On Fri, Feb 7, 2014 at 8:50 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > Hi Rob, > > On Fri, Feb 07, 2014 at 02:33:27PM +0000, Rob Herring wrote: >> 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. > > If they're optional then you can't handle optional entries (i.e. when > nothing's wired to an input), and this is counter to the style I've been > recommending to people (defining clocks in terms of clock-names). > > I really don't see the point in any *-names property if they don't > define the list and allow for optional / reordered lists. Why does the > order have to be fixed rather than using the -names properties? It's > already a de-facto standard. Maybe for clocks, but I don't think we should treat clocks differently from other properties. We've already got enough variation in binding styles, I'd like to be consistent across interrupts, reg, clocks, etc. >> 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 > > For more complex IP blocks you might have more inputs than you actually > have clocks wired to. > > How do you handle an unwired input in the middle of the list, or a new > revision of the IP block that got rid of the first clock input from the > list but is otherwise compatible? fixed-clock with freq of 0 for unwired (really wired to gnd) inputs? With a new compatible string if it is a new block. 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
