Re: [PATCH v2 06/15] dt: binding: add binding for ImgTec IR block

[Mark Rutland <mark.rutland@arm.com>]

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@imgtec.com> 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@imgtec.com> 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.

> 
> 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?

I really don't think it makes sense to say that clock-names doesn't
define the list.

Thanks,
Mark.