From: Javier Martinez Canillas <javierm@redhat.com>
To: Conor Dooley <conor@kernel.org>
Cc: linux-kernel@vger.kernel.org, Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rob Herring <robh@kernel.org>,
Peter Robinson <pbrobinson@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Conor Dooley <conor+dt@kernel.org>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers
Date: Sun, 17 Dec 2023 23:00:07 +0100 [thread overview]
Message-ID: <87cyv4mqvs.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20231217-hunk-cross-4bf51740957c@spud>
Conor Dooley <conor@kernel.org> writes:
Hello Conor,
> On Sun, Dec 17, 2023 at 10:33:24PM +0100, Javier Martinez Canillas wrote:
[...]
>> >> + then:
>> >> + properties:
>> >> + width:
>> >> + default: 96
>> >> + height:
>> >> + default: 64
>> >
>> > Do you envisage a rake of devices that are going to end up in this
>> > binding? Otherwise, why not unconditionally set the constraints?
>> >
>>
>> Because these are only for the default width and height, there can be
>> panels using the same controller but that have a different resolution.
>>
>> For example, there are panels using the SSD1306 controller that have
>> 128x32 [0], 64x32 [1] or 128x64 [2] resolutions.
>
> This, as you know, does not matter here.
>
Are you sure? What I tried to say is that the SSD133x are just OLED
controllers and manufacturers use those chips to attach a panel that
has a certain resolution.
While it makes sense to use all the supported width and height, some
manufacturers chose to have a smaller panel instead (I used SSD1306
as an example because I knew about these but the same might be true
for let's say SSD1331).
Or saying another way, are you sure that every manufacturer selling
RGB OLED panels using the SSD1331 chip will use the default resolution
and users won't have to set a custom width and height ?
I have already chosen to make the DT binding as simple as possible to
prevent what happened with the SSD1306 "solomon,page-offset" property
that has a broken default [0] but I think that not allowing to set the
resolution is already too restrictive and would make it unusable for
any panel that doesn't have the default width and height.
[0]: https://lists.freedesktop.org/archives/dri-devel/2023-November/431150.html
>> But answering your question, yes I think that more devices for this
>> SSD133x family are going to be added later. Looking at [3], there is
>> at least SSD1333 that has a different default resolutions (176x176).
>
> That's fair enough though. I'd probably err on the side of introducing
> this complexity when the other users actually show up though.
>
Agree and the reason why I did not include entries for the SSD1332 and
SSD1333. I was planning to add those only if there were users since it
seems that the SSD1331 is the most popular controller from this family.
But as explained, even for the SSD1331 it may be needed to set a width
and height that is different than the default of this panel controller.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2023-12-17 22:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-17 10:07 [PATCH 0/2] drm/solomon: Add support for the SSD133x controller family Javier Martinez Canillas
2023-12-17 10:07 ` [PATCH 1/2] dt-bindings: display: Add SSD133x OLED controllers Javier Martinez Canillas
2023-12-17 20:52 ` Conor Dooley
2023-12-17 21:33 ` Javier Martinez Canillas
2023-12-17 21:43 ` Conor Dooley
2023-12-17 22:00 ` Javier Martinez Canillas [this message]
2023-12-17 22:32 ` Conor Dooley
2023-12-17 22:46 ` Javier Martinez Canillas
2023-12-18 7:34 ` Krzysztof Kozlowski
2023-12-18 8:42 ` Javier Martinez Canillas
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=87cyv4mqvs.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=airlied@gmail.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=geert@linux-m68k.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=pbrobinson@gmail.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--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