[PATCH v3 03/10] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem

[Bedia, Vaibhav]

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:
> > On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
> >> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
> >>> 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.

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