Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754441AbcCBTmB (ORCPT ); Wed, 2 Mar 2016 14:42:01 -0500 Received: from arroyo.ext.ti.com ([192.94.94.40]:47309 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751560AbcCBTl5 (ORCPT ); Wed, 2 Mar 2016 14:41:57 -0500 Subject: Re: [PATCH v3 1/5] pwms: pwm-ti*: Remove support for local clock gating To: Tony Lindgren References: <1456439796-28546-1-git-send-email-fcooper@ti.com> <1456439796-28546-2-git-send-email-fcooper@ti.com> <20160229220444.GQ13417@atomide.com> <56D4C69D.1090100@ti.com> <20160229225536.GR13417@atomide.com> <56D4D032.7040801@ti.com> <20160229232011.GU13417@atomide.com> CC: , , , , , , , , , Thierry Reding From: "Franklin S Cooper Jr." Message-ID: <56D741E6.3000708@ti.com> Date: Wed, 2 Mar 2016 13:41:26 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160229232011.GU13417@atomide.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2870 Lines: 75 On 02/29/2016 05:20 PM, Tony Lindgren wrote: > * Franklin S Cooper Jr. [160229 15:12]: >> >> On 02/29/2016 04:55 PM, Tony Lindgren wrote: >>> * Franklin S Cooper Jr. [160229 14:31]: >>>> On 02/29/2016 04:04 PM, Tony Lindgren wrote: >>>>> Hmm but why are you also removing the pm_runtime calls? Those >>>>> actually do take care of gating the clocks via the interconnect >>>>> level code that is hwmod in this case. >>>> I removed all PM runtime calls that revolved around >>>> pwmss_submodule_state_change. Originally the driver would do >>>> a pm_runtime_get_sync then call pwmss_submodule_state_change >>>> and then immediately call pm_runtime_put_sync. Without >>>> pwmss_submodule_state_change those calls would be >>>> meaningless. I also removed pm_runtime calls in error paths >>>> that no longer existed. >>> Typically the interconnect level code can gate the clkctrl bit >>> for the module with PM runtime even with no other driver specific >>> registers. If you remove the pm_runtime calls, that does not >>> happen. >> So the clocks should be unlocked when ever the IP registers are >> being read/written or if the peripheral is being used for >> example >> the pwm signal is being generated. All these cases are already >> being handled. >> >> Using ecap driver as an example. >> >> Pm_runtime_get_sync is called within ecap_pwm_enable when >> the pwm signal is to be generated. Pm_runtime_put_sync is called >> when the pwm signal is to be stopped. >> >> When either the pwm signal polarity is set or pwm >> configuration is made >> then a pm_runtime_get_sync and pm_runtime_put_sync are >> called within >> the same function surrounding calls to the IP's registers. >> >> Probe is calling pm_runtime_enable while remove is calling >> pm_runtime_disable. > OK good to hear you have considered this. The above answers > my questions then thanks. > >> So the correct pm_runtime calls are being made from what I >> can see. >> I'm not sure I understand the concern since removing those >> calls aren't >> creating any kind of imbalance. > OK thanks for checking. > >> If I'm not addressing your concern please give me an example >> of where >> you see a possible issue. > No that's fine. I thought you're ripping out all of the the > pm_runtime based on just looking at the patch :) > >>> Also, how do you know this change does not affect the other >>> SoC variants using the same driver? >> I've tested these changes on AM335x GP and AM437x GP evms. >> AM335x >> and AM437x were the only other users of this driver. Sorry >> I should of >> documented this in my cover-letter. > OK good to hear. > > Thanks, > > Tony I know there are some comments regarding other patches in this patchset but this patch is unrelated and can be pulled in separately. Any objections to this or should I just resubmit this patch by itself?