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>
Clock slop is a solution for rk3288, not suitable for rk3399,
after use crtc mode_valid, we can remove the clock slop.
Change-Id: I68121505dfb7e65bf09c26d51c23edc909bdb517
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
