On Thu, Feb 6, 2014 at 8:41 AM, James Hogan <james.hogan@xxxxxxxxxx> wrote: > Hi Rob, > > On 06/02/14 14:33, Rob Herring wrote: >> On Fri, Jan 17, 2014 at 7:58 AM, James Hogan <james.hogan@xxxxxxxxxx> wrote: >>> +Required properties: >>> +- compatible: Should be "img,ir1" >> >> Kind of short for a name. I don't have anything much better, but how >> about img,ir-rev1. > > Okay, that sounds reasonable. > >>> +Optional properties: >>> +- clocks: List of clock specifiers as described in standard >>> + clock bindings. >>> +- clock-names: List of clock names corresponding to the clocks >>> + specified in the clocks property. >>> + Accepted clock names are: >>> + "core": Core clock (defaults to 32.768KHz if omitted). >>> + "sys": System side (fast) clock. >>> + "mod": Power modulation clock. >> >> You need to define the order of clocks including how they are >> interpreted with different number of clocks (not relying on the name). > > Would it be sufficient to specify that "clock-names" is required if > "clocks" is provided (i.e. unnamed clocks aren't used), or is there some > other reason that clock-names shouldn't be relied upon? irq-names, reg-names, clock-names, etc. are considered optional to their associated property and the order is supposed to be defined. clock-names is a bit different in that clk_get needs a name, so it effectively is required by Linux when there is more than 1 clock. Really, we should fix Linux. Regardless, my other point is still valid. A given h/w block has a fixed number of clocks. You may have them all connected to the same source in some cases, but that does not change the number of inputs. Defining what are the valid combinations needs to be done. Seems like this could be: <none> - default to 32KHz <core> - only a "baud" clock <core>, <sys>, <mod> - all clocks Rob -- 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
