[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7hbnoojm8y.fsf@deeprootsystems.com>
Date: Mon, 03 Nov 2014 08:13:17 -0800
From: Kevin Hilman <khilman@...nel.org>
To: Andrzej Hajda <a.hajda@...sung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@...sung.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Inki Dae <inki.dae@...sung.com>,
Joonyoung Shim <jy0922.shim@...sung.com>,
Seung-Woo Kim <sw0312.kim@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
David Airlie <airlied@...ux.ie>,
Kukjin Kim <kgene.kim@...sung.com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org,
linux-samsung-soc@...r.kernel.org,
Marek Szyprowski <m.szyprowski@...sung.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [RFC 1/2] PM / Domains: Power on domain early during system resume
Andrzej Hajda <a.hajda@...sung.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@...sung.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists