Message-ID: <CAL_JsqLhOmwjkj_OO=6umG2QwkWqQhAUQYL0WZUHhsV4LHXFyg@mail.gmail.com>
Date:   Tue, 17 Oct 2017 12:11:40 -0500
From:   Rob Herring <robh+dt@...nel.org>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Lothar Waßmann <LW@...o-electronics.de>,
        David Airlie <airlied@...ux.ie>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.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 7:56 AM, Thierry Reding
<thierry.reding@...il.com> 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

Powered by blists - more mailing lists