Re: [PATCH v4 2/3] ARM: omap: hwmod: get rid of all omap_clk_get_by_name usage

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Thu, 2012-08-30 at 13:57 +0200, Benoit Cousson wrote:
> On 08/30/2012 10:39 AM, Rajendra Nayak wrote:
> > On Thursday 30 August 2012 05:45 AM, Turquette, Mike wrote:
> >> On Wed, Aug 29, 2012 at 1:56 AM, Rajendra Nayak<rnayak@ti.com>  wrote:
> >>> diff --git a/arch/arm/mach-omap2/clock44xx_data.c
> >>> b/arch/arm/mach-omap2/clock44xx_data.c
> >>> index d7f55e4..a3831a2 100644
> >>> --- a/arch/arm/mach-omap2/clock44xx_data.c
> >>> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> >>> @@ -3156,6 +3156,7 @@ static struct omap_clk omap44xx_clks[] = {
> >>>          CLK(NULL,       "dss_tv_clk",&dss_tv_clk,    CK_443X),
> >>>          CLK(NULL,       "dss_48mhz_clk",&dss_48mhz_clk, CK_443X),
> >>>          CLK(NULL,       "dss_dss_clk",&dss_dss_clk,   CK_443X),
> >>> +       CLK(NULL,       "dss_fck",&dss_fck,       CK_443X),
> >>>          CLK("omapdss_dss",      "ick",&dss_fck,       CK_443X),
> >>
> >> Is it right to re-use dss_fck for the "ick" here?  I think it is due
> >> to omap4 modulemode stuff but I don't have DM in front of me and
> >> wanted a double-check...
> > 
> > yes, its because of the wierdness of DSS clocks where a so-called
> > optional clock is actually a function clock.
> 
> Not only, it is a hack to allow the DSS to be enabled whenever a DSS
> submodule has to be enabled. Since they are sharing the ick, it will
> enable the modulemode when the DISPC will be enabled.
> 
> That hack should disappear as soon as the DSS will be able to handle the
> PM dependency between DSS submodules and the DSS itself using pm_runtime
> parent/child link.
> And then we will have to remove this fake ick modulemode clock node and
> let hwmod handle that properly.
> 
> Tomi already cleaned the DSS part, I guess it should be upstreamed soon,
> if this is not already the case.

This is in 3.5. omapdss_dss is now the parent for the rest of the dss
submodules, and runtime PM is being used.

I think we should now revisit this dss clock handling to see if there
are any other changes required in the omapdss side, but I hope they are
already according to our discussions and correct.

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]