On Mon, Aug 20, 2012 at 10:16 AM, Shawn Guo <[email protected]> wrote: > On Mon, Aug 20, 2012 at 09:54:48AM -0500, Matt Sealey wrote: >> Yet another arbitrary array... >> >> I'm not sure why you would move the registration lookup into the DT > > Because I do not want to patch kernel every time I need a new lookup. > Furthermore, looking at function imx53_qsb_init in imx53-dt.c, you > will find that lookup for sgtl5000 is really board specific and should > go to device tree. > >> and use an arbitrarily ordered array again. Sure, you're looking it up >> entirely within the device tree here, but a better solution would be >> to not name clocks twice, and structure your clock definition >> properly. >> >> What's wrong with; >> >> ccm@020c4000 { >> ... >> my_clock: clock@0 { >> name = "my_clock_name"; >> } >> } >> >> uart@nnnnnnnn { >> ... >> clocks = <&my_clock>; >> } >> >> ? >> > It turns a property into 185 nodes, which will just bloat the device > tree. This issue has been discussed for a plenty of times.
It's not bloat just because it is by its very definition "a big list", is it? How do you explain duplicating the clock names in the array AND in the device node as NOT being bloated? You're going to have to define these clocks as a tree with parents and leaf nodes anyway in the clock subsystem. Why not define these in the device tree in total and reference them by handle when you build the entire clock tree from the ground up? Or will it just be all the clocks defined in Linux, but the lookups (which is what I see here) moved into the DT? Why not form the lookups as part of the definition of the clock tree? -- Matt Sealey <[email protected]> Product Development Analyst, Genesi USA, Inc. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
