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

[Javier Martinez Canillas]

Hello LiangCheng,

Thanks Thomas for CC'ing me since I missed this patch series.

On Thu, Sep 17, 2026 at 4:57 AM LiangCheng Wang <zaq14760@xxxxxxxxx> wrote:
>
> Hi Thomas,
>
> > There's also the ssd130x driver under solomon/ how does it related to
> > the ssd16xx? Is that similar as well?
>
> They share the vendor, but not much else as far as I can tell - Javier
> will know ssd130x far better than I do.
>
> It is an OLED driver over regmap, while ssd16xx is e-paper over raw SPI
> with a BUSY handshake, RAM address windows and waveform LUTs.  The
> register maps do not overlap, so I doubt there is much the two could
> share.
>

Correct, I don't think there is much overlap between the ssd13xx and
ssd16xx families.

There are a few bits that I think are similar though and could be
reused, for example the pixpaper_spi_write() helper logic is basically
the same than ssd130x_spi_write() AFAICT.

Same for pixpaper_send_cmd() and pixpaper_send_data(), I believe that
is the same logic that we now have in ssd130x_write_cmds(). Specially
after the recent commit 3e391b0b516b ("drm/ssd130x: Add SSD135X_FAMILY
and SSD1351 support") that introduced a cmd_params_are_data flag that
allows to send the operation as command and the parameters as data.

So the MCU interface seems to be the same, in particular for the
4-wire SPI interface which AFAIU is what this new SSD1677 driver
supports.

> Its shape does look like a good model though - one driver covering three
> sub-families through a variant table.  And if you would prefer ssd16xx to
> sit in drivers/gpu/drm/solomon/ next to it, that is fine by me.
>

I think that's a good idea, as I mentioned above some of the helpers
used by ssd130x could be factored out in a solomon-common.{h,c} or
something and be shared by both driver ssd130x and ssd16xx drivers (in
insight I should had called ssd13xx to the driver since now it
supports SSD130X, SSD132X, SSD133X and SSD135X families...).

> > If the ssd16xx does not make progress, we could also try to merge your
> > code as ssd16xx and Devarsh would then add support for additional ICs on
> > top.
>
> Thank you - I would be glad to help that way if it comes to it.
>

Agreed. The ssd16xx driver could do the same than ssd130x and support
both SSD1677 and SSD1683. They seem to be quite similar by looking at
the datasheets publicly available.

> Devarsh, it is your series though, so please say if you would rather carry
> it yourself; I would only pick it up with your agreement.
>
> I should also be honest about what I could offer: only what the SSD1677
> and the PIXPAPER 4.26m need, arranged so that further controllers can be
> added on top.  This panel is the only SSD16xx hardware I have, so I could
> not implement or test the others.  If that is too small a starting point,
> I quite understand.
>

That's OK. When I introduced the ssd130x driver, it only supported the
SSD1306 controller and over time we added suppport for more ICs and
13xx families.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat