On 02/29/2016 05:20 PM, Tony Lindgren wrote:

* Franklin S Cooper Jr. [off-list ref] [160229 15:12]:

quoted

On 02/29/2016 04:55 PM, Tony Lindgren wrote:

quoted

* Franklin S Cooper Jr. [off-list ref] [160229 14:31]:

quoted

On 02/29/2016 04:04 PM, Tony Lindgren wrote:

quoted

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.

quoted

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.

quoted

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 :)

quoted

quoted

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?