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]
Message-ID: <20171017125642.GE27983@ulmo>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ