Hi Benoit,

On Mon, Nov 26, 2012 at 14:32:59, Cousson, Benoit wrote:

Hi Vaibhav,

On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote:

quoted

On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:

quoted

On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:

quoted

As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM).
To handle resource sharing & IP integration
1. Rework on parent child relation between PWMSS and
   ECAP, EQEP & EHRPWM child devices to support runtime PM.
2. Add support for opt_clks in EHRPWM HWMOD entry to handle additional
   clock gating from control module.
3. Add HWMOD entries for EQEP PWM submodule.

Is there any review on this patch?
This patch depends on ECAP & EHRPWM to work in am335x.

First of all, I think you should break up this patch as per the 3 points
that you mentioned above.

The usage of opt_clks for this does not look right to me. Based on your
description this clock is necessary and not optional on AM335x and on 
Davinci platforms this clock does not exist.

I checked the DA830 TRM and looks like TBCLK for eHRPWM is an always on clock
there. So, the only difference in AM335x is an additional enable bit.

Instead of adding this as opt_clk in hwmod, we could add an always on clock node
in Davinci clock data and have the driver always do a clk_enable() on the tbclk
as part of the probe sequence. On AM335x, with the right clock node this will enable
the clock in hardware and on DA830 it turns into a NOP. This way we can avoid adding
the opt_clk entry in hwmod of eHRPWM.

quoted

I think the custom activate/deactivate functions in the OMAP runtime PM
implementation was a good fit for keeping this SoC integration detail out
of the driver code. However, the current DT flow in omap_device.c seems to
assign the default activate/deactivate ops. Is that approach deprecated?

The issue is that this approach is not doable anymore with DT, that's
why I had to provide a default set of functions.

So once all OMAP drivers get converted to DT, will there be no notion of
latency based activate/deactivate functions? Or will it get used in a different
manner?

Regards,
Vaibhav