From: Javier Martinez Canillas <javierm@redhat.com>
To: Marcus Folkesson <marcus.folkesson@gmail.com>
Cc: David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Thomas Zimmermann <tzimmrmann@suse.de>
Subject: Re: [PATCH v3 2/3] drm/st7571-i2c: add support for Sitronix ST7571 LCD controller
Date: Wed, 09 Apr 2025 11:43:54 +0200 [thread overview]
Message-ID: <87bjt5fz51.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <Z_YWq4ry6Y-Jgvjq@gmail.com>
Marcus Folkesson <marcus.folkesson@gmail.com> writes:
Hello Marcus,
[...]
>>
>> That's a god question, I don't really know...
>>
>> But fbdev does support XRGB8888, which may be another good reason to add
>> it and make it the default format. Yes, it will cause an unnecessary pixel
>> format conversion but the I2C transport is so slow anyways that compute is
>> not the bottleneck when using these small displays.
>
> Hrm, I now realised that I have another issue.
> Not all LCDs that will be attached to the ST7571 controller will be
> grayscale.
> The display I've attached to the ST7571 is a monochrome LCD for example.
>
Oh, that's very interesting. This means that vendors are using a more capable IC
(i.e: ST7571) for display controllers + LCD panels board designs, even where they
could had used a less capable one (i.e: ST7765). That is, using an IC that supports
2-bit grayscale when they could just used one that only supported monochrome pixels.
From a quick search, I found for example this one from SinoCrystal:
https://displaysino.com/product_details/SC128128012-V01.html
> Maybe the right way to do it is to only support XRGB8888 and specify
> if the display is monochrome or grayscale in the device tree.
>
> Or do you have any good suggestions?
>
I don't know the proper way to handle this, but what I would do is to include
the actual boards as entries in the OF device ID table instead of just the ICs.
And then for each entry you can specify what formats are supported, e.g:
static const uint32_t monochrome_formats[] = {
DRM_FORMAT_XRGB8888,
DRM_FORMAT_R1
};
static const uint32_t grayscale_formats[] = {
DRM_FORMAT_XRGB8888,
DRM_FORMAT_R1
DRM_FORMAT_R2
};
static const struct of_device_id st7571_of_match[] = {
/* monochrome displays */
{
.compatible = "sinocrystal,sc128128012-v01",
.data = monochrome_formats,
},
...
/* grayscale displays */
{
.compatible = "foo,bar",
.data = grayscale_formats,
},
};
and then in your probe callback, you can get the correct format list for
the device matched. Something like the following for example:
static int st7571_probe(struct i2c_client *client) {
const uint32_t *formats = device_get_match_data(client->dev);
...
ret = drm_universal_plane_init(..., formats, ...);
...
};
Likely you will need to define more stuff to be specific for each entry, maybe
you will need different primary plane update handlers too. Similar to how I had
to do it the ssd130x driver to support all the Solomon OLED controller families:
https://elixir.bootlin.com/linux/v6.11/source/drivers/gpu/drm/solomon/ssd130x.c#L1439
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2025-04-09 9:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 7:04 [PATCH v3 0/3] Add support for Sitronix ST7571 LCD controller Marcus Folkesson
2025-04-08 7:04 ` [PATCH v3 1/3] dt-bindings: display: Add Sitronix ST7571 LCD Controller Marcus Folkesson
2025-04-08 16:16 ` Conor Dooley
2025-04-08 7:04 ` [PATCH v3 2/3] drm/st7571-i2c: add support for Sitronix ST7571 LCD controller Marcus Folkesson
2025-04-08 10:44 ` Javier Martinez Canillas
2025-04-08 11:01 ` Thomas Zimmermann
2025-04-08 11:34 ` Javier Martinez Canillas
2025-04-08 13:20 ` Marcus Folkesson
2025-04-08 13:57 ` Thomas Zimmermann
2025-04-08 14:58 ` Marcus Folkesson
2025-04-09 7:22 ` Thomas Zimmermann
2025-04-09 6:11 ` Javier Martinez Canillas
2025-04-09 6:41 ` Marcus Folkesson
2025-04-09 9:43 ` Javier Martinez Canillas [this message]
2025-04-09 13:25 ` Marcus Folkesson
2025-04-09 14:15 ` Javier Martinez Canillas
2025-04-11 6:47 ` Geert Uytterhoeven
2025-04-11 6:03 ` Marcus Folkesson
2025-04-11 8:26 ` Javier Martinez Canillas
2025-04-12 6:56 ` Marcus Folkesson
2025-04-14 7:55 ` Javier Martinez Canillas
2025-04-24 6:36 ` Marcus Folkesson
2025-04-24 6:45 ` Javier Martinez Canillas
2025-04-08 7:04 ` [PATCH v3 3/3] MAINTAINERS: add entry for Sitronix ST7571 LCD Controller Marcus Folkesson
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=87bjt5fz51.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=airlied@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marcus.folkesson@gmail.com \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=tzimmrmann@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;
as well as URLs for NNTP newsgroup(s).