Proportional Rate Reduction for TCP.

This patch implements Proportional Rate Reduction (PRR) for TCP.
PRR is an algorithm that determines TCP's sending rate in fast
recovery. PRR avoids excessive window reductions and aims for
the actual congestion window size at the end of recovery to be as
close as possible to the window determined by the congestion control
algorithm. PRR also improves accuracy of the amount of data sent
during loss recovery.

The patch implements the recommended flavor of PRR called PRR-SSRB
(Proportional rate reduction with slow start reduction bound) and
replaces the existing rate halving algorithm. PRR improves upon the
existing Linux fast recovery under a number of conditions including:
  1) burst losses where the losses implicitly reduce the amount of
outstanding data (pipe) below the ssthresh value selected by the
congestion control algorithm and,
  2) losses near the end of short flows where application runs out of
data to send.

As an example, with the existing rate halving implementation a single
loss event can cause a connection carrying short Web transactions to
go into the slow start mode after the recovery. This is because during
recovery Linux pulls the congestion window down to packets_in_flight+1
on every ACK. A short Web response often runs out of new data to send
and its pipe reduces to zero by the end of recovery when all its packets
are drained from the network. Subsequent HTTP responses using the same
connection will have to slow start to raise cwnd to ssthresh. PRR on
the other hand aims for the cwnd to be as close as possible to ssthresh
by the end of recovery.

A description of PRR and a discussion of its performance can be found at
the following links:
- IETF Draft:
    http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
- IETF Slides:
    http://www.ietf.org/proceedings/80/slides/tcpm-6.pdf
    http://tools.ietf.org/agenda/81/slides/tcpm-2.pdf
- Paper to appear in Internet Measurements Conference (IMC) 2011:
    Improving TCP Loss Recovery
    Nandita Dukkipati, Matt Mathis, Yuchung Cheng

Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ARM: errata: 716044: an uncacheable load multiple can cause a deadlock.

Under some rare circumstances, an uncacheable load multiple
instruction (LDRD, LDM, VLDM, VLD1, VLD2, VLD3, VLD4) can cause
a processor deadlock.

Change-Id: Ibd79aa8182dce37d0be9892f2310735e1123618a
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-on: http://git-master/r/95914
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
Tested-by: Varun Colbert <vcolbert@nvidia.com>
ARM: smp: Fix cpu_up() racing with sys_reboot

Nothing stops a process from hotplugging in a CPU concurrently
with a sys_reboot() call. In such a situation we could have
ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the
fact that the CPU is not really offline and call the
CPU_UP_PREPARE notifier. When this happens stop_machine code will
complain that the cpu thread already exists and BUG_ON().

CPU0                      CPU1

sys_reboot()
 kernel_restart()
  machine_restart()
   machine_shutdown()
    smp_send_stop()
    ...                   ipi_cpu_stop()
                           set_cpu_online(1, false)
                            local_irq_disable()
                             while(1)
    <PREEMPT>
cpu_up()
 _cpu_up()
   if (!cpu_online(1))
    __cpu_notify(CPU_UP_PREPARE...)
cpu_stop_cpu_callback()
  BUG_ON(stopper->thread)

This is easily reproducible by hotplugging in and out in a tight
loop while also rebooting.

Since the CPU is not really offline and hasn't gone through the
proper steps to be marked as such, let's mark the CPU as inactive.
This is just as easily testable as online and avoids any possibility
of _cpu_up() trying to bring the CPU back online when it never was
offline to begin with.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
modified for tuna kernel by faux123 from Linux 3.5+
ARM: tegra: clock: Export clock minimum

Add clock minimum to debugfs.

Bug 917644

Change-Id: Ie088809829af2bdc81a969a034bf00847459f0ce
Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
Reviewed-on: http://git-master/r/101555
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>
media: video: tegra: add GPL v2 MODULE_LICENSE

Add MODULE_LICENSE to modules that do not advertise a license,
and therefore taint the kernel.

Bug 979176

Change-Id: I1abbfa9ca1535b39e70d8bf7aa975e2663a6e45d
Signed-off-by: Eric Brower <ebrower@nvidia.com>
Reviewed-on: http://git-master/r/100214
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
cpufreq: Don't clip PM QoS requests to old policy limits

Clipping PM QoS requests to combined old policy limits that include
both PM QoS and user policy requests creates a circular dependency.
As a result new PM QoS maximum limit is rejected if it is above
previous PM QoS minimum limit even though the new PM QoS minimum
limit has been already lowered below new PM QoS maximum limit.

Instead clip PM QoS request to the old user policy limits only.

Change-Id: Ice0a53a699e0798f07f0e32d6b8a28586fe5db0c
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/102386
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Donghan Ryu <dryu@nvidia.com>
Reviewed-by: Antti Miettinen <amiettinen@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
Tested-by: Vikas Ramesh Kedigehalli <vikasr@nvidia.com>
arm: tegra: governor:  change governor using cpufreq interface

Older code sets "conservative" governor in early-suspend
using sysfs entries.This implementation changes governor
in early-suspend using cpufreq interfaces.

bug 871958

Change-Id: I721afb6184982a063dc5f330da31f8fb88481cfd
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: http://git-master/r/100849
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>
video: tegra: dc: remove bandwidth efficiency

Remove the efficiency factor in the bandwidth calculation.
Clock API will take care off setting the right clock based factoring the
efficiency.

Change-Id: I2b549197778b5afaf1aab3cc87a84debb08172e8
Reviewed-on: http://git-master/r/91659
Signed-off-by: Jon Mayo <jmayo@nvidia.com>
Reviewed-on: http://git-master/r/103682
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
GVS: Gerrit_Virtual_Submit
crypto: tegra-se: Use sg_next to get next sg

Use sg_next to get next sg

Bug 958431

Signed-off-by: Mallikarjun Kasoju <mkasoju@nvidia.com>

Change-Id: I14aa7c9c551d0230b9c5b681a2699dd5355d0a6d
Reviewed-on: http://git-master/r/98449
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Mallikarjun Kasoju <mkasoju@nvidia.com>
Tested-by: Mallikarjun Kasoju <mkasoju@nvidia.com>
Reviewed-by: Venkat Moganty <vmoganty@nvidia.com>
ARM: tegra: dvfs: Fix error checking of voltage

Fix error checking of predicted voltage. Also get rid of
maybe-uninitialized warning when using 4.6 toolchain.

Bug 949219
Bug 999222

Change-Id: I47553aba5a93c91bdd93cbf75081d69f92aec4dd
Signed-off-by: Juha Tukkinen <jtukkinen@nvidia.com>
Reviewed-on: http://git-master/r/108899
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>
arm: tegra: Fix cpu governor change issue

It fixes the issue where cpu governor change
was inconsistent across platforms.

In T2x, AUTO HOTPLUG is disabled therefore we need
to store/restore gov for all online cpus across
LP0 cycle.

In T3x, AUTO HOTPLUG is enabled therefore storing/restoring
gov for Cpu0 across LP0 cycle. Cpu0 remains online in suspend
and resume.

bug 991081

Change-Id: I167654aa21e4832b3fdc40e3d388a4d3f984632b
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: http://git-master/r/105404
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>

Conflicts:

	arch/arm/mach-tegra/common.c
arm: tegra: hotplug: modify down_delay

Modified the hot-plug governor down_delay to be 500ms instead of 2s

Bug 958978

Change-Id: I55b5a4994f8e4564879cfd206fc683ff6f32d9ac
Signed-off-by: Wen Yi <wyi@nvidia.com>
(cherry picked from commit dd477396f2762f871255fb9d0800431d7534754d)
Reviewed-on: http://git-master/r/111640
Reviewed-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Tested-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
video: tegra: dc: support disp mode override via boot args

Allows overidding the default disp mode without having to recompile
the kernel. Boot args can be specified in the following format:

disp_params=<rgb|hdmi|dsi>:pclk,h_active,v_active,h_ref_to_sync,
v_ref_to_sync,h_sync_width,v_sync_width,h_back_porch,v_back_porch,
h_front_porch,v_front_porch;<rgb|hdmi|dsi>:pclk,h_active,...

Bug 969088

Change-Id: Id0acf608de145493f6749d5b799d4bbb8162ba72
Signed-off-by: Nirav Patel <nipatel@nvidia.com>
Reviewed-on: http://git-master/r/104604
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
regulator: fix incorrectly cached voltage on error

In regulator_set_voltage, if _regulator_do_set_voltage returns
an error, the new voltage will still be cached.  If
regulator_set_voltage is called again with the same constraints,
it will return success, but the voltage will still be at the
old voltage.

Keep the old voltage cached if _regulator_do_set_voltage returns
and error.

Signed-off-by: Colin Cross <ccross@android.com>
Change-Id: I7c9cb3e508be92a3ec807e88f093a8e185e56b3c
v0.6