On Mon, Aug 19, 2013 at 10:50:43AM +0100, Nicolin Chen wrote: > Hi, > > On Mon, Aug 19, 2013 at 10:24:58AM +0100, Mark Rutland wrote: > > Is this used semantically, or is it a completely arbitrary string? In > > either case I don't see why the compatible string doesn't give the > > driver enough to have a sensible value. > > > > I'm confused as to why we need this. The phrase "user-visible" in a > > device description seems very odd. > > The string would be in the ALSA device list: > ALSA device list: > #0: imx-spdif > > I think it can be a sort of arbitrary as long as users know which this > device exactly is when they catch the name by 'aplay -l' or 'arecord -l' > > The phrase "user-visible" is being used in many current docs, I don't > dare to change it unless a sage gives me a suggestion. I can see that there is entrenched usage, but this really seems to be embedding Linux-specific implementation details into the dt. I don't see why the driver cannot select a sensible name, but perhaps I'm missing something. Mark, is there any reason we need to handle the user-visible name of the device this way? > > > > + > > > + - spdif-controller : The phandle of the i.MX S/PDIF controller > > > + > > > + > > > +Optional properties: > > > + > > > + - spdif-transmitter : The phandle of the spdif-transmitter dummy codec > > > + > > > + - spdif-receiver : The phandle of the spdif-receiver dummy codec > > > + > > > +* Note: At least one of these two properties should be set in the DT binding. > > > > Are all four units (comlpex,controller,transmitter,receiver) really > > separate blocks? > > At least they are separate drivers as I mentioned in the commit comments. I'm not sure that the boundary of Linux drivers should necessarily determine the way we carve up the description of IP blocks, though presumably it's a pretty sensible way of carving it up or we wouldn't have done it. Is there any public documentation on the i.MX S/PDIF hardware block(s)? Thanks, Mark. -- 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