On Tue, Oct 17, 2017 at 7:56 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Tue, Oct 17, 2017 at 02:44:23PM +0200, Lothar Waßmann wrote: >> Hi, >> >> On Tue, 17 Oct 2017 14:12:40 +0200 Thierry Reding wrote: >> > On Wed, Oct 11, 2017 at 01:23:35PM +0200, Lothar Waßmann wrote: >> > > The baseboards for the Ka-Ro electronics series of i.MX modules >> > > use a 24bit LCD interface, no matter what LCD bus width the SoC on the >> > > module provides and what the LCD panel expects. LCDs with 6bit per color >> > > will ignore the 2 LSBs of each color lane, and modules using a SoC >> > > that provides only 6bit per color, drive the display information on the >> > > 6 MSBs of each color lane and tie the 2 LSBs of each color lane to GND. >> > > >> > > Thus, no matter what combination of LCD and SoC is used, the LCD port >> > > can be used without shuffling bit lanes by always configuring the LCD >> > > output to 24bit mode. >> > > >> > > Add a function to handle certain quirks of the LCD interface to the >> > > panel driver to be able to override the bus format specified in a >> > > panel's display_mode. >> > >> > I think the above paragraph clearly indicates that this is the wrong >> > place to workaround this. You say yourself that the LCD interface has >> > quirks that need to be handled, so why do you want to force this >> > handling into the panel driver? >> > >> The quirk is in the interfacing of the SoM's LCD output to the LCD >> panel. Thus it can be handled in either place. > > Yes. What I'm saying is that the panel is, in my opinion, the wrong > place to handle an LCD interface (originating from the SoM) quirk. There's 2 possible things we could need to describe here. First, is any restrictions the SoM has. For example, the SoM has an 18-bit interface while the SoC has a 24-bit interface. Second, is how a panel with fewer bits than the interface (whether a SoM or direct to SoC) is wired up. If we think about this in terms of a base DT plus overlays, then the former case belongs in the base and the latter belongs in the overlay. If the SoM interface needs to be SoC independent, then it gets more complicated as we don't want to have the SoC's LCD controller node in the overlay adding properties to it and therefore need to have some sort of translation (i.e. a connector binding). But we have no definition of how we would describe OF graph thru a connector. In the end, these are board level properties, so you can make the same argument that this property doesn't belong in the SoC's LCD controller node as you can it doesn't belong in the panel node. Generally, we just default to the node bound to the driver we want to handle the property. In any case, I think this should be properties of the endpoints rather than the endpoint parent nodes as it is a property of the interface, not the controller nor the panel. This is also how camera interfaces were done. An LCD controller node could have 2 interfaces for example. >> > The panel remains the same, no matter what interface you connect it to. >> > >> Because that's just ONE place to change, no matter what LCD driver is >> being used. > > That's a Linux specific implementation detail. If you ever want to use > a panel that is not driven by simple-panel you'd have to change it in > that driver, too. I do agree the implementation belongs in the LCD controller side, but just because the property is in the panel node that doesn't mean it's the panel driver that has to handle the property. As long as the property is parse-able in a standard way, the "parent" can do it. There are cases where the driver tied to the parent node handles properties in the child nodes. SPI timing modes is one example. In this case, I think we'll need to handle this property being in the local endpoint and the remote endpoint and resolving the format needed based on that (as well as what the panel driver says). That's going to be needed with overlays and connectors anyways and then you don't really have to care where the restriction comes from. Rob -- 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
