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]

Date:	Mon, 22 Apr 2013 11:41:41 -0700
From:	Kevin Hilman <khilman@...aro.org>
To:	Grygorii Strashko <grygorii.strashko@...com>
Cc:	Sourav Poddar <sourav.poddar@...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

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.

>> 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/