From: Amit Barzilai <amit.barzilai22@gmail.com>
To: Javier Martinez Canillas <javierm@redhat.com>,
Andy Shevchenko <andriy.shevchenko@intel.com>,
dri-devel@lists.freedesktop.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Amit Barzilai <amit.barzilai22@gmail.com>
Subject: [PATCH v3 0/3] drm/ssd130x: Add support for the Solomon SSD1351 OLED controller
Date: Sat, 4 Jul 2026 11:09:22 +0300 [thread overview]
Message-ID: <20260704080925.75113-1-amit.barzilai22@gmail.com> (raw)
This series adds support for the Solomon SSD1351, a 128x128 65k-color
RGB OLED controller, to the ssd130x DRM driver:
- Patch 1 adds the device tree binding.
- Patch 2 switches the SSD133X family from RGB332 to RGB565, bringing
65k color to the SSD1331.
- Patch 3 adds the SSD1351 as a new SSD135X_FAMILY, reusing the
SSD133X plane/CRTC and blit/clear helpers. The only data-path
difference is the explicit Write RAM command (0x5c) the SSD1351
needs before pixel data; it also gets its own init sequence.
Testing:
- The SSD1351 (patches 1 and 3) is tested on hardware.
- The SSD1331 RGB565 change (patch 2) is compile-tested only; I do not
currently have a working SSD1331 panel. Javier has kindly offered to
test it on his SSD1331.
Dependency:
The SSD1351 reuses ssd133x_update_rect(), which programs the column
and row *end* address as a relative offset rather than an absolute
coordinate. This breaks partial updates that do not start at (0,0). A
separate fix is posted at [2]; until it lands, the SSD1351 shows the
same partial-redraw artifacts. This series applies independently of
that fix, but the two are best merged together.
Backlight:
While adding the SSD1351 I noticed that the shared backlight path
(ssd130x_update_bl()) is only correct for the SSD130X and SSD132X
families, where 0x81 is the contrast command. On the SSD133X, 0x81 is
"Set Contrast for Color A", so brightness changes shift the color
balance rather than dim the panel. On the SSD1351, 0x81 is not
implemented at all and the brightness byte itself would be executed
as a command opcode (e.g. 0xae is Display OFF). This series therefore
does not register a backlight device for the SSD135X family. I plan a
follow-up making the backlight path family-aware (scaling
0x81/0x82/0x83 together for SSD133X, 0xc1 contrast A/B/C for
SSD135X), which would also fix the existing SSD1331 behavior. Happy
to reorder if you would prefer that rework to land first.
Based on drm-misc-next. Note that the series depends on
ssd130x_run_cmd_seq() (commit 208211646fb3 ("drm/solomon: add
ssd130x_run_cmd_seq() for batch command execution")), which is in
drm-misc-next but not yet in mainline.
Thanks to Javier, Andy and Krzysztof for the reviews.
[1] v2 of this series:
https://lore.kernel.org/dri-devel/20260622152506.78627-1-amit.barzilai22@gmail.com
[2] ssd132x/ssd133x update_rect end-address fix:
https://lore.kernel.org/dri-devel/20260622122604.32500-1-amit.barzilai22@gmail.com
---
Changes since v2 [1]:
- Drop patch 4 (staging fbtft fb_ssd1351 removal); it was agreed that
the fbtft driver stays.
- Patch 2: remove RGB332 support entirely and drive the SSD133X family
at RGB565 unconditionally, instead of adding a per-variant format
flag to the deviceinfo struct (per Javier). Retitled accordingly.
- Patch 3: drop the 120 ms post-reset msleep(); it was a generic fbtft
value, not an SSD1351 datasheet figure. Retested on hardware without
it. A comment noting this is left in ssd130x_reset() (per Andy).
- Patch 3: explain the ssd130x_write_data() constification in the
commit message (per Andy).
- Add trailing commas to non-terminator array/enum entries and drop
the comma from the init-sequence terminator (per Andy).
- Declare the loop variable inside the for statement in
ssd130x_write_cmd() (per Andy).
- Split declaration and assignment of ret in ssd133x_write_pixels()
(per Andy).
- Fix comment wording/plurals ("3, 3 and 2 bits") (per Andy).
- Patch 3: skip backlight device registration for the SSD135X family;
the shared backlight path would execute the brightness byte as a
command opcode on the SSD1351. To be addressed by a follow-up making
the backlight path family-aware (see the Backlight section above).
- Collect Reviewed-by tags on patch 1.
Amit Barzilai (3):
dt-bindings: display: Add Solomon SSD1351 OLED controller
drm/ssd130x: Change SSD133X color format to RGB565 from RGB332
drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support
.../bindings/display/solomon,ssd1351.yaml | 42 +++
drivers/gpu/drm/solomon/ssd130x-spi.c | 7 +
drivers/gpu/drm/solomon/ssd130x.c | 289 ++++++++++++++----
drivers/gpu/drm/solomon/ssd130x.h | 5 +-
4 files changed, 278 insertions(+), 65 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/solomon,ssd1351.yaml
--
2.54.0
next reply other threads:[~2026-07-04 8:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-04 8:09 Amit Barzilai [this message]
2026-07-04 8:09 ` [PATCH v3 1/3] dt-bindings: display: Add Solomon SSD1351 OLED controller Amit Barzilai
2026-07-04 8:17 ` sashiko-bot
2026-07-04 8:09 ` [PATCH v3 2/3] drm/ssd130x: Change SSD133X color format to RGB565 from RGB332 Amit Barzilai
2026-07-04 8:23 ` sashiko-bot
2026-07-04 8:09 ` [PATCH v3 3/3] drm/ssd130x: Add SSD135X_FAMILY and SSD1351 support Amit Barzilai
2026-07-04 8:26 ` sashiko-bot
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=20260704080925.75113-1-amit.barzilai22@gmail.com \
--to=amit.barzilai22@gmail.com \
--cc=airlied@gmail.com \
--cc=andriy.shevchenko@intel.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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