On Tue, 2009-08-18 at 14:21 +1000, Benjamin Herrenschmidt wrote: > So here's a followup to my discussion about the clock API.
Really nobody has a comment here ? :-) Not even Mitch ? Cheers, Ben. > I'm cooking up a patch that replace our current primitive implementation > in arch/powerpc/kernel/clock.c with something along the lines of what I > described. However, I want a bit more churn here on the device-tree > related bits. > > So, basically, the goal here is to define a binding so that we can link > a device clock inputs to a clock provider clock outputs. > > In general, in a system, there's actually 3 "names" involved. The clock > provider output name, the clock signal name, and the clock input name on > the device. However, I want to avoid involving the clock signal name as > it's a "global" name and it will just end up being a mess if we start > exposing that. > > So basically, it boils down to a device having some clock inputs, > referenced by names, that need to be linked to another node which is a > clock provider, which has outputs, references either by number or names, > see discussion below. > > First, why names, and not numbers ? IE. It's the OF "tradition" for > resources to just be an array, like interrupts, or address ranges in > "reg" properties, and one has to know what the Nth interrupt correspond > too. > > My answer here is that maybe the tradition but it's crap :-) Names are > much better in the long run, besides it makes it easier to represent if > not all inputs have been wired. Also, to some extent, things like PCI do > encode a "name" with "reg" or "assigned-addresses" properties as part of > the config space offset in the top part of the address, and that has > proved very useful. > > Thus I think using names is the way to go, and we should even generalize > that and add a new "interrupt-names" property to name the members of an > "interrupts" :-) > > So back to the subject at hand. That leaves us with having to populate > the driver with some kind of map (I call it clock-map). Ideally, if > everything is named, which is the best approach imho, that map would > bind a list of: > > - clock input name > - clock provider phandle > - clock output name on provider > > However, it's a bit nasty to mix strings and numbers (phandles) in a > single property. It's possible, but would likely lead to the phandle not > being aligned and tools such as lsprop to fail miserably to display > those properties in any kind of readable form. > > My earlier emails proposed an approach like this: > > - clock input names go into a "clock-names" property > (which I suggest naming instead "clock-input-names" btw) > > - the map goes into a "clock-map" property and for each input > provides a phandle and a one cell numerical ID that identifies > the clock on the source. > > However, I really dislike that numerical clock ID. Magic numbers suck. > It should be a string. But I don't want to add a 3rd property in there. > > Hence my idea below. It's not perfect but it's the less sucky i've come > up with so far. And then we can do some small refinements. > > * Device has: > > - "clock-input-names" as above > - "clock-map" contains list of phandle,index > > * Clock source has: > > - "clock-output-names" list of strings > > The "index" in the clock map thus would reference the > "clock-output-names" array in the clock provider. That means that the > "magic number" here is entirely local to a given device-tree, doesn't > leak into driver code, which continues using names. > > In addition, we can even have some smooth "upgrade" path from existing > "clock-frequency" properties by assuming that if "clock-output-names" is > absent, but "clock-frequency" exist, then index 0 references a fixed > frequency clock source without a driver. This could be generally handy > anyway to represent crystals of fixed bus clocks without having to write > a clock source driver for them. > > Any comments ? > > I'll post a patch, maybe later today, implementing the above (I may or > may not have time to also convert the existing 512x code to it, we'll > see). > > Cheers, > Ben. > > > > > > _______________________________________________ > devicetree-discuss mailing list > devicetree-disc...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
