Re: [PATCH v3 2/2] drm/tiny: add support for PIXPAPER 4.26 monochrome e-ink panel

[LiangCheng Wang <zaq14760@gmail.com>]

Hi Thomas,

Thank you for the quick reply.

> Where exactly are these ssd16xx patches. I cannot find them in the DRM
> trees. I presume they are not upstream yet?

That is right, they are not upstream. Devarsh posted them on 1 May and
the series is still at v1 on the list:

  [PATCH 0/6] Add DRM driver for Solomon SSD16xx e-paper display controllers
  https://lore.kernel.org/all/20260430183311.2978142-1-devarsht@ti.com/

One thing that is easy to miss, and that I should have made clearer in my
last mail: that v1 series covers the SSD1683 only. The SSD1677, which is
the controller on the PIXPAPER 4.26m, is not part of it. Devarsh has
SSD1677 support in a staged branch that he kindly shared with me in July,
and that is what I tested on the panel:

  https://github.com/devarsht/linux-next/commits/ssd16xx_7_2/

Those SSD1677 patches have not been posted to the list yet, which is why
the panel support has not had anything to build on so far.

> If there's support for similar ICs, I'd strongly prefer to have the
> ssd1677 be part of that instead of a stand-alone driver.
>
> Once the stand-alone driver is in place, users will rely on it. Then it
> becomes hard to replace. We had (have?) cases where there are several
> drivers for the same hardware.

Understood, and thank you for explaining the reasoning - the point about
users coming to depend on a driver that is then hard to replace makes
sense, and I would rather not create that problem. I will drop the
standalone driver and add the PIXPAPER 4.26m to ssd16xx instead, once the
shared driver is in.

Devarsh, thank you again for sharing the branch, and for making room for
the panel in your work in the first place. I am glad to keep testing
SSD1677 on real hardware whenever that is useful to you.

Regards,
LiangCheng