In order not to cause ABI regression, let's invent a new
androidboot.mode for NVMe instead. Just elaborate a bit more
that we now doesn't support mtd devices, otherwise we should
rework it to make it more scalable.
Change-Id: I115ffd0e5c4986f2e76fcbcf6700c31f297f7950
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
To modify hdmi default output color depth, use following dts:
&hdmi {
rockchip,defaultdepth = <10>;
}
rockchip,defaultdepth could be following value:
<0> auto select color depth, prefer 8bit
<8> 8bit
<10> 10bit
Change-Id: Idce0bd080c042edf3939c5c38b76d4d1860b7a9f
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 905228ba1e)
Use following command to set hdr metadata:
cd /sys/class/display/HDMI
echo "hdrmdata=1 2 3 4 5 6 7 8 9 10 11 12" > color
Use following command to get current hdr metadata
cat /sys/class/display/HDMI/color
Change-Id: I81a5000801b558728689be912c1a642f3b237e65
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 09210b8aa1)
Use following command:
echo mode=<value> > /sys/class/display/HDMI/mode
<value> is decimal digits, lower 8bit is color mode, upper 8bit is depth.
For example:
value = 131 = 0x83 means YCbCr444 8bit output
value = 164 = 0xa4 means YCbCr422 10bit output
value = 0 means restore auto mode(8bit, priority YCbCr444)
Change-Id: I256906d91f7075defb4d785cfc15926ca5627093
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit c3620a88e5)
fix warning: switch condition has boolean value [-Wswitch-bool]
Change-Id: I11d7a9fe2a07f6681dacf4a1d800b16497339297
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 66f72e45db)
1. HDR MetaData HB2 is 26.
2. Under HF1-53, HDR MetaData should be sent and
PB1 value should be exist in EDID.
Change-Id: I616b4cdcf321ea0080b845c868d1f4cd4881fd14
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 39c34527e7)
If output tmdsclk is out of sink max tmds clk, we need to set output
mode to 8bit or YCbCr422.
For example, sink max tmds clk is 600M, but 3840x2160p-60 10bit tmdsclk
is 594*1.25 > 600, we set output mode to YCbCr422 10bit which tmds clk
is 594, so we can get max picture quality.
Change-Id: I13fe30dad06757ec52de8d367f1e10a56e63ad92
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 0c3397a9b8)
HDR is introduced by HDMI2.0a, which need parsing HDR Static
Metedata data Block defined in EDID, and send Dynamic Range
and Mastering InfoFrame to inform TV to switch to HDR mode.
If TV support HDR, it's EOTF is shown in sysfs node
/sys/class/display/HDMI/color with key word "Supported EOTF:".
For example, "Support EOTF: 0x7" means support following EOTF:
BIT0: Traditional gamma - SDR
BIT1: Traditional gamma - HDR
BIT2: ST_2084
To switch eotf mode, you can use following command:
echo hdr=value > /sys/class/display/HDMI/color
value could be:
0 - Disable sending Dynamic Range and Mastering InfoFrame
1 - Traditional gamma - SDR
2 - Traditional gamma - HDR
4 - ST_2084
0、1 both means SDR mode， 4 is HDR10/Dolby HDR mode.
Change-Id: Ia3d19bbca9b9368cde8dcb11265fbff4684ac603
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 08ea9d12f3)
user can change hdmi_dbg_level value to printf log which you want.
1 : cec
2 : hdmi
3 : hdcp
such as, echo 2 > /sys/module/rockchip_hdmi_sysfs/parameters/hdmi_dbg_level
Change-Id: Iaa5a66c2926789694e0d544196bedc81fb3a755a
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>
(cherry picked from commit 919cb0208a)
When box is starting, if kernel resolution is different from uboot,
need to clear hdmi->uboot
Change-Id: Iec56862fe20dcaccc12fefae21de55b56ab2fe54
Signed-off-by: Shen Zhenyi <szy@rock-chips.com>
(cherry picked from commit 899bf65ac0)
CEC GRF register can be replaced by hdmi cec register
CEC_CTRL BIT 5.
Change-Id: Ic27eb242e23c4a9b4de6a77032372eac11b5247c
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 3a94990c47)
If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.
Change-Id: Id72b1f92e10449c48006aced0d49612637402210
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
In cases when a PM domain isn't powered off when genpd's ->prepare()
callback is invoked, genpd runtime resumes and disables runtime PM for the
device. This behaviour was needed when genpd managed intermediate states
during the power off sequence, as to maintain proper low power states of
devices during system PM suspend/resume.
Commit ba2bbfbf63 (PM / Domains: Remove intermediate states from the
power off sequence), enables genpd to improve its behaviour in that
respect.
The PM core disables runtime PM at __device_suspend_late() before it calls
a system PM "late" callback for a device. When resuming a device, after a
corresponding "early" callback has been invoked, the PM core re-enables
runtime PM.
By changing genpd to allow runtime PM according to the same system PM
phases as the PM core, devices can be runtime resumed by their
corresponding subsystem/driver when really needed.
In this way, genpd no longer need to runtime resume the device from its
->prepare() callback. In most cases that avoids unnecessary and energy-
wasting operations of runtime resuming devices that have nothing to do,
only to runtime suspend them shortly after.
Although, because of changing this behaviour in genpd and due to that
genpd powers on the PM domain unconditionally in the system PM resume
"noirq" phase, it could potentially cause a PM domain to stay powered
on even if it's unused after the system has resumed. To avoid this,
schedule a power off work when genpd's system PM ->complete() callback
has been invoked for the last device in the PM domain.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 4d23a5e848)
Change-Id: I195392386758b1320107d17f4e54c3c220263a9c
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
The PM core increases the runtime PM usage count at the system PM prepare
phase. Later when the system resumes, it does a pm_runtime_put() in the
complete phase, which in addition to decrementing the usage count, does
the equivalent of a pm_request_idle().
Therefore the call to pm_request_idle() from within genpd's ->complete()
callback is redundant, so remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 9b002b8f0e)
Change-Id: I3b6b3cb1b7675f7a9579b57d801efa5ea55c0e4e
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Due to the previous changes in genpd, which removed the suspend_power_off
flag, several of the system PM callbacks no longer do any additional
checks but only invoke corresponding pm_generic_* helper functions.
To clean up the code, drop these wrapper functions as they have
become redundant. Instead, assign the system PM callbacks directly
to the pm_generic_*() helper functions.
While changing this, it has bocame clear that some of the current
system PM callbacks in genpd invoke wrong driver callbacks. For
example, the genpd's ->restore() callback invokes pm_generic_resume(),
while that should be pm_generic_restore(). Fix that as well.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 8001885389)
Change-Id: I463cc0a8c4d6d2e69dd320ff58af3cf2e999e6ee
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
If a PM domain is powered off when the first device starts its system PM
prepare phase, genpd prevents any further attempts to power on the PM
domain during the following system PM phases. Not until the system PM
complete phase is finalized for all devices in the PM domain, genpd again
allows it to be powered on.
This behaviour needs to be changed, as a subsystem/driver for a device in
the same PM domain may still need to be able to serve requests in some of
the system PM phases. Accordingly, it may need to runtime resume its
device and thus also request the corresponding PM domain to be powered on.
To deal with these scenarios, let's make the device operational in the
system PM prepare phase by runtime resuming it, no matter if the PM domain
is powered on or off. Changing this also enables us to remove genpd's
suspend_power_off flag, as it's being used to track this condition.
Additionally, we must allow the PM domain to be powered on via runtime PM
during the system PM phases.
This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
driver. It registers a genpd to model the ACP as a PM domain, but
unfortunately it's also abuses genpd's "internal" suspend_power_off flag
to deal with a corner case at system PM resume.
More precisely, the so called SMU block powers on the ACP at system PM
resume, unconditionally if it's being used or not. This may lead to that
genpd's internal status of the power state, may not correctly reflect the
power state of the HW after a system PM resume.
Because of changing the behaviour of genpd, by runtime resuming devices in
the prepare phase, the AMD ACP drm driver no longer have to deal with this
corner case. So let's just drop the related code in this driver.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 39dd0f234f)
Change-Id: I1c964ebd660c8c7a8547f2206c80c25b936e7196
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
As the PM core already have wakeup management during the system PM phase,
it seems reasonable that genpd and its users should be able to rely on
that. Therefore let's remove this from pm_genpd_prepare().
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 164a2159a2)
Change-Id: I39f72aa82468327c01b4533d177f797bf2da59a6
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
1. MID board is only one dp port, we need to assign a phy.
2. MID board not use HDMI, we need to disabled it.
Change-Id: I589373fa04b940681910b3c0ee58ee9f9f464916
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
The u2phy driver of kernel 4.4 need add config and specific tuning
for rk3328. This patch add support of u2phy for rk3328.
Change-Id: Ie1bdfc0fde37d7d0b26d0f3aac136481bd6f4c44
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
Due to the u2phy registers are separated from general grf, we need to
add u2phy grf node and place u2phy node in it. And on some platform,
the 480m clock may need to assign clock parent in dts in stead of
clock driver. So this patch add u2phy grf node and property of
assigned-clocks and assigned-clock-parents to assign parent for 480m
clock.
Change-Id: I88e63745e38265814169136f079a00791f5813b3
Signed-off-by: Meng Dongyang <daniel.meng@rock-chips.com>
to slove the display shaking, when uboot logo display to kernel show.
Change-Id: I804aa09f24bc4fa7b6314a7a5487f0ee1a321724
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
attention:
if the vopb is for hdmi,the vopb parent clk must be vpll
and the vopl parent clk is cpll or others plls.
if the vopl is for hdmi,the vopl parent clk must be vpll
and the vopb parent clk is cpll or other plls.
Change-Id: I9056fbdbfcdb7a71f2e7ee5d57a0db8523be66ef
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
On a Rockchip rk3399-based board during suspend/resume testing, we
found that we could get the console UART into a state where it would
print this to the console a lot:
serial8250: too much work for irq42
Followed eventually by:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 11s!
Upon debugging I found that we're in this state:
iir = 0x000000cc
lsr = 0x00000060
It appears that somehow we have a RX Timeout interrupt but there is no
actual data present to receive. When we're in this state the UART
driver claims that it handled the interrupt but it actually doesn't
really do anything. This means that we keep getting the interrupt
over and over again.
Normally we don't actually need to do anything special to handle a RX
Timeout interrupt. We'll notice that there is some data ready and
we'll read it, which will end up clearing the RX Timeout. In this
case we have a problem specifically because we got the RX TImeout
without any data. Reading a bogus byte is confirmed to get us out of
this state.
It's unclear how exactly the UART got into this state, but it is known
that the UART lines are essentially undriven and unpowered during
suspend, so possibly during resume some garbage / half transmitted
bits are seen on the line and put the UART into this state.
The UART on the rk3399 is a DesignWare based 8250 UART. From mailing
list posts, it appears that other people have run into similar
problems with DesignWare based IP. Presumably this problem is unique
to that IP, so I have placed the workaround there to avoid possibly of
accidentally triggering bad behavior on other IP. Also note the RX
Timeout behaves very differently in the DMA case, for for now the
workaround is only applied to the non-DMA case.
BUG=chrome-os-partner:59918
TEST=suspend_stress_test
Change-Id: I99974b2977527868c6216ac624dcb8bc9b64cf46
Signed-off-by: Douglas Anderson <dianders@chromium.org>
(am from https://patchwork.kernel.org/patch/9558923/)
Reviewed-on: https://chromium-review.googlesource.com/421577
Reviewed-by: Caesar Wang <wxt@rock-chips.com>
