On 09/23/2013 10:43 AM, Russell King - ARM Linux wrote: > On Mon, Sep 23, 2013 at 10:30:15AM -0600, Stephen Warren wrote: >> On 09/23/2013 10:06 AM, Russell King - ARM Linux wrote: >>> On Mon, Sep 23, 2013 at 10:03:18AM -0600, Stephen Warren wrote: >>>> It sounds like you could just put LCDControl & 0x2e in the DT rather >>>> than using values such as 0x100..0x107, which don't appear to match the >>>> register format you mentioned above. >>> >>> No. Platforms which route the outputs to something like VGA or HDMI can >>> change the framebuffer format. Your suggestions is far too restrictive. >> >> Surely the DT should describe the HW setup only. Usually, a particular >> HW setup can support multiple different framebuffer formats. Hence, the >> DT wouldn't/shouldn't imply anything about the framebuffer format, but >> simply which wires are connected to the LCD. > > Quite, and putting the contents of the LCDControl register - even just > bits 5 and 3-1 results in you having to modify the DT and reboot the > kernel just to change the framebuffer format. That's why I'm objecting > to your comment. Oh, so these particular registers define both the output signal muxing for the pins and the FB data format? If so, yes it's not correct to put the register values into DT. I assumed that the HW would have a separate representation of those two concepts, in different registers or at least different fields in the same register. If not, there is indeed no choice but to make up some arbitrary values to represent just the pinmuxing :-( -- 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
