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

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 17.09.26 um 12:49 schrieb 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@gmail.com> 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.

I cannot advice anything here, but at least I'd like to get ssd16xx out 
of tiny/. It would be great to have it all under solomon/. It looks like 
sitronix/ does a similar thing.

Best regards
Thomas

>
>> 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.
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)