On Thu, 2009-08-13 at 00:40 +0100, Russell King wrote: > Maybe - and since you're just starting to look at clkdev, I'll point > out that it's actually not intuitive which way around the "wildcard" > matching works in clkdev. The clk_get() arguments aren't the > wildcards, they're in the clk_lookup structure. Yes, it seems odd, > but if you consider it from the point of view of the platform code > wanting to match clocks to a specific set of devices and clock inputs, > it's actually the way around that you want.
Ok so I had a look, it's basically a list of bindings between a device "ID" (dev_name(dev)) and a clock input name, matched to a struct clk *. I'm not entirely sure I want to port that over, because I believe that I can do better with the device-tree, but then, it will mostly depend whether we end up wanting to use drivers that do rely on the clkdev mechanism. For one, I'm not 100% certain that our dev_id's are unique. Then, that means that at some stage, the clock source provider need to create the struct clk for anything devices -may- need, so for all the device clock connections in the system, it cannot be done on-demand. I'm thus tempted to pursue for now an approach where the connection is provided by the device-tree exclusively (or override platform code but that's to be avoided most of the time), we'll see where it takes us. IE. In case you haven't looked at what I had in mind there, basically the device-node of a device contains properties linking each clock input to the device node of the clock provider, along with the ID of that clock within the provider space. So all I need is register clock providers, that get passed in clk_get() with the "translated" clock ID and that can spit out struct clk* "on demand". For example, if I have an external PLL chip that provides 4 clocks, I can register a clock provider driver attached to that device-node (which can then also contain properties indicating to the driver how to program the said PLL chip if so desired). Then, if 2 of those lines (PLL1 and PLL3) go respectively to a device SYS_CLK and PHY_CLK inputs, for example, then all I need is to have a "clock-names" and "clock-map" properties in that device node. The first one contains "SYS_CLK" and "PHY_CLK", and the second one, a list of two items, each being the the phandle to the PLL and respectively 1 and 3. I could just parse the tree and generate all the struct clk* at boot time and somewhat generate clkdev for them etc... but I believe that isn't needed, ie, clkdev is an ARM specific mechanism for expressing the linkage between devices and clock sources but not something that we would benefit from moving over since we can do better, I believe, with the device-tree. Or am I missing something still ? :-) Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
