[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYif_h38TYDuSjY-0WkWNknFOe8n2Xe7zBydKxySrdZHA@mail.gmail.com>
Date: Thu, 6 Jul 2023 23:36:29 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Doug Anderson <dianders@...gle.com>
Cc: Cong Yang <yangcong5@...qin.corp-partner.google.com>,
neil.armstrong@...aro.org, conor+dt@...nel.org,
devicetree@...r.kernel.org, sam@...nborg.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
hsinyi@...gle.com
Subject: Re: [v4 4/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel
On Thu, Jul 6, 2023 at 11:25 PM Doug Anderson <dianders@...gle.com> wrote:
> In my mind it's really a tradeoff and I'm happy to go with whatever
> consensus that others agree with. What I'm never super happy with,
> though, is changing the bikeshed color too often, so I'd be really
> curious to hear Sam's thoughts on the issue and whether he'd like to
> see this driver broken out into a dozen drivers.
This is not question about a dozen drivers, to be clear.
I just want to break out the drivers that have an identifiable
display controller that differs from the others, especially this one.
The rest of the drivers inside of this boe driver I can't really tell,
they seem related? We don't know?
So the Ilitek ILI9882t is an obvious break-out.
For the rest, I guess I would be happier if the Chromium people
could use their leverage with vendors to muscle out the details
about display controller vendors and provide #defines for all
magic commands, we all dislike these opaque firmware-looking
jam tables.
Cong already stated that he indeed has the datasheet for the
ILI9882t controller at hand, had I come in earlier I would have
asked for all of those sequences to be provided with proper
#defines instead of 0xff 0x98 0x82 0x01... but I'm late to the
show.
Yours,
Linus Walleij
Powered by blists - more mailing lists