On 09/12/2013 12:10 PM, Pawel Moll wrote: > On Thu, 2013-09-12 at 16:23 +0100, Pawel Moll wrote: >> Anyway, I think I've got an idea how to render the problem custom panel >> properties invalid. If so, I'll send another version of the patch. > > So, instead of describing the panel I thought I'd go lower level and try > to describe the CLCD's signal functions. It gets down to something like > this: > > 8<---- > - arm,pl11x,panel-data-pads: array of 24 cells, each of them describing > a function of one of the CLD pads, > starting from 0 up to 23; each pad can > be described by one of the following values: > - 0: reserved (not connected) > - 0x100-0x107: color upper STN panel data 0 to 7 ... > Such approach would also solve problem with bizarre cases like the > Versatile's (not Express ;-) muxer Russell mentioned (where there is a > de-facto custom wiring used). And no, I had a look at pinmux bindings > and I don't think they fit here at all... > > Thoughts? I think pinctrl would work just fine here. However, I suspect there's little need for pinctrl. pinctrl is required when one module may impose requirements on another module's muxable pins. I assume that the configuration for pins on CLCD is only relevant for CLCD itself, so there's no need to export an interface by which something else can configure the pins. Now, if any of the pins could be e.g. "GPIO", then this argument might not apply. Hence, I think pinctrl is only "possible" here, not "required", and the approach above seems fine to me. -- 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
