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>
The operation mode of controller will change to peripheral when
resume if PD is power off during suspend, current code disconnect
hcd and set lx state to L3 in this case to make sure the controller
will be reinit in device mode, but that's not enough, the op_state
is still host which is change when init or ID change interrupt
occur. If the ID change happened after suspend the driver would
miss the interrupt, so when the application call the pullup function
to stop gadget and start again to change to another function, the
disconnect gadget operation can't be done and the gadget restart
directly. This will result in NULL point when gadget work. This
patch set op_state to OTG_STATE_B_PERIPHERAL when resume in this
case.
Change-Id: Ifbafb7fae43d634cfa879c9a066d1e114db4196e
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
This adds support for the RK3308 audio codec.
Change-Id: Ieccdebaa27f4a46f6de9406046a6e02e20398013
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
hdmi_sound is defined in "rk3399-sapphire.dtsi"
So we do not need to define it again.
Change-Id: Ieb7e11240d06d64c82954ee725589b667480a4cc
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
We cache the invalid cached phase when the clock provider be
reparented from orphan to its real parent in the first place,
thus we may mess up the initialization of MMC cards since we
only set the default sample phase and drive phase later on.
So we should skip to restore the invalid phase.
Change-Id: I2d995a4ab53b824737718482f35fcaaf84767dfb
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
It's found that the clock phase output from clk_summary is
wrong compared to the actual phase reading from the register.
cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
sdio_sample 0 1 0 50000000 0 -22
It exposes an issue that clk core, clk_core_get_phase, always
returns the cached core->phase which should be either updated
by calling clk_set_phase or directly from the first place the
clk was registered.
When registering the clk, the core->phase getting from ->get_phase()
may return negative value indicating error. This is quite common
since the clk's phase may be highly related to its parent chain,
but it was temporarily orphan when registered, since its parent
chains hadn't be ready at that time, so the clk drivers decide to
return error in this case. However, if no clk_set_phase is called or
maybe the ->set_phase() isn't even implemented, the core->phase would
never be updated. This is wrong, and we should try to update it when
all its parent chains are settled down, like the way of updating clock
rate for that. But it's not deserved to complicate the code now and
just update it anyway when calling clk_core_get_phase, which would be
much simple and enough.
Change-Id: I21e8899f4dc6cb0d244ea8c9741337b17da3308d
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
(cherry picked from git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
commit 1f9c63e8de)
vccio_sd and vcc_sd are well better controlled by MMC core
and please don't bother taking care of them instead, otherwise
reboot w/ a working SD3.0 card will fail to respond the correct
OCR in the first place as missing a proper power removal.
Change-Id: I9efa11e25198b66e21538bd6603a3bab6638dc5f
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
set frame effect to fix mistake fild when in interlace mode
Change-Id: I74143cc28cbd9a7864a1df57979f3888137c141c
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
when video width is bigger than 3840 the linebuffer mode
should be LB_YUV_3840X5.
Change-Id: I27dce8a6fcb7f6f5b8d196671a515c68f188c101
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
On 32bit platform, vco may be out of range. The variable type
of vco needs to be set to u64.
Change-Id: I2f6b967278986bb77bf74c7a11794fc4d73645db
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
panel init cmds is not only for dsi panel, some mcu screen and
spi screen also need init cmds, so we update this panel init cmd
name and reuse this part logic.
Change-Id: I9e633647fa3f3d92eb90b443a8a5da99a24a3b42
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
