Re: [RFC/PATCHv2 5/5] arm: omap2+: omap_device: remove no_idle_on_suspend

[Sourav Poddar <sourav.poddar@ti.com>]

Hi Kevin,
On Tuesday 23 April 2013 12:11 AM, Kevin Hilman wrote:
> Grygorii Strashko<grygorii.strashko@ti.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@ti.com>
>>> Cc: Felipe Balbi<balbi@ti.com>
>>> Cc: Rajendra nayak<rnayak@ti.com>
>>> Cc: Grygorii Strashko<grygorii.strashko@ti.com>
>>> Signed-off-by: Sourav Poddar<sourav.poddar@ti.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
>