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. When I rewrote the way the CLCD driver handles the various panels, I did it with full information on how the hardware was being used at that time. That is precisely why I came up with the capability system, where we describe which formats the hardware can support up to the interface, separately from the formats which the attached device - be it a LCD panel, VGA socket or HDMI socket - can support. The resulting set of formats which can be used are a union of these. Suggesting that we can do this by putting register values into DT is completely wrong - if that were possible, I wouldn't have come up with this capability system to sort this mess out in the first place - I could've just hard-coded the register values and said to everyone "tough, on these platforms you only get RGB444 support and that's it." -- 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
