RE: Query on clock naming conventions in clockxxxx_data.c

2010-09-24 Thread Kanigeri, Hari
Archit,

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Taneja, Archit
 Sent: Friday, September 24, 2010 7:41 AM
 To: Nayak, Rajendra
 Cc: linux-omap@vger.kernel.org; Guruswamy, Senthilvadivu
 Subject: Query on clock naming conventions in clock_data.c
 
 Hi,
 
 I had a couple of queries regarding the clock structures in the
 clock_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().
 

I guess migrating to hwmod should resolve the issue you mentioned.

Thank you,
Best regards,
Hari
--
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


RE: Query on clock naming conventions in clockxxxx_data.c

2010-09-24 Thread Nayak, Rajendra
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 clock_data.c
 
 Hi,
 
 I had a couple of queries regarding the clock structures in the 
 clock_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


RE: Query on clock naming conventions in clockxxxx_data.c

2010-09-24 Thread Taneja, Archit
Hi,

Thanks for this info.

Regards,

Archit

Nayak, Rajendra wrote:
 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 clock_data.c
 
 Hi,
 
 I had a couple of queries regarding the clock structures in the
 clock_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