linux-kernel - Re: [PATCH 3/9] drm/panel: simple: make it possible to override LCD bus format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Oct 2017 14:56:42 +0200
From:   Thierry Reding <thierry.reding@...il.com>
To:     Lothar Waßmann <LW@...O-electronics.de>
Cc:     David Airlie <airlied@...ux.ie>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/9] drm/panel: simple: make it possible to override LCD
 bus format

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)