Archit,
> -----Original Message-----
> From: Taneja, Archit
> Sent: Friday, September 24, 2010 6:11 PM
> To: Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org; Guruswamy, Senthilvadivu
> Subject: Query on clock naming conventions in clockxxxx_data.c
>
> Hi,
>
> I had a couple of queries regarding the clock structures in the
> clockxxxx_data.c files:
>
> -I have seen that the name of the structure itself explains the name of the
> clock as
> given in the TRM.
> -The member "name" also tries to mimic the clock name.
>
> The drivers get the clock struct using the "name" member in the clk_get()
> api. Is it
> okay if we can change the "name" member to a more generic string. So that the
> driver
> code stays more generic?
>
> For example, the SYS_CLK which comes into DSS is called "dss2_alwon_fck" on
> omap3 and
> "dss_sys_clk" on omap4. This will make our driver need to have cpu_is_omap
> checks
> while
> calling clk_get().
The right way to use the clk_get api is by passing the dev pointer to identify
the device
and a generic identifier like fck or ick to identify the type/functionality of
the clock.
Its not advisable to hardcode clock names, the very reason being that it gets
difficult to
maintain clock node names across processor families and eventually you end up
with
cpu_is_* checks.
Doing this however requires the clkdev tables to be updated with the mapping of
device
names and generic clock identifiers to the actual clock node.
So if you today have something like
if (cpu_is_omap34xx())
clk_get(NULL, " dss2_alwon_fck");
else
clk_get(NULL, " dss_sys_clk");
It can very easily be replaced with a
clk_get(dev, "fck");
with the clkdev table entry for omap3 like
CLK("dss-omap","fck", &dss2_alwon_fck...
and the clkdev table entry for omap4 having something like
CLK("dss-omap","fck", & dss_sys_clk...
Now, however since all drivers are using pm_runtime api's which hide the clk
control from drivers, this might not have be needed anyway.
Regards,
Rajendra
>
> Thanks,
>
> Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
