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. > > 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. Thierry
Attachment:
signature.asc
Description: PGP signature
