[PATCH 0/4] auxdisplay: Add support for TM1637 7-segment display driver

Siratul Islam posted 4 patches 3 weeks, 4 days ago
.../ABI/testing/sysfs-platform-tm1637         |  20 ++
.../bindings/auxdisplay/titanmec,tm1637.yaml  |  43 +++
.../devicetree/bindings/vendor-prefixes.yaml  |   2 +
MAINTAINERS                                   |   7 +
drivers/auxdisplay/Kconfig                    |  11 +
drivers/auxdisplay/Makefile                   |   1 +
drivers/auxdisplay/tm1637.c                   | 297 ++++++++++++++++++
7 files changed, 381 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-platform-tm1637
create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm1637.yaml
create mode 100644 drivers/auxdisplay/tm1637.c
[PATCH 0/4] auxdisplay: Add support for TM1637 7-segment display driver
Posted by Siratul Islam 3 weeks, 4 days ago
This series adds a driver for the Titan Micro TM1637 7-segment display
controller.

The TM1637 uses a custom two-wire protocol (CLK/DIO) that resembles I2C
but lacks a slave address, requiring a bit-banging implementation.

The driver exposes standard sysfs attributes for 'message' (text) and
'brightness'. It handles standard ASCII-to-7-segment mapping using the
kernel's map_to_7segment utility.

Note on implementation:
This driver is implemented as a standalone platform driver rather than
using the auxiliary display 'linedisp' framework. The TM1637 protocol
requires manual handling of the decimal point (merging it with the
previous digit), which is difficult to achieve cleanly with the current
linedisp character buffer abstraction.

Siratul Islam (4):
  dt-bindings: vendor-prefixes: Add titanmec
  dt-bindings: auxdisplay: Add titanmec,tm1637
  auxdisplay: tm1637: Add driver for TM1637
  MAINTAINERS: Add entry for TM1637

 .../ABI/testing/sysfs-platform-tm1637         |  20 ++
 .../bindings/auxdisplay/titanmec,tm1637.yaml  |  43 +++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 MAINTAINERS                                   |   7 +
 drivers/auxdisplay/Kconfig                    |  11 +
 drivers/auxdisplay/Makefile                   |   1 +
 drivers/auxdisplay/tm1637.c                   | 297 ++++++++++++++++++
 7 files changed, 381 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-tm1637
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm1637.yaml
 create mode 100644 drivers/auxdisplay/tm1637.c

--
2.47.3
Re: [PATCH 0/4] auxdisplay: Add support for TM1637 7-segment display driver
Posted by Andy Shevchenko 3 weeks, 4 days ago
On Tue, Jan 13, 2026 at 6:03 AM Siratul Islam <email@sirat.me> wrote:

...

> Note on implementation:
> This driver is implemented as a standalone platform driver rather than
> using the auxiliary display 'linedisp' framework. The TM1637 protocol
> requires manual handling of the decimal point (merging it with the
> previous digit), which is difficult to achieve cleanly with the current
> linedisp character buffer abstraction.

We need this for 7-segment + dot point anyway, so consider extending
linedisp to cover this (via callback to the driver or better way).


-- 
With Best Regards,
Andy Shevchenko
Re: [PATCH 0/4] auxdisplay: Add support for TM1637 7-segment display driver
Posted by Andy Shevchenko 3 weeks, 4 days ago
On Tue, Jan 13, 2026 at 6:03 AM Siratul Islam <email@sirat.me> wrote:
>
> This series adds a driver for the Titan Micro TM1637 7-segment display
> controller.
>
> The TM1637 uses a custom two-wire protocol (CLK/DIO) that resembles I2C
> but lacks a slave address, requiring a bit-banging implementation.
>
> The driver exposes standard sysfs attributes for 'message' (text) and
> 'brightness'. It handles standard ASCII-to-7-segment mapping using the
> kernel's map_to_7segment utility.
>
> Note on implementation:
> This driver is implemented as a standalone platform driver rather than
> using the auxiliary display 'linedisp' framework. The TM1637 protocol
> requires manual handling of the decimal point (merging it with the
> previous digit), which is difficult to achieve cleanly with the current
> linedisp character buffer abstraction.

Wait, what happens to
https://lore.kernel.org/lkml/20251121145911.176033-1-jefflessard3@gmail.com/
?

-- 
With Best Regards,
Andy Shevchenko