It's required by gpu driver, which will load firmware through
/system/vendor/firmware.
If android finds another way to fix it, then can be reverted.
Change-Id: I2fede28f022f10c2e16f68b21159a638a10a53ec
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
this patch register hdmi and dp as one sound card, and compatible
single hdmi audio, single dp audio or both.
Change-Id: I840e6c13f1a0c765a3a9235eb0a798011fc3bf06
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
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>
