Re: [PATCH 0/2] drm: Add driver for the Solomon SSD1351 OLED controller

[Javier Martinez Canillas <javierm@redhat.com>]

Amit Barzilai <amit.barzilai22@gmail.com> writes:

Hello Amit,

Thanks for your patches.

> This series adds a new DRM/KMS driver for the Solomon SSD1351, a 128x128
> 65k-color RGB OLED controller driven over a 4-wire SPI bus. The SSD1351
> currently has no DRM driver; the only in-tree support is the legacy fbtft
> fb_ssd1351.
>
> The driver advertises XRGB8888 to userspace and converts to big-endian
> RGB565 on flush via drm_fb_xrgb8888_to_rgb565be(), building on the GEM
> SHMEM and atomic modeset/shadow-plane helpers with damage-clipped partial
> updates.
>
> The SSD1351 is implemented as a standalone driver rather than as part of
> ssd130x. ssd130x converts XRGB8888 down to a packed <= 8bpp hardware
> format (mono, grayscale, or 256-colour RGB332); the SSD1351 is driven in
> its native 65k-colour RGB565 and does not fit that pixel pipeline.
>

I think that makes more sense to have the SSD1351 support as a part of the
ssd130x driver, rather than as a separate one. There is already support for
SSD133X in ssd130x and this family also supports the same 65k format than
used by SSD1351.

The correct approach in my opinion to add SSD1351 support is as follows:

1) Add support for 65k (DRM_FORMAT_RGB565) for the SSD133X_FAMILY.

2) Add support for the SSD135X_FAMILY with DRM_FORMAT_RGB565.

3) Optionally add support for the 256k color format to SSD135X_FAMILY
   but I don't think there's a native fourcc code for this. So likely
   you will need to do a XRGB8888 to native 256k format conversion.

By doing this way, not only SSD1351 will be supported by ssd130x but also
you could make the existing SSD133X support to use the 65k color depth.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat