This patch adds the devicetree documentation required for Rockchip
USB 3.0 core wrapper consisting of USB 3.0 controller IP from Synopsys
and USB 3.0 PHY IP from Innosilicon.
It supports DRD mode, and could operate in device mode (SS, HS, FS)
and host mode (SS, HS, FS, LS).
Change-Id: Ia240627c31cd3ff2f2d7f1a1faa9c7d88207d04f
Signed-off-by: William Wu <wulf@rock-chips.com>
The rk322xh USB3 PHY has a problem to detect disconnection,
it loses the ability to detect an absence of a far-end
receiver termination specified in USB3 spec Table 6-21,
and this causes the linkstate to change between SS.Inactive
and Polling state, but not return to correct state Rx.detect.
To workaround this bug, we depends on the hub_event to
detect the port linkstate change and do soft disconnect.
And then do USB3 PHY reset and reinit HCD to recovery
the whole USB3.
The workaround process is:
Plug out USB3 device -> hub_event detect PLC and find
USB 3.0 port in the Inactive -> call usb_remove_device()
to do soft disconnect -> call usb_phy_notify_connect()
-> send notifier to DWC3 controller driver to do USB3
PHY reset and reinit HCD.
Change-Id: Icb975581c6fbbb34a7da90ddca47e04a46e5da48
Signed-off-by: William Wu <wulf@rock-chips.com>
Some rockchip SoCs (e.g. rk322xh/rk3328) integrated with
INNO USB 3.0 PHY have a problem to detect disconnection
correctly. So we need to depend on the usb phy framework
to handle the disconnection.
Change-Id: Ie3bd015c89e1fb8d46f69fe8d274e29462bfb763
Signed-off-by: William Wu <wulf@rock-chips.com>
This patch implements a USB 3.0 PHY driver for Rockchip
platform (e.g. rk3328) with Innosilicon IP block.
Change-Id: Ia6ed5df6b7b9eecebd5a5c8a4c4a6df7d26b7422
Signed-off-by: William Wu <wulf@rock-chips.com>
This patch adds USB 3.0 PHY grf node and apb node
for rk3328 USB 3.0 module.
Change-Id: I9d4e6c6d6792ac5fd6c2a4d7cc902f1ff0cf4ef1
Signed-off-by: William Wu <wulf@rock-chips.com>
This patch adds a binding that describes the Rockchip USB 3.0
PHY designed by Innosilicon.
Change-Id: Ia5b9f18743c7a7ed1b9d33420608a2f12a086aee
Signed-off-by: William Wu <wulf@rock-chips.com>
We have cherry-pick new binding documentation for dwc3
from upstream, so delete the legacy one.
Change-Id: I292447c96c741445669139478c769e356d1b8d9e
Signed-off-by: William Wu <wulf@rock-chips.com>
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 905228ba1e43c24b3048820a7f1047a4ed5ef185)
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 09210b8aa1881935d31be8a4d9e2574a026512b3)
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 c3620a88e55c3ade4a823adea08b0bb2acc4737e)
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 66f72e45db8d12d4c5049de6c6fb9aae67a30fe6)
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 39c34527e735b84e6ceb8a2e386aed0060111858)
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 0c3397a9b8b4da4ca3a67e5a6d88abf20f00f184)
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 08ea9d12f34f8ea6f79bdd5b7eb1ff74d2cd796f)
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 919cb0208a877a1b80bf4171d479f36c9a2dbca2)
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 899bf65ac08492fc5aec36a1b23509baa008d409)
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 3a94990c47760102a6b314e7b83c75c86af788e6)
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>
