From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sourav Poddar Subject: Re: [RFC/PATCHv2 5/5] arm: omap2+: omap_device: remove no_idle_on_suspend Date: Tue, 23 Apr 2013 14:51:26 +0530 Message-ID: <51765296.1030800@ti.com> References: <1366638237-6880-1-git-send-email-sourav.poddar@ti.com> <1366638237-6880-6-git-send-email-sourav.poddar@ti.com> <517545C2.3080006@ti.com> <87y5ca76hm.fsf@linaro.org> <517619DF.5010803@ti.com> <5176520B.2040004@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5176520B.2040004@ti.com> Sender: linux-kernel-owner@vger.kernel.org To: Grygorii Strashko Cc: Kevin Hilman , gregkh@linuxfoundation.org, tony@atomide.com, rmk+kernel@arm.linux.org.uk, linux-serial@vger.kernel.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, Santosh Shilimkar , Felipe Balbi , Rajendra nayak List-Id: linux-serial@vger.kernel.org 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 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 >>>>> Cc: Felipe Balbi >>>>> Cc: Rajendra nayak >>>>> Cc: Grygorii Strashko >>>>> Signed-off-by: Sourav Poddar >>>>> --- >>>>> 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 >>> >> >