linux-kernel - Re: [RFC/PATCHv2 5/5] arm: omap2+: omap_device: remove no_idle_on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <517619DF.5010803@ti.com>
Date:	Tue, 23 Apr 2013 10:49:27 +0530
From:	Sourav Poddar <sourav.poddar@...com>
To:	Kevin Hilman <khilman@...aro.org>
CC:	Grygorii Strashko <grygorii.strashko@...com>,
	<gregkh@...uxfoundation.org>, <tony@...mide.com>,
	<rmk+kernel@....linux.org.uk>, <linux-serial@...r.kernel.org>,
	<linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Felipe Balbi <balbi@...com>, Rajendra nayak <rnayak@...com>
Subject: Re: [RFC/PATCHv2 5/5] arm: omap2+: omap_device: remove no_idle_on_suspend

Hi Kevin,
On Tuesday 23 April 2013 12:11 AM, Kevin Hilman wrote:
> Grygorii Strashko<grygorii.strashko@...com>  writes:
>
>> On 04/22/2013 04:43 PM, Sourav Poddar wrote:
>>> Remove the "OMAP_DEVICE_NO_IDLE_ON_SUSPEND" check, since
>>> driver should be able to prevent idling of an omap device
>>> whenever required.
>>>
>>> Cc: Santosh Shilimkar<santosh.shilimkar@...com>
>>> Cc: Felipe Balbi<balbi@...com>
>>> Cc: Rajendra nayak<rnayak@...com>
>>> Cc: Grygorii Strashko<grygorii.strashko@...com>
>>> Signed-off-by: Sourav Poddar<sourav.poddar@...com>
>>> ---
>>> Hi Kevin,
>>>
>>> I have put this as an RFC, due to few comments on cover letter of
>>> the previous version by Grygorii Strashko.
>>> As, he has mentioned that there are Audio playback use cases which
>>> also requires "no_idle_on_suspend" and using them on mainline after
>>> this series can cause regression.
>>>
>>> What you think will be the right approach on this in relation to this patch?
>>> I mean every driver(if possible) should  prevent
>>> runtime PM for no_idle_on_suspend usecase and we get
>>> rid of this OMAP_DEVICE_NO_IDLE_ON_SUSPEND check? OR we should
>>> drop this patch as of now?
> This is the correct approach, and AFAICT you've fixed the *mainline*
> users of this patch which is the important part.  If there are other
> mainline users of this feature, we need to know about them.
>
> Let me be clear: this OMAP_DEVICE_NO_IDLE_ON_SUSPEND feature is a hack
> (it was introduced by me, but still a hack.)  We've found a way to
> handle using the generic framework, and we should move to that.  There
> are already a handful of complications when combining runtime PM and
> system suspend, and this is just another one.  It makes the most sense
> for this handling to be in the drivers themselves.  IOW: if the driver
> wants to refuse to runtime suspend (during system suspend), it has the
> choice.
>
Yes, I was also of the same view that the driver should take care of the
no_idle_on_suspend case and we should get rid of the hacks around this.
Modifying a respective driver will be a more generic solution which will 
work
irrespective of dt and non dt boot.

>>> Hi Grygorii,
>>>
>>> Is it possible to handle ABE no_idle_on_suspend uscase the way I am
>>> trying to handle it for UART in the 2nd patch of this series?
>> Unfortunately, I don't know ASOC details (my part is PM),  but from
>> the first look it
>> will be not easy, because map4-dmic have no Runtime PM handlers at
>> all, for example ((
> Are those drivers upstream?  If so, please point them out and show how
> this feature is being used in *mainline* by those drivers.
>
> For OMAP PM, we have been very clear for a long time all of our PM was
> based on runtime PM.  Any drivers that are not runtime PM are broken and
> need to be fixed.
>
> As long as Sourav is fixing up all the mainline users of this feature, my
> plan to merge/ack the changes unless there are some good arguemnts based
> on *upstream* users of the feature.
>
> 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/