RE: Query on clock naming conventions in clockxxxx_data.c
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
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
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