Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756554Ab3DWJVs (ORCPT ); Tue, 23 Apr 2013 05:21:48 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:57949 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755087Ab3DWJVq (ORCPT ); Tue, 23 Apr 2013 05:21:46 -0400 Message-ID: <51765296.1030800@ti.com> Date: Tue, 23 Apr 2013 14:51:26 +0530 From: Sourav Poddar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Grygorii Strashko CC: Kevin Hilman , , , , , , , Santosh Shilimkar , Felipe Balbi , Rajendra nayak Subject: Re: [RFC/PATCHv2 5/5] arm: omap2+: omap_device: remove no_idle_on_suspend 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> In-Reply-To: <5176520B.2040004@ti.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3958 Lines: 96 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 >>> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/