From: a.hajda@samsung•com (Andrzej Hajda)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC 1/2] PM / Domains: Power on domain early during system resume
Date: Thu, 30 Oct 2014 12:01:35 +0100 [thread overview]
Message-ID: <54521A8F.5070808@samsung.com> (raw)
In-Reply-To: <1414654594.5114.8.camel@AMDC1943>
On 10/30/2014 08:36 AM, Krzysztof Kozlowski wrote:
> On ?ro, 2014-10-29 at 10:46 -0700, Kevin Hilman wrote:
>> Krzysztof Kozlowski <k.kozlowski@samsung•com> writes:
>>
>>> When resuming the system the power domain has to be powered on early so
>>> any runtime PM aware devices could resume.
>>>
>>> This fixes following scenario reproduced on Exynos DRM:
>>> 1. Power domain is off before suspending the system.
>>> 2. System is suspended to RAM.
>>> 3. Resuming starts. The Exynos DRM driver resume callback is called.
>>> 4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns
>>> the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON.
>> Dumb Q: if the device (and power domain) were off before (and during)
>> suspend, why are they being resumed?
>>
>> Shouldn't the resume path restore things to the same state they were
>> before suspend?
> One could expect that... but the Exynos DRM driver behaves differently
> (and some other drivers also). In resume method it calls
> drm_helper_resume_force_mode() which forces restoring mode setting
> configuration. Apparently setting a mode needs DPMS on:
> static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
> {
> ...
> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
> ...
>
> The previous DPMS status (status during suspend) is completely ignored
> here.
Suspend callback switches off all connectors (thus all other devs in
their pipeline) by calling dpms_off,
in restore callback all devs are restored to their previous state by
calling appropriate dpms.
So I guess drm_helper_resume_force_mode() call at the end of resume is
incorrect.
On the other side it is present in many other drivers, so I am also
little bit confused.
Regards
Andrzej
next prev parent reply other threads:[~2014-10-30 11:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-23 13:48 [RFC 0/2] PM and DRM: Add runtime PM to Exynos DSI Krzysztof Kozlowski
2014-10-23 13:48 ` [RFC 1/2] PM / Domains: Power on domain early during system resume Krzysztof Kozlowski
2014-10-23 16:20 ` Grygorii Strashko
2014-10-24 7:30 ` Krzysztof Kozlowski
2014-10-29 17:46 ` Kevin Hilman
2014-10-30 7:36 ` Krzysztof Kozlowski
2014-10-30 11:01 ` Andrzej Hajda [this message]
2014-11-03 16:13 ` Kevin Hilman
2014-11-04 13:43 ` Grygorii Strashko
2014-10-23 13:48 ` [RFC 2/2] drm/exynos/dsi: Add runtime PM so LCD power domain could be turned off Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54521A8F.5070808@samsung.com \
--to=a.hajda@samsung$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox