On 01/17/2018 05:57 AM, Sekhar Nori wrote:
On Tuesday 16 January 2018 10:51 PM, David Lechner wrote:
On 01/16/2018 08:00 AM, Sekhar Nori wrote:
On Monday 08 January 2018 07:47 AM, David Lechner wrote:
+void __init da850_psc_clk_init(void __iomem *psc0, void __iomem *psc1)
+{
+ struct clk_onecell_data *clk_data;
+
+ clk_data = davinci_psc_register_clocks(psc0, da850_psc0_info, 16);
+ if (!clk_data)
+ return;
+
+ clk_register_clkdev(clk_data->clks[3], NULL, "ti-aemif");
+ clk_register_clkdev(clk_data->clks[3], "aemif", "davinci-nand.0");
+ clk_register_clkdev(clk_data->clks[4], NULL, "spi_davinci.0");
+ clk_register_clkdev(clk_data->clks[5], NULL, "da830-mmc.0");
+ clk_register_clkdev(clk_data->clks[9], NULL, "serial8250.0");
+ clk_register_clkdev(clk_data->clks[14], "arm", NULL);
+ clk_register_clkdev(clk_data->clks[15], NULL, "davinci-rproc.0");
+
+ clk_free_onecell_data(clk_data);
+
+ clk_data = davinci_psc_register_clocks(psc1, da850_psc1_info, 32);
+ if (!clk_data)
+ return;
+
+ clk_register_clkdev(clk_data->clks[1], "usb20_psc_clk", NULL);
Is this con_id really needed now? Searching for "usb20_psc_clk" in your
tree results in only this one hit.
Yes, this is left over from previous attempts.
+ clk_register_clkdev(clk_data->clks[1], NULL, "musb-da8xx");
+ clk_register_clkdev(clk_data->clks[1], NULL, "cppi41-dmaengine");
I guess multiple dev_id matches like these are another hurdle in moving
them to davinci_psc_clk_info[] table? If its too cumbersome to keep
multiple entries in the table, they can be handled as an exception at
the end of processing the table? Still they are not the norm so I hope
the normal case will still benefit.
Right, as I mentioned in the reply to the previous patch, instead of
assigning a con_id and dev_id to each clock, we would need to assign
an array with a list of clocks. I think that would work better than
trying to handle the extras as an exception since there, on average,
about 5 per SoC.
Okay, are you going to try this to see how it looks? It looks like
samsung (clk-s3c2410.c) and tegra (clk-tegra20.c) use such tables
(although both use separate tables mapping just the gate number to
con_id/dev_id).
Others like u8540_clk.c and clk-mmp2.c have multiple calls in code to
clk_register_clkdev() like you have, but they keep them right after the
gate clock registration which makes it easy to see the mapping.
clk-imx35.c has multiple clk_register_clkdev() calls, but uses an enum
for the gates so its easy to see the mapping. This approach looks fine
to me as well.
So looks like there is a whole gamut of ways people have approached
this. But I do think we need to change the scheme you have currently
since it is difficult to review and audit (believe me on this one :))
OK, I'll figure out something here.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
