Grygorii Strashko <grygorii.strashko@xxxxxx> 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@xxxxxx> >> Cc: Felipe Balbi <balbi@xxxxxx> >> Cc: Rajendra nayak <rnayak@xxxxxx> >> Cc: Grygorii Strashko <grygorii.strashko@xxxxxx> >> Signed-off-by: Sourav Poddar <sourav.poddar@xxxxxx> >> --- >> 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
