If hdmi plug in when kernel starting, hdmi may be without output.
Because the old criteria that to determine whether uboot logo is
on is hdmi phy pll locked and hdmi is connected. But in some
platform(such as rk3229), hdmi phy pll is locked even hdmi phy
is power down. In this case, the old criteria is unreliable.
So we add a new criteria that check Frame Composer register.If
the register value is not 0, we think that uboot logo is on,
hdmi has been setup.
Change-Id: Ifaa27030e5f5d551bec8f971694ff5d9c34a7c1d
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Ladder governor is for periodic timer tick, we use menu governor.
Change-Id: Iffb797a801563f6745238a26b2582ea57d6ab0a5
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Add irq disabled protection at the PWM configuration, which can
speed up the PWM configuration and reduce the possibility of
interrupting the configuration.
Change-Id: I8ca3c4b9790b747c12804fa82b51456a0de7fb92
Signed-off-by: David Wu <david.wu@rock-chips.com>
From AOSP 294eb9dac3c0 ("mkbootimg: use int for os_version and os_patch_level")
Change-Id: I5026049859df121d0a034085c2563cfc4ef98230
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Add LEDS_IS31FL32XX for rk3308-evb.
Add ARM64_CRYPTO for best performance, use 75KB.
Change-Id: Id2aafe02ccdb163af00d4bc19375a1fddca450a4
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Some regulators have different settling times for voltage increases and
decreases. To avoid a time penalty on the faster transition allow for
different settings for up- and downward transitions.
Change-Id: Iab14df27c8275945a31a55630ce3c926acf5828d
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 3ffad468cf)
Some regulators have different settling times for voltage increases and
decreases. Add DT properties to define separate settling times for up-
and downward voltage changes.
Change-Id: Ie41615b15161608d1751685147702e451a205531
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 543853de35)
Some regulators (some PWM regulators) have the voltage transition
non-linear i.e. exponentially. On such cases, the settling time
for voltage transition can not be presented in the voltage-ramp-delay.
Add new property for non-linear voltage transition and handle this
in getting the voltage settling time.
Change-Id: I3b3b8b173beaa3ecbc959b241c791d0816e5b7d2
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit d6c1dc3f52)
Some regulators (some PWM regulators) have the voltage transition
exponentially. On such cases, the settling time for voltage change
is treated as constant time.
Add DT property for providing the settling time for any level of
voltage change for non-linear voltage change.
signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Change-Id: Ia88df848c62aecb0e03838a00398655a44dc220f
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit cfd2cedb48)
commit 73e705bf81 ("regulator: core: Add set_voltage_time op")
introduced a new rdev_warn() if the ramp_delay is 0.
Apparently, on omap3/twl4030 platforms with dynamic voltage
management this results in non-ending spurious messages like
[ 511.143066] VDD1: ramp_delay not set
[ 511.662322] VDD1: ramp_delay not set
[ 513.903625] VDD1: ramp_delay not set
[ 514.222198] VDD1: ramp_delay not set
[ 517.062835] VDD1: ramp_delay not set
[ 517.382568] VDD1: ramp_delay not set
[ 520.142791] VDD1: ramp_delay not set
[ 520.502593] VDD1: ramp_delay not set
[ 523.062896] VDD1: ramp_delay not set
[ 523.362701] VDD1: ramp_delay not set
[ 526.143035] VDD1: ramp_delay not set
I have observed this on GTA04 while it is reported to occur on
N900 as well: https://bugzilla.kernel.org/show_bug.cgi?id=178371
This patch makes the warning appear only in debugging mode.
Change-Id: I29b9fcc6f5507bd9763d26d076d72e8ccb0e25ec
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit ba14fa1a57)
The new op is analogous to set_voltage_time_sel. It can be used by
regulators which don't have a table of discrete voltages. The function
returns the time for the regulator output voltage to stabilize after
being set to a new value, in microseconds. If the op is not set a
default implementation is used to calculate the delay.
This change also removes the ramp_delay calculation in the PWM
regulator, since the driver now uses the core code for the calculation
of the delay.
Change-Id: I401ace81648be8e8eab2e4bd3a0f41ed9766fae1
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 73e705bf81)
The current code assumes that only the ramp_delay is used to determine
the time needed for the voltage to stabilize. This may be true for the
calculation done by regulator_set_voltage_time_sel(), however regulators
can implement their own set_voltage_time_sel() op which would be skipped
if no ramp delay is specified. Remove the check in
_regulator_do_set_voltage(), the functions calculating the ramp delay
return 0 anyway when the ramp delay is not configured.
Change-Id: Ia15f06f27b5dfa230cd8c7f548965a8fa283c263
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit d89564efe7)
If the voltage can not be set jump to the end of the function. This
avoids having to check for an error multiple times and eliminates one
level of nesting in a follow-up change.
Change-Id: Icead960f8403e2e962cd94fc516a5f633f5c3fc7
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 31dfe686ed)
According to Dave Miller "the networking stack has a
hard requirement that all SKBs which are transmitted
must have their completion signalled in a fininte
amount of time. This is because, until the SKB is
freed by the driver, it holds onto socket,
netfilter, and other subsystem resources."
In summary, this means that using TX IRQ throttling
for the networking gadgets is, at least, complex and
we should avoid it for the time being.
Change-Id: Ice4107af47309054e67f1ab22cc7c2c6a393263d
Cc: <stable@vger.kernel.org>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: David Miller <davem@davemloft.net>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit fd9afd3cbe)
The phy flag shift offset is defined in dts file, there is
no need to or the shift in the phy driver.
Change-Id: I13a33a536dabea68adf07a73cc2d13439719c589
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
