this patch is used for rockchip built-in HDMI and DP audio output which are
wired to the same i2s line. so we use a DAI link CPU to multicodecs.
Change-Id: Ie8d1ede201a4d4b4cd11c8c05cd1f6177d844957
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
snd_soc_get_dai_name() is used from snd_soc_of_get_dai_name(),
and it is assuming that DT is using "sound-dai" / "#sound-dai-cells".
But graph base DT is using "remote-endpoint". This patch makes
snd_soc_get_dai_name() non static for graph support.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit 1ad8ec535b)
Change-Id: If99dcbfa722f09e3238cfafb5dc2803b6636a2e0
This adds move some common properties of usb-otg from dts to dtsi.
Change-Id: I84355433b5ca63cc0b763d66dcdbb38897635418
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Using the builtin I2C controller in dw_hdmi is better than using the
normal RK3288 I2C controller(I2C5).
Test: work normally when switch mode between 4K@60hz|4K@30hz|1080P..
Change-Id: Ifb4b72ca5649efb0cc3055f2db34ebbcc2377c4c
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Using the builtin I2C controller in dw_hdmi is better than using the
normal RK3399 I2C controller(I2C3).
Change-Id: I6a2de7221263e8564f7cca56ea5c52e1a133c138
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
"I2C Master Interface Extended Read Mode" implements a segment
pointer-based read operation using the Special Register configuration.
This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned
"The current implementation does not support "I2C Master Interface
Extended Read Mode" to read data addressed by non-zero segment
pointer, this means that if EDID has more than 1 extension blocks"
With this patch,dw-hdmi can read EDID data with 1/2/4 blocks.
(am from https://patchwork.kernel.org/patch/9586343/)
BUG=chrome-os-partner:59768
TEST=fievel can read 1/2/4 blocks EDID data
Change-Id: I086e6ea63ec69c0532be445b958ce253a7f1f3cc
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/442308
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
field. Doing that will ease adaptation of the PWM framework to support
atomic update.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 4b58896f72)
Change-Id: Ic6bdaf2017bb292ef920604fba86805999cebf0c
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
We're going to need to amend this table in board files.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from commit 647cea2e68)
Change-Id: Ife7affa44554622b1b35ad6756cef78d22c69a3a
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
This patch fix the following warning:
drivers/pwm/pwm-rockchip.c:176:6: warning: unused variable 'ret' [-Wunused-variable]
Change-Id: I9ac08ad08fdefee5b875d36592936b07f032586c
Signed-off-by: David Wu <david.wu@rock-chips.com>
support wifi driver work as ko module or compile into kernel
1. wifi driver work as ko module, configs show as below:
CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP=n
CONFIG_RTL8188EU = m and CONFIG_RTL8188FU = m
2. wifi driver compile into kernel, configs show as below:
ps: Only one Realtek driver can be compiled into the kernel
CONFIG_WIFI_LOAD_DRIVER_WHEN_KERNEL_BOOTUP=y
CONFIG_RTL8188EU = y or CONFIG_RTL8188FU = y
Change-Id: I40e33a6f27597f9f90d9987d189b74fb637c40c1
Signed-off-by: Xu Xuehui <xxh@rock-chips.com>
On yuv domain, background need use 10bit yuv format.
Change-Id: I02fe3894ac12b509e22c0d90977bcb7e4535c16d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
VOP output mode and bus_format must be ROCKCHIP_OUT_MODE_YUV420
and MEDIA_BUS_FMT_YUV8_1X24 when display mode has a YCbCr420
flag.
Change-Id: Ib2d51c119f5a8f1b8a9285c47ab228b22a293d56
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Since bits[19:22] have been used for picture aspect ratio
in upstream patch 876f43c073.
We define YCbCr420 flag to the subsequent bits.
Change-Id: I2eff8b51227fc7beb4f587e90bc070ae865ba9d4
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
invert the pwm polarity for new pwm interface
Change-Id: I8dfde14fbc4fd4aa907722f260ce72fdb4d7d3bb
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
The pwm_apply_args() should be removed when switching to the atomic
PWM API. Oherwise, the screen would splashing as the backlight is
disabled once when boot.
Change-Id: I0cadd471db54140192c39b9d7c6a673862e8f8d8
Signed-off-by: David Wu <david.wu@rock-chips.com>
If the pwm was not enabled at uboot loader, pwm could not work for clock
always disabled at pwm driver. The pwm clock is enabled at beginning of
pwm_apply(), but disabled at end of pwm_apply().
If the pwm was enabled at uboot loader, pwm clock is always enabled unless
closed by ATF. The pwm-backlight might turn off the power at early suspend,
should disable pwm clock for saving power consume.
It is important to provide opportunity to enable/disable clock at pwm driver,
the pwm consumer should ensure correct order to call pwm enable/disable, and
pwm driver ensure state of pwm clock synchronized with pwm enabled state.
Change-Id: I545db81eb638957567abacb93fd06fff9dd7181b
Fixes: 2bf1c98aa5 ("pwm: rockchip: Add support for atomic update")
Signed-off-by: David Wu <david.wu@rock-chips.com>
While the particular usage in question is likely safe (struct
cros_ec_command is 32-bit aligned, followed by <= 32-bit fields), it's
been suggested this is not a great pattern to follow for the general
case -- for example, if we follow a 'struct cros_ec_command' (which is
32-bit- but not 64-bit-aligned) with a struct that starts with a 64-bit
type (e.g., u64), the compiler may add padding.
Let's add __packed, to inform the compiler of our true intention -- to
have no padding between these struct elements -- and to future proof for
any refactorings that might occur.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 065cfbbb63)
Change-Id: Iddd499863dde168679a88c2f9ecc461316b417a0
Signed-off-by: David Wu <david.wu@rock-chips.com>
Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.
This driver supports only device tree at the moment, because that
provides a very flexible way of describing the relationship between PWMs
and their consumer devices (e.g., backlight). On a non-DT system, we'll
probably want to use the non-GENERIC addressing (i.e., we'll need to
make special device instances that will use EC_PWM_TYPE_KB_LIGHT or
EC_PWM_TYPE_DISPLAY_LIGHT), as well as the relatively inflexible
pwm_lookup infrastructure for matching devices. Defer that work for now.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 1f0d3bb027)
Change-Id: I47dbb20b10ae1b941e50e9a783cb708dff8f7efd
Signed-off-by: David Wu <david.wu@rock-chips.com>
The ChromeOS Embedded Controller can support controlling its attached
PWMs via its host-command interface. The number of supported PWMs varies
on a per-board basis, but we can autodetect this by checking the error
codes, so we don't need an extra property for this. And because the EC
only allows specifying the duty cycle and not the period, we don't
specify the period via pwm-cells, and instead have only support for one
cell -- to specify the index.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 9e60f50b4a)
Change-Id: Ibb2ac5cff1e8cc2ab43c9f1f89e68e48da23d897
Signed-off-by: David Wu <david.wu@rock-chips.com>
The continuous mode allows one to declare a PWM regulator without having
to declare the voltage <-> dutycycle association table. It works fine as
long as your voltage(dutycycle) function is linear, but also has the
following constraints:
- dutycycle for min_uV = 0%
- dutycycle for max_uV = 100%
- dutycycle for min_uV < dutycycle for max_uV
While the linearity constraint is acceptable for now, we sometimes need to
restrict of the PWM range (to limit the maximum/minimum voltage for
example) or have a min_uV_dutycycle > max_uV_dutycycle (this could be
tweaked with PWM polarity, but not all PWMs support inverted polarity).
Add the pwm-dutycycle-range and pwm-dutycycle-unit DT properties to define
such constraints. If those properties are not defined, the PWM regulator
use the default pwm-dutycycle-range = <0 100> and
pwm-dutycycle-unit = <100> values (existing behavior).
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit ea398e2873)
Change-Id: I6e10c93a6620113e1463221d461fc23ccf3fe398
Signed-off-by: David Wu <david.wu@rock-chips.com>
The current logic will disable the PWM clk even if the PWM was left
enabled by the bootloader (because it's controlling a critical device
like a regulator for example).
Keep the PWM clk enabled if the PWM is enabled to avoid any glitches.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(commit 48cf973cae)
Conflicts:
drivers/pwm/pwm-rockchip.c
Change-Id: I75ffccd19c5244568fc0034d1585dac490296111
Signed-off-by: David Wu <david.wu@rock-chips.com>
The current implementation always round down the duty and period values,
while it would be better to round them to the closest integer.
These changes are needed in preparation of atomic update support to
prevent a period/duty cycle drift when executing several times the
'pwm_get_state() / modify / pwm_apply_state()' sequence.
Say you have an expected period of 3.333 us and a clk rate of
112.666667 MHz -- the clock frequency doesn't divide evenly, so the
period (stashed in nanoseconds) shrinks when we convert to the register
value and back, as follows:
pwm_apply_state(): register = period * 112666667 / 1000000000;
pwm_get_state(): period = register * 1000000000 / 112666667;
or in other words:
period = period * 112666667 / 1000000000 * 1000000000 / 112666667;
which yields a sequence like:
3333 -> 3328
3328 -> 3319
3319 -> 3310
3310 -> 3301
3301 -> 3292
3292 -> ... (etc) ...
With this patch, we'd see instead:
period = div_round_closest(period * 112666667, 1000000000) *
1000000000 / 112666667;
which yields a stable sequence:
3333 -> 3337
3337 -> 3337
3337 -> ... (etc) ...
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 12f9ce4a51)
Change-Id: Ife75404e663d1380725d634ac621b2ca9f831791
Signed-off-by: David Wu <david.wu@rock-chips.com>
The continuous PWM voltage regulator is caching the voltage value in
the ->volt_uV field. While most of the time this value should reflect the
real voltage, sometime it can be sightly different if the PWM device
rounded the set_duty_cycle request.
Moreover, this value is not valid until someone has modified the regulator
output.
Remove the ->volt_uV field and always rely on the PWM state to calculate
the regulator output.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit d9070fdbe4)
Change-Id: Iba7b143c1b08d547b5cd46ac42d9051fb34309df
Signed-off-by: David Wu <david.wu@rock-chips.com>
The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current
voltage value.
If possible, retrieve the current voltage selector from the PWM state,
else return -EINVAL.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 87248991a1)
Change-Id: I179395dc7bad7aa867e68c92be7ce92b03ae7112
Signed-off-by: David Wu <david.wu@rock-chips.com>
Use the atomic API wherever appropriate and get rid of pwm_apply_args()
call (the reference period and polarity are now explicitly set when
calling pwm_apply_state()).
We also make use of the pwm_set_relative_duty_cycle() helper to ease
relative to absolute duty_cycle conversion.
Note that changes introduced by commit fd786fb027 ("regulator: pwm:
Try to avoid voltage error in duty cycle calculation") are no longer
needed because pwm_set_relative_duty_cycle() takes care of all rounding
approximation for us.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: Brian Norris <briannorris@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit 3f4eb39be9)
Change-Id: Id12d4d625fb6e1e5ff3725737cc9232e4df40c36
Signed-off-by: David Wu <david.wu@rock-chips.com>
The PWM framework expects PWM users to configure the duty cycle in nano-
seconds, but many users want to express the duty cycle relatively to the
period value (i.e. duty_cycle = 33% of the period).
Add the pwm_{get,set}_relative_duty_cycle() helpers to ease this kind of
conversion.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit f6f3bddf7b)
Change-Id: Ifffc72290225766a6006db6b18e6902ee51adb1c
Signed-off-by: David Wu <david.wu@rock-chips.com>
The pwm_init_state() helper prepares a new state object containing the
current PWM state except for the polarity and period fields which are
set to the reference values (those in struct pwm_args).
This is particularly useful for PWM users who want to apply a new duty-
cycle expressed relatively to the reference period without changing the
enable state.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
(cherry picked from commit a6a0dbbcfa)
Change-Id: Ib968e8fa6a49d5f853fc13cb4935e2af7494040f
Signed-off-by: David Wu <david.wu@rock-chips.com>
The original commit adding support for continuous voltage mode didn't
handle the regulator ramp delay properly. It treated the delay as a
fixed delay in uS despite the property being defined as uV / uS. Let's
adjust it. Luckily there appear to be no users of this ramp delay for
PWM regulators (as per grepping through device trees in linuxnext).
Note also that the upper bound of usleep_range probably shouldn't be a
full 1 ms longer than the lower bound since I've seen plenty of hardware
with a ramp rate of ~5000 uS / uV and for small jumps the total delays
are in the tens of uS. 1000 is way too much. We'll try to be dynamic
and use 10%.
NOTE: This commit doesn't add support for regulator-enable-ramp-delay.
That could be done in a future patch when someone has a user of that
featre.
Though this patch is shows as "fixing" a bug, there are no actual known
users of continuous mode PWM regulator w/ ramp delay in mainline and so
this likely won't have any effect on anyone unless they are working
out-of-tree with private patches. For anyone in this state, it is
highly encouraged to also pick Boris Brezillon's WIP patches to get
yourself a reliable and glitch-free regulator.
Fixes: 4773be185a ("regulator: pwm-regulator: Add support for continuous-voltage")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit c2588393e6)
Change-Id: Ib0af8e04275813f333af12d48567b7e411b4d49f
Signed-off-by: David Wu <david.wu@rock-chips.com>
