| Message ID | 1366638237-6880-6-git-send-email-sourav.poddar@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? > > 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 (( > > arch/arm/mach-omap2/omap_device.c | 12 +++--------- > arch/arm/mach-omap2/omap_device.h | 10 ---------- > 2 files changed, 3 insertions(+), 19 deletions(-) > > diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c > index 381be7a..2043d71 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct platform_device *pdev) > r->name = dev_name(&pdev->dev); > } > > - if (of_get_property(node, "ti,no_idle_on_suspend", NULL)) > - omap_device_disable_idle_on_suspend(pdev); > - > pdev->dev.pm_domain = &omap_device_pm_domain; > > odbfd_exit1: > @@ -620,11 +617,9 @@ static int _od_suspend_noirq(struct device *dev) > ret = pm_generic_suspend_noirq(dev); > > if (!ret && !pm_runtime_status_suspended(dev)) { > - if (pm_generic_runtime_suspend(dev) == 0) { > - if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) > - omap_device_idle(pdev); > + if (pm_generic_runtime_suspend(dev) == 0) > + omap_device_idle(pdev); > od->flags |= OMAP_DEVICE_SUSPENDED; > - } > } > > return ret; > @@ -638,8 +633,7 @@ static int _od_resume_noirq(struct device *dev) > if ((od->flags & OMAP_DEVICE_SUSPENDED) && > !pm_runtime_status_suspended(dev)) { > od->flags &= ~OMAP_DEVICE_SUSPENDED; > - if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) > - omap_device_enable(pdev); > + omap_device_enable(pdev); > pm_generic_runtime_resume(dev); > } > > diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h > index 044c31d..17ca1ae 100644 > --- a/arch/arm/mach-omap2/omap_device.h > +++ b/arch/arm/mach-omap2/omap_device.h > @@ -38,7 +38,6 @@ extern struct dev_pm_domain omap_device_pm_domain; > > /* omap_device.flags values */ > #define OMAP_DEVICE_SUSPENDED BIT(0) > -#define OMAP_DEVICE_NO_IDLE_ON_SUSPEND BIT(1) > > /** > * struct omap_device - omap_device wrapper for platform_devices > @@ -101,13 +100,4 @@ static inline struct omap_device *to_omap_device(struct platform_device *pdev) > { > return pdev ? pdev->archdata.od : NULL; > } > - > -static inline > -void omap_device_disable_idle_on_suspend(struct platform_device *pdev) > -{ > - struct omap_device *od = to_omap_device(pdev); > - > - od->flags |= OMAP_DEVICE_NO_IDLE_ON_SUSPEND; > -} > - > #endif -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Mon, Apr 22, 2013 at 07:13:57PM +0530, 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? > > 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? let's ask Péter. Péter, OMAP_DEVICE_NO_IDLE_ON_SUSPEND should be removed as driver's can get same behavior by just returning -EBUSY from their ->runtime_suspend callbacks. Do you see any problems with patch below (left for reference) ? Would it be too difficult to add ->runtime_suspend/->runtime_resume on ASoC layer ? > diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c > index 381be7a..2043d71 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct platform_device *pdev) > r->name = dev_name(&pdev->dev); > } > > - if (of_get_property(node, "ti,no_idle_on_suspend", NULL)) > - omap_device_disable_idle_on_suspend(pdev); > - > pdev->dev.pm_domain = &omap_device_pm_domain; > > odbfd_exit1: > @@ -620,11 +617,9 @@ static int _od_suspend_noirq(struct device *dev) > ret = pm_generic_suspend_noirq(dev); > > if (!ret && !pm_runtime_status_suspended(dev)) { > - if (pm_generic_runtime_suspend(dev) == 0) { > - if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) > - omap_device_idle(pdev); > + if (pm_generic_runtime_suspend(dev) == 0) > + omap_device_idle(pdev); > od->flags |= OMAP_DEVICE_SUSPENDED; > - } > } > > return ret; > @@ -638,8 +633,7 @@ static int _od_resume_noirq(struct device *dev) > if ((od->flags & OMAP_DEVICE_SUSPENDED) && > !pm_runtime_status_suspended(dev)) { > od->flags &= ~OMAP_DEVICE_SUSPENDED; > - if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) > - omap_device_enable(pdev); > + omap_device_enable(pdev); > pm_generic_runtime_resume(dev); > } > > diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h > index 044c31d..17ca1ae 100644 > --- a/arch/arm/mach-omap2/omap_device.h > +++ b/arch/arm/mach-omap2/omap_device.h > @@ -38,7 +38,6 @@ extern struct dev_pm_domain omap_device_pm_domain; > > /* omap_device.flags values */ > #define OMAP_DEVICE_SUSPENDED BIT(0) > -#define OMAP_DEVICE_NO_IDLE_ON_SUSPEND BIT(1) > > /** > * struct omap_device - omap_device wrapper for platform_devices > @@ -101,13 +100,4 @@ static inline struct omap_device *to_omap_device(struct platform_device *pdev) > { > return pdev ? pdev->archdata.od : NULL; > } > - > -static inline > -void omap_device_disable_idle_on_suspend(struct platform_device *pdev) > -{ > - struct omap_device *od = to_omap_device(pdev); > - > - od->flags |= OMAP_DEVICE_NO_IDLE_ON_SUSPEND; > -} > - > #endif > -- > 1.7.1 >
On Mon, Apr 22, 2013 at 07:13:57PM +0530, 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> Looks alright to me: Reviewed-by: Felipe Balbi <balbi@ti.com> but let's see what Péter Ujfalusi says before applying this one.
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. >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 04/22/2013 04:38 PM, Felipe Balbi wrote: >> 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? > > let's ask Péter. > > Péter, OMAP_DEVICE_NO_IDLE_ON_SUSPEND should be removed as driver's can > get same behavior by just returning -EBUSY from their ->runtime_suspend > callbacks. Do you see any problems with patch below (left for > reference) ? Would it be too difficult to add > ->runtime_suspend/->runtime_resume on ASoC layer ? I don't see any issue with this. FWIW AESS/ABE does not use the OMAP_DEVICE_NO_IDLE_ON_SUSPEND flag neither in upstream nor in my development branch.
On 04/23/2013 08:19 AM, Sourav Poddar wrote: > 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 Sourav, Kevin, Let it be, but could you update patch description with detailed explanation of what drivers should do from now to be able to use such functionality (make IP active while System is suspended). So, people, who've used this hack before (even if these users are not in *mainline*) will know what to do. Regards -grygorii >>>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 23 April 2013 02:49 PM, Grygorii Strashko wrote: > On 04/23/2013 08:19 AM, Sourav Poddar wrote: >> 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 Sourav, Kevin, > > Let it be, but could you update patch description with detailed > explanation > of what drivers should do from now to be able to use such functionality > (make IP active while System is suspended). > So, people, who've used this hack before (even if these users are not > in *mainline*) > will know what to do. > Sure, will try to be more explicit in my change log in my next version. > Regards > -grygorii > >>>>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 381be7a..2043d71 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -170,9 +170,6 @@ static int omap_device_build_from_dt(struct platform_device *pdev) r->name = dev_name(&pdev->dev); } - if (of_get_property(node, "ti,no_idle_on_suspend", NULL)) - omap_device_disable_idle_on_suspend(pdev); - pdev->dev.pm_domain = &omap_device_pm_domain; odbfd_exit1: @@ -620,11 +617,9 @@ static int _od_suspend_noirq(struct device *dev) ret = pm_generic_suspend_noirq(dev); if (!ret && !pm_runtime_status_suspended(dev)) { - if (pm_generic_runtime_suspend(dev) == 0) { - if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) - omap_device_idle(pdev); + if (pm_generic_runtime_suspend(dev) == 0) + omap_device_idle(pdev); od->flags |= OMAP_DEVICE_SUSPENDED; - } } return ret; @@ -638,8 +633,7 @@ static int _od_resume_noirq(struct device *dev) if ((od->flags & OMAP_DEVICE_SUSPENDED) && !pm_runtime_status_suspended(dev)) { od->flags &= ~OMAP_DEVICE_SUSPENDED; - if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND)) - omap_device_enable(pdev); + omap_device_enable(pdev); pm_generic_runtime_resume(dev); } diff --git a/arch/arm/mach-omap2/omap_device.h b/arch/arm/mach-omap2/omap_device.h index 044c31d..17ca1ae 100644 --- a/arch/arm/mach-omap2/omap_device.h +++ b/arch/arm/mach-omap2/omap_device.h @@ -38,7 +38,6 @@ extern struct dev_pm_domain omap_device_pm_domain; /* omap_device.flags values */ #define OMAP_DEVICE_SUSPENDED BIT(0) -#define OMAP_DEVICE_NO_IDLE_ON_SUSPEND BIT(1) /** * struct omap_device - omap_device wrapper for platform_devices @@ -101,13 +100,4 @@ static inline struct omap_device *to_omap_device(struct platform_device *pdev) { return pdev ? pdev->archdata.od : NULL; } - -static inline -void omap_device_disable_idle_on_suspend(struct platform_device *pdev) -{ - struct omap_device *od = to_omap_device(pdev); - - od->flags |= OMAP_DEVICE_NO_IDLE_ON_SUSPEND; -} - #endif
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? 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? arch/arm/mach-omap2/omap_device.c | 12 +++--------- arch/arm/mach-omap2/omap_device.h | 10 ---------- 2 files changed, 3 insertions(+), 19 deletions(-)