Devicetree
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javierm@redhat.com>
To: Amit Barzilai <amit.barzilai22@gmail.com>,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
	robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	andy@kernel.org, gregkh@linuxfoundation.org, deller@gmx.de
Cc: azuddinadam@gmail.com, chintanlike@gmail.com,
	dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
	linux-staging@lists.linux.dev,
	Amit Barzilai <amit.barzilai22@gmail.com>
Subject: Re: [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family
Date: Mon, 29 Jun 2026 12:13:24 +0200	[thread overview]
Message-ID: <87jyrhd58b.fsf@ocarina.mail-host-address-is-not-set> (raw)
In-Reply-To: <20260622152506.78627-3-amit.barzilai22@gmail.com>

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

Hello Amit,

Thanks for doing a re-spin and adding the SSD1351 support to the
ssd130x driver. This is much closer to what I had in mind than v1.

[...]

>  
>  const struct ssd130x_deviceinfo ssd130x_variants[] = {
> @@ -206,6 +212,7 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
>  	[SSD1331_ID] = {
>  		.default_width = 96,
>  		.default_height = 64,
> +		.format_rgb565 = 1,
>  		.family_id = SSD133X_FAMILY,
>  	}

[...]

>  
>  	iosys_map_set_vaddr(&dst, data_array);
> -	drm_fb_xrgb8888_to_rgb332(&dst, &dst_pitch, vmap, fb, rect, fmtcnv_state);
> +	if (ssd130x->device_info->format_rgb565)
> +		drm_fb_xrgb8888_to_rgb565be(&dst, &dst_pitch, vmap, fb, rect, fmtcnv_state);
> +	else
> +		drm_fb_xrgb8888_to_rgb332(&dst, &dst_pitch, vmap, fb, rect, fmtcnv_state);
>

Since you are changing the SSD1331_ID to use .format_rgb565, what's the
value of keeping the RGB323 support ? It's not used by any other Solomon
family supported by the driver.

Ideally, we would like the driver to expose native formats besides the
virtualized XRGB8888. Geert posted some patches for SSD1301 some time ago:

https://lists.freedesktop.org/archives/dri-devel/2023-August/419937.html

but that never landed.

If that was the case, then SSD130X could expose DRM_FORMAT_XRGB8888 and
DRM_FORMAT_R1; SSD132X would expose DRM_FORMAT_XRGB8888 and DRM_FORMAT_R4 and
SSD133X expose DRM_FORMAT_XRGB8888, DRM_FORMAT_RGB332 and DRM_FORMAT_RGB565.

Given that we don't have that, I suppose that we could just get rid of the
DRM_FORMAT_RGB332 support for SSD133X and just default to DRM_FORMAT_RGB565.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat


  parent reply	other threads:[~2026-06-29 10:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22 15:25 [PATCH v2 0/4] drm/ssd130x: Add support for the Solomon SSD1351 OLED controller Amit Barzilai
2026-06-22 15:25 ` [PATCH v2 1/4] dt-bindings: display: Add " Amit Barzilai
2026-06-23  8:43   ` Krzysztof Kozlowski
2026-06-22 15:25 ` [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family Amit Barzilai
2026-06-23  9:03   ` Andy Shevchenko
2026-06-28 15:43     ` [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support Amit Barzilai
2026-06-29  6:19       ` Andy Shevchenko
2026-06-28 16:30     ` [PATCH v2 2/4] drm/ssd130x: Add RGB565 support to SSD133X family Amit Barzilai
2026-06-29 10:13   ` Javier Martinez Canillas [this message]
2026-06-30 14:04     ` Amit Barzilai
2026-06-22 15:25 ` [PATCH v2 3/4] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support Amit Barzilai
2026-06-23  9:05   ` Markus Elfring
2026-06-23 21:34     ` Amit Barzilai
2026-06-24  6:27       ` Markus Elfring
2026-06-23  9:37   ` Andy Shevchenko
2026-06-22 15:25 ` [PATCH v2 4/4] staging: fbtft: remove fb_ssd1351 driver Amit Barzilai
2026-06-23  7:55   ` Maxime Ripard
2026-06-23  8:41   ` Andy Shevchenko
2026-06-23  8:50     ` Javier Martinez Canillas
2026-06-23 20:28       ` Amit Barzilai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87jyrhd58b.fsf@ocarina.mail-host-address-is-not-set \
    --to=javierm@redhat.com \
    --cc=airlied@gmail.com \
    --cc=amit.barzilai22@gmail.com \
    --cc=andy@kernel.org \
    --cc=azuddinadam@gmail.com \
    --cc=chintanlike@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox