linux-kernel - Re: [v4 4/4] drm/panel: Support for Starry-ili9882t TDDI MIPI-DSI panel

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: <CACRpkdZLgf15Ao6CPym6q2yC17XcA3kjtDCQ3F2-aa-XwZJ=xg@mail.gmail.com>
Date:   Fri, 7 Jul 2023 00:21:55 +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:58 PM Doug Anderson <dianders@...gle.com> wrote:

> > So the Ilitek ILI9882t is an obvious break-out.
>
> I guess. To me it feels like the concept of breaking the driver into
> multiple sub-drivers and the idea of supporting ILI9882t more cleanly
> are orthogonal. You could still do your patch #4 and break out the
> page switching function without breaking up the driver.

Yeah that's true. But with Ilitek in particular we have these nice
precedents:
drivers/gpu/drm/panel/panel-ilitek-ili9322.c
drivers/gpu/drm/panel/panel-ilitek-ili9341.c
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c

So it looks disorganized to me if this one Ilitek panel controller
now goes inside another driver with other completely unrelated
drivers.

> It feels to me fairly likely that many of the panels here are just as
> different from each other as the ILI9882t is from them. I guess it's
> not a dozen, but it feels like using the same "how different are they
> from each other" metric we'd end up with at least 5-6 new drivers. It
> seems clear to me that the panel that Sam first commented on is as
> different from the others in the BOE driver as the ILI9882t is.
> Certainly it has a pretty darn big unique command sequence for init...

It doesn't really matter until we can say certainly what display controller
each of them is. It seems we can't, but for this one we can.

> The problem is that it's hard for me to make a strong argument here
> when there is prior art of panels being supported with blob-sequences.
> In this case, I think you as an upstream developer have more leverage.
> I can help put pressure to make sure that upstream concerns are
> addressed, but I think it's on upstream to put their foot down and say
> that these blob sequences are not OK for new panels. In each case I
> landed a patch with a new blob sequence I tried to give the community
> time to respond and I tried to telegraph what I was going to do to
> make sure nobody was surprised...

I would say it is not fair to block driver coming from hobbyists or minor
vendors just trying to make something work. In general I think a working
something is better than nothing so I wouldn't block anything.

But with big companies who actually talk to Ilitek, Novotek and the other
companies ending with -tek that make these display controllers I would
certainly like to send the message that datasheets and proper
defines would be appreciated, and say it is also for their best, because
I mentioned proper gamma correction is possible if the driver author
just invest time and works with the DRM community and that should
be in their best interest. Feel free to pass this along the supply
chain if you can.

Yours,
Linus Walleij