Message ID | 20240225213423.690561-1-chris.packham@alliedtelesis.co.nz |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-80311-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp1750543dyb; Sun, 25 Feb 2024 13:35:35 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWKcoHNjzJIYXXnSKdkEp6Na23emRXoNtCu1Ps0nICWrRzgkQgJ6UBSjyVCV/UKCYd4NfZS8NUI4t0aE0YBbUwWObPbSw== X-Google-Smtp-Source: AGHT+IFqSQ+Bnnyi9+EBNvW5Lwnn6lf0VAM3epKR13EFwpqv7fnTYEPXHEKf+S+9epWBAfobSRMs X-Received: by 2002:a0c:db04:0:b0:68f:43f6:4834 with SMTP id d4-20020a0cdb04000000b0068f43f64834mr6356018qvk.26.1708896934910; Sun, 25 Feb 2024 13:35:34 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708896934; cv=pass; d=google.com; s=arc-20160816; b=Sc/V0WM6ZI2HGHuiFgp9We2is1x58S3kxf0dJxiGtgJMPZh/oIjEq4uZKQAncAefrh KG/54FHJFDZqSECq5C8hSROqvHNaozjlRVfB1q8zRuHkqw0Qw3+sBjIOfYagF/n1wymw NPVQO2ITC7iRMg4K0fy8SxLXmfO8Ply+WVQV2xcfmI5hkHTIHqsijGCpBZnjsE+6KOka 3A3eQmaScU1c/WxfUW4X7GHwxKbmyKLYBoVV+VK31jyU4QsW7o1lWQYYgyjF5N4E8QHR mPXjwFzEQPdJXnOsXffh1T1qtQrHYPK7nlfUT3J2EOGXLC7NSkuN0WY0OECWD0PxJu5I enyg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=dYKwYg9jFPCTvhHfnHRuamLyYbyHrNi847yiy9x7npg=; fh=pEzhTg0ac/4WJHIRlAVeJCsnBpFrwMBCjOZhAIgfYzs=; b=N1kXkNPjtE6iO46OP/7jB7l+xlI7UiJ87DRLVHdFrC+6DHmBghI3U56z6r3br/Zpd8 3VqSezNpXveLW8jjlo1WdajbmrIMWWeWVOypHhby9j2bgl/0zrnrk18nTAS/av2YJfNf /UkE1B+rn7LO6862nPMFP4QT90C+dfEt80CyXD0TSKBJjGbBpoQN52aEeC1mqD03MkF/ oAQ/OlOAw59bd48zAWSmxPp9CqfU3Ksx+ayJtyGht5khew7PnmiXIfCNjl2fyMOrgLey N5OI46HGB459IZ/r9MNNzS+tZT5Yd6Ds62Rbody+cbc6Tsmuv5NR+JWichMNsec3JGRr M9Jg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@alliedtelesis.co.nz header.s=mail181024 header.b=Ag6eyl5z; arc=pass (i=1 spf=pass spfdomain=alliedtelesis.co.nz dkim=pass dkdomain=alliedtelesis.co.nz dmarc=pass fromdomain=alliedtelesis.co.nz); spf=pass (google.com: domain of linux-kernel+bounces-80311-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-80311-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=alliedtelesis.co.nz Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id jx8-20020a0562142b0800b0068f52f40746si3765260qvb.440.2024.02.25.13.35.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Feb 2024 13:35:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-80311-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@alliedtelesis.co.nz header.s=mail181024 header.b=Ag6eyl5z; arc=pass (i=1 spf=pass spfdomain=alliedtelesis.co.nz dkim=pass dkdomain=alliedtelesis.co.nz dmarc=pass fromdomain=alliedtelesis.co.nz); spf=pass (google.com: domain of linux-kernel+bounces-80311-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-80311-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=REJECT dis=NONE) header.from=alliedtelesis.co.nz Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id B10B71C20363 for <ouuuleilei@gmail.com>; Sun, 25 Feb 2024 21:35:34 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 051F21CA81; Sun, 25 Feb 2024 21:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=alliedtelesis.co.nz header.i=@alliedtelesis.co.nz header.b="Ag6eyl5z" Received: from gate2.alliedtelesis.co.nz (gate2.alliedtelesis.co.nz [202.36.163.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D81A91B81F for <linux-kernel@vger.kernel.org>; Sun, 25 Feb 2024 21:34:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.36.163.20 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708896887; cv=none; b=R9zCuko6UEk5iF7ZrqnTlt1BR2x1/PT0lSPrIFMevOsFNMN2k/cwI6ze5yj5kpDMoQNRAdOJofJQxZMHgXhypUGPKV2q3aR/IM9fnMHdalfXGmykd3VPdjj1bldpuYZ/xvSDZRyBD+jkqIwFK9U9nRC/9S059ahIeLryAKDiCmY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708896887; c=relaxed/simple; bh=rBkQQG9txA6R1c7Mv2Avk/c9RrmlA7X0BzGB2IgLlPk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=f/+fudCfe5WD6R+Gc6LVgJ2GU/JfD7c+H6qodMKbWgDNOHn09D0Oj1/2sN7+JyeeI/Q7fCNujCfrVLw8ZO+qfMkEPx+qJ1i8bCDEwpnlcyeeP44wZiaGgjSpM6dNsrWGHwr8Q5LLcvFkSnFvcX4YWjMzx7yMoAwq5csFfi5FXuY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=alliedtelesis.co.nz; spf=pass smtp.mailfrom=alliedtelesis.co.nz; dkim=pass (2048-bit key) header.d=alliedtelesis.co.nz header.i=@alliedtelesis.co.nz header.b=Ag6eyl5z; arc=none smtp.client-ip=202.36.163.20 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=alliedtelesis.co.nz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alliedtelesis.co.nz Received: from svr-chch-seg1.atlnz.lc (mmarshal3.atlnz.lc [10.32.18.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by gate2.alliedtelesis.co.nz (Postfix) with ESMTPS id CC9C42C0271; Mon, 26 Feb 2024 10:34:35 +1300 (NZDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alliedtelesis.co.nz; s=mail181024; t=1708896875; bh=dYKwYg9jFPCTvhHfnHRuamLyYbyHrNi847yiy9x7npg=; h=From:To:Cc:Subject:Date:From; b=Ag6eyl5z+oYCkDn07RZHWIrsq+RJoFXQ4DnFWtqvGivt2F6Lssg+kLb4GFQ2htr/m 6LIr3JJlfK4ysLIZAn5DB+QzCT0bcNxPCxMKAnjwLWN0R+DHemijzQPVoHOaku8wKD za3x8FjVFuDa3q2UeOozYkJ1vgdU9xhjvJUt2QRljkslkVkN/IL+9m18VF+yEv0jWB qOBuCmiwWrvFndDA0+05vpKgSavhnsSYaS7ykRRgNEn549t6TiYJdIzfg+ivo8biqN I7yr9O6cK1o5aXfZZGXBhsCKXuoCJlCToU40/RgkeVaVYRWbQXrZEytkYDcg9DUDJz 5Eu/5yHMN20IA== Received: from pat.atlnz.lc (Not Verified[10.32.16.33]) by svr-chch-seg1.atlnz.lc with Trustwave SEG (v8,2,6,11305) id <B65dbb26b0000>; Mon, 26 Feb 2024 10:34:35 +1300 Received: from chrisp-dl.ws.atlnz.lc (chrisp-dl.ws.atlnz.lc [10.33.22.30]) by pat.atlnz.lc (Postfix) with ESMTP id 9B26113EDA8; Mon, 26 Feb 2024 10:34:35 +1300 (NZDT) Received: by chrisp-dl.ws.atlnz.lc (Postfix, from userid 1030) id 935FF280808; Mon, 26 Feb 2024 10:34:35 +1300 (NZDT) From: Chris Packham <chris.packham@alliedtelesis.co.nz> To: ojeda@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, andrew@lunn.ch, gregory.clement@bootlin.com, sebastian.hesselbarth@gmail.com, andy.shevchenko@gmail.com, geert@linux-m68k.org, pavel@ucw.cz, lee@kernel.org Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-leds@vger.kernel.org, Chris Packham <chris.packham@alliedtelesis.co.nz> Subject: [PATCH 0/3] auxdisplay: 7 segment LED display Date: Mon, 26 Feb 2024 10:34:20 +1300 Message-ID: <20240225213423.690561-1-chris.packham@alliedtelesis.co.nz> X-Mailer: git-send-email 2.43.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SEG-SpamProfiler-Analysis: v=2.4 cv=BKkQr0QG c=1 sm=1 tr=0 ts=65dbb26b a=KLBiSEs5mFS1a/PbTCJxuA==:117 a=k7vzHIieQBIA:10 a=VwQbUJbxAAAA:8 a=BcuUNpNrl9xOKT-QDWIA:9 a=3ZKOabzyN94A:10 a=AjGcO6oz07-iQ99wixmX:22 X-SEG-SpamProfiler-Score: 0 x-atlnz-ls: pat X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791908312185453605 X-GMAIL-MSGID: 1791908312185453605 |
Series | auxdisplay: 7 segment LED display | |
Message
Chris Packham
Feb. 25, 2024, 9:34 p.m. UTC
This series adds a driver for a 7 segment LED display. I'd like to get some feedback on how this could be extended to support >1 character. The driver as presented is sufficient for my hardware which only has a single character display but I can see that for this to be generically useful supporting more characters would be desireable. Earlier I posted an idea that the characters could be represended by sub-nodes[1] but there doesn't seem to be a way of having that and keeping the convenience of using devm_gpiod_get_array() (unless I've missed something). [1] - https://lore.kernel.org/lkml/2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz/ Chris Packham (3): auxdisplay: Add 7 segment LED display driver dt-bindings: auxdisplay: Add bindings for generic 7 segment LED ARM: dts: marvell: Add 7 segment LED display on x530 .../auxdisplay/generic,gpio-7seg.yaml | 40 +++++ .../boot/dts/marvell/armada-385-atl-x530.dts | 13 +- drivers/auxdisplay/Kconfig | 7 + drivers/auxdisplay/Makefile | 1 + drivers/auxdisplay/seg-led.c | 152 ++++++++++++++++++ 5 files changed, 212 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic,gpio-7seg.yaml create mode 100644 drivers/auxdisplay/seg-led.c
Comments
On Sun, Feb 25, 2024 at 11:34 PM Chris Packham <chris.packham@alliedtelesis.co.nz> wrote: > > This series adds a driver for a 7 segment LED display. > > I'd like to get some feedback on how this could be extended to support >1 > character. The driver as presented is sufficient for my hardware which only has > a single character display but I can see that for this to be generically useful > supporting more characters would be desireable. > > Earlier I posted an idea that the characters could be represended by > sub-nodes[1] but there doesn't seem to be a way of having that and keeping the > convenience of using devm_gpiod_get_array() (unless I've missed something). It seems you didn't know that the tree for auxdisplay has been changed. Can you rebase your stuff on top of https://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay.git/log/?h=for-next? It will reduce your code base by ~50%. WRT subnodes, you can go with device_for_each_child_node() and retrieve gpio array per digit. It means you will have an array of arrays of GPIOs. > [1] - https://lore.kernel.org/lkml/2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz/
Hello Chris, Am Mon, Feb 26, 2024 at 10:34:20AM +1300 schrieb Chris Packham: > This series adds a driver for a 7 segment LED display. > > I'd like to get some feedback on how this could be extended to support >1 > character. The driver as presented is sufficient for my hardware which only has > a single character display but I can see that for this to be generically useful > supporting more characters would be desireable. > > Earlier I posted an idea that the characters could be represended by > sub-nodes[1] but there doesn't seem to be a way of having that and keeping the > convenience of using devm_gpiod_get_array() (unless I've missed something). > > [1] - https://lore.kernel.org/lkml/2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz/ Read that thread out of curiosity and I'm sorry if I'm late to the party, but I wondered why this is limited to LEDs connected to GPIOs? Would it be possible to somehow stack this on top of some existing LEDs? I mean you could wire a 7 segment device to almost any LED driver IC with enough channels, couldn't you? Greets Alex > > Chris Packham (3): > auxdisplay: Add 7 segment LED display driver > dt-bindings: auxdisplay: Add bindings for generic 7 segment LED > ARM: dts: marvell: Add 7 segment LED display on x530 > > .../auxdisplay/generic,gpio-7seg.yaml | 40 +++++ > .../boot/dts/marvell/armada-385-atl-x530.dts | 13 +- > drivers/auxdisplay/Kconfig | 7 + > drivers/auxdisplay/Makefile | 1 + > drivers/auxdisplay/seg-led.c | 152 ++++++++++++++++++ > 5 files changed, 212 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic,gpio-7seg.yaml > create mode 100644 drivers/auxdisplay/seg-led.c > > -- > 2.43.2 > >
Hi Alex, On 27/02/24 05:04, Alexander Dahl wrote: > Hello Chris, > > Am Mon, Feb 26, 2024 at 10:34:20AM +1300 schrieb Chris Packham: >> This series adds a driver for a 7 segment LED display. >> >> I'd like to get some feedback on how this could be extended to support >1 >> character. The driver as presented is sufficient for my hardware which only has >> a single character display but I can see that for this to be generically useful >> supporting more characters would be desireable. >> >> Earlier I posted an idea that the characters could be represended by >> sub-nodes[1] but there doesn't seem to be a way of having that and keeping the >> convenience of using devm_gpiod_get_array() (unless I've missed something). >> >> [1] - https://scanmail.trustwave.com/?c=20988&d=trbc5eARVo-5gepRnwbAKbQmiGk1bOSpqZDQx9bx7w&u=https%3a%2f%2flore%2ekernel%2eorg%2flkml%2f2a8d19ee-b18b-4b7c-869f-7d601cea30b6%40alliedtelesis%2eco%2enz%2f > Read that thread out of curiosity and I'm sorry if I'm late to the > party, but I wondered why this is limited to LEDs connected to GPIOs? > > Would it be possible to somehow stack this on top of some existing > LEDs? I mean you could wire a 7 segment device to almost any LED > driver IC with enough channels, couldn't you? Mainly because the GPIO version is the hardware I have. I do wonder how this might work with something like the pca9551 which really is just a fancy version of the pca9554 on my board. A naive implementation would be to configure all the pca9551 pins as GPIOs and use what I have as-is. Making a line display out of LED triggers might be another way of doing it but not something I really want to pursue. > > Greets > Alex > >> Chris Packham (3): >> auxdisplay: Add 7 segment LED display driver >> dt-bindings: auxdisplay: Add bindings for generic 7 segment LED >> ARM: dts: marvell: Add 7 segment LED display on x530 >> >> .../auxdisplay/generic,gpio-7seg.yaml | 40 +++++ >> .../boot/dts/marvell/armada-385-atl-x530.dts | 13 +- >> drivers/auxdisplay/Kconfig | 7 + >> drivers/auxdisplay/Makefile | 1 + >> drivers/auxdisplay/seg-led.c | 152 ++++++++++++++++++ >> 5 files changed, 212 insertions(+), 1 deletion(-) >> create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic,gpio-7seg.yaml >> create mode 100644 drivers/auxdisplay/seg-led.c >> >> -- >> 2.43.2 >> >>
On 26/02/24 15:23, Andy Shevchenko wrote: > On Sun, Feb 25, 2024 at 11:34 PM Chris Packham > <chris.packham@alliedtelesis.co.nz> wrote: >> This series adds a driver for a 7 segment LED display. >> >> I'd like to get some feedback on how this could be extended to support >1 >> character. The driver as presented is sufficient for my hardware which only has >> a single character display but I can see that for this to be generically useful >> supporting more characters would be desireable. >> >> Earlier I posted an idea that the characters could be represended by >> sub-nodes[1] but there doesn't seem to be a way of having that and keeping the >> convenience of using devm_gpiod_get_array() (unless I've missed something). > It seems you didn't know that the tree for auxdisplay has been changed. > Can you rebase your stuff on top of > https://scanmail.trustwave.com/?c=20988&d=vfbb5fnU59kvIREfdD-21Pab30bpMpuTM2Ipv28now&u=https%3a%2f%2fgit%2ekernel%2eorg%2fpub%2fscm%2flinux%2fkernel%2fgit%2fandy%2flinux-auxdisplay%2egit%2flog%2f%3fh%3dfor-next%3f > It will reduce your code base by ~50%. > > WRT subnodes, you can go with device_for_each_child_node() and > retrieve gpio array per digit. It means you will have an array of > arrays of GPIOs. So would the following work? count = device_get_child_node_count(dev); struct gpio_descs **chars = devm_kzalloc(dev, sizeof(*chars) * count, GFP_KERNEL); i = 0; device_for_each_child_node(dev, child) { chars[i] = devm_gpiod_get_array(dev, "segment", GPIOD_OUT_LOW); } I haven't used the child. The devm_gpiod_get_array() will be looking at the fwnode of the parent.
Hello Chris, Am Mon, Feb 26, 2024 at 08:10:07PM +0000 schrieb Chris Packham: > Hi Alex, > > On 27/02/24 05:04, Alexander Dahl wrote: > > Hello Chris, > > > > Am Mon, Feb 26, 2024 at 10:34:20AM +1300 schrieb Chris Packham: > >> This series adds a driver for a 7 segment LED display. > >> > >> I'd like to get some feedback on how this could be extended to support >1 > >> character. The driver as presented is sufficient for my hardware which only has > >> a single character display but I can see that for this to be generically useful > >> supporting more characters would be desireable. > >> > >> Earlier I posted an idea that the characters could be represended by > >> sub-nodes[1] but there doesn't seem to be a way of having that and keeping the > >> convenience of using devm_gpiod_get_array() (unless I've missed something). > >> > >> [1] - https://scanmail.trustwave.com/?c=20988&d=trbc5eARVo-5gepRnwbAKbQmiGk1bOSpqZDQx9bx7w&u=https%3a%2f%2flore%2ekernel%2eorg%2flkml%2f2a8d19ee-b18b-4b7c-869f-7d601cea30b6%40alliedtelesis%2eco%2enz%2f > > Read that thread out of curiosity and I'm sorry if I'm late to the > > party, but I wondered why this is limited to LEDs connected to GPIOs? > > > > Would it be possible to somehow stack this on top of some existing > > LEDs? I mean you could wire a 7 segment device to almost any LED > > driver IC with enough channels, couldn't you? > > Mainly because the GPIO version is the hardware I have. I do wonder how > this might work with something like the pca9551 which really is just a > fancy version of the pca9554 on my board. A naive implementation would > be to configure all the pca9551 pins as GPIOs and use what I have as-is. My idea was to do it on top of the LED abstraction, not on top of the GPIO abstraction. Currently you are using the GPIO consumer interface and group 7 gpios which are supplied by that pca9554 in your case, but could also be coming from a SoC or a 74hc595 etc. Why not put it a level of abstraction higher, and let it consume LEDs instead of GPIOs? Your usecase would still be possible then. As far as I could see the concept of a LED consumer can be done, the leds-group-multicolor driver in drivers/leds/rgb/leds-group-multicolor.c does that, introduced with kernel v6.6 not so long ago. It sets the sysfs entries of the LEDs part of the group to readonly so they are not usable on their own anymore and one would not disturb the grouped multicolor LED. This would allow to use LEDs as a 7 segment group driven by any LED driver including leds-gpio. > Making a line display out of LED triggers might be another way of doing > it but not something I really want to pursue. Fair enough. I just wanted to share my idea. Didn't want to pressure you in any direction. :-) Greets Alex > > > > > Greets > > Alex > > > >> Chris Packham (3): > >> auxdisplay: Add 7 segment LED display driver > >> dt-bindings: auxdisplay: Add bindings for generic 7 segment LED > >> ARM: dts: marvell: Add 7 segment LED display on x530 > >> > >> .../auxdisplay/generic,gpio-7seg.yaml | 40 +++++ > >> .../boot/dts/marvell/armada-385-atl-x530.dts | 13 +- > >> drivers/auxdisplay/Kconfig | 7 + > >> drivers/auxdisplay/Makefile | 1 + > >> drivers/auxdisplay/seg-led.c | 152 ++++++++++++++++++ > >> 5 files changed, 212 insertions(+), 1 deletion(-) > >> create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic,gpio-7seg.yaml > >> create mode 100644 drivers/auxdisplay/seg-led.c > >> > >> -- > >> 2.43.2 > >> > >>
Hi! > My idea was to do it on top of the LED abstraction, not on top of the > GPIO abstraction. Currently you are using the GPIO consumer > interface Let's not do that. Pavel