From: Kevin Hilman <khilman@kernel.org>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Inki Dae <inki.dae@samsung.com>,
Joonyoung Shim <jy0922.shim@samsung.com>,
Seung-Woo Kim <sw0312.kim@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
David Airlie <airlied@linux.ie>,
Kukjin Kim <kgene.kim@samsung.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [RFC 1/2] PM / Domains: Power on domain early during system resume
Date: Mon, 03 Nov 2014 08:13:17 -0800 [thread overview]
Message-ID: <7hbnoojm8y.fsf@deeprootsystems.com> (raw)
In-Reply-To: <54521A8F.5070808@samsung.com> (Andrzej Hajda's message of "Thu, 30 Oct 2014 12:01:35 +0100")
Andrzej Hajda <a.hajda@samsung.com> writes:
> 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.
Though I'm not terribly familiar with DRM, it seems incorrect because I
expect resume to restore the state of things when suspend happened, not
forcibly resume everything.
> On the other side it is present in many other drivers, so I am also
> little bit confused.
Many other DRM drivers? or other drivers too?
Kevin
next prev parent reply other threads:[~2014-11-03 16:13 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
2014-11-03 16:13 ` Kevin Hilman [this message]
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=7hbnoojm8y.fsf@deeprootsystems.com \
--to=khilman@kernel.org \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=inki.dae@samsung.com \
--cc=jy0922.shim@samsung.com \
--cc=k.kozlowski@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
--cc=sw0312.kim@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).