From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1481702104-8617-1-git-send-email-jaghu@google.com> <20161214125641.GA5379@kroah.com> <2512681.Wh85HyB8FH@wuerfel> From: Jaghathiswari Rankappagounder Natarajan Date: Mon, 19 Dec 2016 20:06:54 -0800 Message-ID: Subject: Re: [PATCH linux v1 0/4] Seven segment display support Content-Type: multipart/alternative; boundary=047d7bb040c6e81a4a05440f2b1f To: David Daney Cc: Arnd Bergmann , Neil Armstrong , Thomas Petazzoni , mark.rutland@arm.com, devicetree@vger.kernel.org, Greg KH , OpenBMC Maillist , linux@armlinux.org.uk, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Joel Stanley , linux-arm-kernel@lists.infradead.org List-ID: --047d7bb040c6e81a4a05440f2b1f Content-Type: text/plain; charset=UTF-8 Hi, Thanks all for the feedback; Further reimplementation of this driver will be handled by another member of my team. Please contact Nancy Yuen(yuenn@google.com) for any details. Summary of main points mentioned in the feedback were : - Address Russell's errno comments - Rebase per Joel's comment - Research fingerprint reader support (mentioned by Greg KH) - Research drivers/leds (mentioned by Arnd) - Reimplement either by making an API that all devices of this type could use or in drivers/leds model or the fingerprint reader model. On Wed, Dec 14, 2016 at 12:05 PM, David Daney wrote: > On 12/14/2016 06:15 AM, Arnd Bergmann wrote: > >> On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote: >> >>> On 12/14/2016 01:56 PM, Greg KH wrote: >>> >>>> On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote: >>>> >>>>> Hello, >>>>> >>>>> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder >>>>> Natarajan wrote: >>>>> >>>>> Documentation for the binding which provides an interface for adding >>>>>> clock, >>>>>> data and clear signal GPIO lines to control seven segment display. >>>>>> >>>>>> The platform device driver provides an API for displaying on two >>>>>> 7-segment >>>>>> displays, and implements the required bit-banging. The hardware >>>>>> assumed is >>>>>> 74HC164 wired to two 7-segment displays. >>>>>> >>>>>> The character device driver implements the user-space API for letting >>>>>> a user >>>>>> write to two 7-segment displays including any conversion methods >>>>>> necessary >>>>>> to map the user input to two 7-segment displays. >>>>>> >>>>>> Adding clock, data and clear signal GPIO lines in the devicetree to >>>>>> control >>>>>> seven segment display on zaius platform. >>>>>> >>>>>> The platform driver matches on the device tree node; the platform >>>>>> driver also >>>>>> initializes the character device. >>>>>> >>>>>> Tested that the seven segment display works properly by writing to the >>>>>> character device file on a EVB AST2500 board which also has 74HC164 >>>>>> wired >>>>>> to two 7-segment displays. >>>>>> >>>>> >>>>> FWIW, I proposed a driver for seven segment displays back in 2013: >>>>> >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013- >>>>> January/139986.html >>>>> >>>>> And the feedback from Greg KH was: we don't need a driver for that, do >>>>> it from userspace. See: >>>>> >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013- >>>>> January/139992.html >>>>> >>>>> So: good luck >>>>> >>>> >>>> Did anyone ever write a library for this type of thing? >>>> >>>> Again, I don't want to see one-off drivers for random devices like this >>>> that should be able to all be controlled from userspace in a common >>>> manner. Much like we did for fingerprint readers a long long time >>>> ago... >>>> >>>> >> Actually, it's more than a random interface, a lot of SoCs and boards >>> actually have such displays >>> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly >>> stuff to only print a few >>> characters a simple and clean driver could achieve. >>> Some very well known SoCs even have integrated registers to lower the >>> BOM and bypass the need for >>> a 74HC164 like component and avoid gpio bit banging. >>> >>> My personal concern is that you could also need to drive more segments, >>> thus 7-segments >>> is too restrictive. >>> >>> But this driver is well structured, the gpio-bitbanging sub-driver is >>> welcome. >>> >> >> Maybe we can find a way to fit this into the existing drivers/leds/ >> subsystem? >> >> That already supports blinking, brightness and colour attributes of LEDs, >> so could this be extended to support (one of) digit, number, character >> or string with a common sysfs attribute and a way to hook up a led driver >> to that? >> > > We have a lot of boards with an 8-cell dot matrix LED. Each cell is > programmed with an 8-bit value. The mapping of these values to the dots > defaults to ASCII character rendering, but there is the facility to install > other bitmaps as well. > > Really I view these things not as part of the LED subsystem, but more as a > very small frame buffer. > > We like to display entire words, and the most useful interface from a user > point of view is something that consumes entire strings rather than having > to manage each cell independently. > > You could imagine that if the text to be displayed were longer than the > display, that the driver would make it continuously scroll. I would like > to see a framework where a simple character device were exposed, and from > userspace you could do: "echo message > /dev/small-display" and get > something sensible. > > >> Arnd >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >> > --047d7bb040c6e81a4a05440f2b1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
Thanks all for the feedback; Further reimplementat= ion of this driver will be handled by
another member of my team. = Please contact Nancy Yuen(yuenn@google.= com) for any details.
Summary of main points mentioned in the= feedback were :
=C2=A0 - Addres= s=C2=A0Russell's=C2=A0errno comments
=C2=A0 - Rebase per Joel's comment
=C2=A0 - Research fingerprint reader su= pport (mentioned by Greg KH)
=C2=A0 - Research drivers/leds (mentioned by Arnd)<= /span>
=C2= =A0 - Reimplement either by=C2=A0ma= king an API that all devices of this type could use or in=C2=A0drivers/leds =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 model or the fingerprint reader model.

<= div>

On Wed, Dec 14, 2016 at 12:05 PM= , David Daney <ddaney.cavm@gmail.com> wrote:
On 12/14/201= 6 06:15 AM, Arnd Bergmann wrote:
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:
On 12/14/2016 01:56 PM, Greg KH wrote:
On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
Hello,

On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
Natarajan wrote:

Documentation for the binding which provides an interface for adding clock,=
data and clear signal GPIO lines to control seven segment display.

The platform device driver provides an API for displaying on two 7-segment<= br> displays, and implements the required bit-banging. The hardware assumed is<= br> 74HC164 wired to two 7-segment displays.

The character device driver implements the user-space API for letting a use= r
write to two 7-segment displays including any conversion methods necessary<= br> to map the user input to two 7-segment displays.

Adding clock, data and clear signal GPIO lines in the devicetree to control=
seven segment display on zaius platform.

The platform driver matches on the device tree node; the platform driver al= so
initializes the character device.

Tested that the seven segment display works properly by writing to the
character device file on a EVB AST2500 board which also has 74HC164 wired to two 7-segment displays.

FWIW, I proposed a driver for seven segment displays back in 2013:

=C2=A0 =C2=A0http://li= sts.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.= html

And the feedback from Greg KH was: we don't need a driver for that, do<= br> it from userspace. See:

=C2=A0 =C2=A0http://li= sts.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.= html

So: good luck

Did anyone ever write a library for this type of thing?

Again, I don't want to see one-off drivers for random devices like this=
that should be able to all be controlled from userspace in a common
manner.=C2=A0 Much like we did for fingerprint readers a long long time
ago...


Actually, it's more than a random interface, a lot of SoCs and boards a= ctually have such displays
and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly = stuff to only print a few
characters a simple and clean driver could achieve.
Some very well known SoCs even have integrated registers to lower the BOM a= nd bypass the need for
a 74HC164 like component and avoid gpio bit banging.

My personal concern is that you could also need to drive more segments, thu= s 7-segments
is too restrictive.

But this driver is well structured, the gpio-bitbanging sub-driver is welco= me.

Maybe we can find a way to fit this into the existing drivers/leds/ subsyst= em?

That already supports blinking, brightness and colour attributes of LEDs, so could this be extended to support (one of) digit, number, character
or string with a common sysfs attribute and a way to hook up a led driver to that?

We have a lot of boards with an 8-cell dot matrix LED. Each cell is program= med with an 8-bit value.=C2=A0 The mapping of these values to the dots defa= ults to ASCII character rendering, but there is the facility to install oth= er bitmaps as well.

Really I view these things not as part of the LED subsystem, but more as a = very small frame buffer.

We like to display entire words, and the most useful interface from a user = point of view is something that consumes entire strings rather than having = to manage each cell independently.

You could imagine that if the text to be displayed were longer than the dis= play, that the driver would make it continuously scroll.=C2=A0 I would like= to see a framework where a simple character device were exposed, and from = userspace you could do: "echo message > /dev/small-display" an= d get something sensible.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Arnd

_______________________________________________
linux-arm-kernel mailing list
l= inux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/= listinfo/linux-arm-kernel



--047d7bb040c6e81a4a05440f2b1f-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3tjPPf436fzDwQy for ; Tue, 20 Dec 2016 15:07:18 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.b="I6F+jPcQ"; dkim-atps=neutral Received: by mail-wj0-x22a.google.com with SMTP id v7so166274978wjy.2 for ; Mon, 19 Dec 2016 20:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GSEAM+EMvnNkKkor7BOKoI5rmihI9O2n05HhnCYsUN8=; b=I6F+jPcQK50D96u/t8nTP2FeN5Dow4SQQXcI/eY8+GPwKDVhDc9MWMpFZtuCAheBeT BWsEsQKVuhJxKNWDIAlEFpKsb5Nnk02sSp6Yh8vUB7C7JTud3srwHC1Qn/h868vNs+x8 rDFom3MMFDFHd3/Cjxo6ehr8tAH+UtJ6eahXdH8QYpomphQbGc4CHapitSGbhL1vj99w JAcxJeDi2N53FKl89lk/3saIyJoSoKFWtXhWGtT6OWhGGsBqfSU0wmE63XAqhRCvH4i1 L0mf9ZizlGWTo3+Dw0SuGn0x+rn4IlWYKBQaZIBnmsvaRAW3yU/imfZj5MszlORMLZtG Wy+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GSEAM+EMvnNkKkor7BOKoI5rmihI9O2n05HhnCYsUN8=; b=YdiLkabBIJ03nm+UdhIdkaHXm0xz4D0HnoK7lFCmjsJhA0NWJqR8l4MOwNqS+oZcos 1m2voviUQj6KRViy4AbpYRVAIS4UJZklpImqn7+UiUT/nNCDCHqR2GIIKBiAB274QJfv NbQV9iBlvIn/OjYnICzzBtcpnvM5tbatNAhnzOxMu8wVojaih2ro+eQYY3xLPq7DUpa7 h5c4pFOoCPZWOPGYcBmJD10HyZM2J5OUZjizOYG/v7wsSEjr8sMgqkPWgc9FpPT2zqop MuL6G11MKO1aDWdtZNf6XfCCbuFVXVmLWz5BFaRdDSfMW/rcnf7j3JW/ORtO/IsJG/3X bFIg== X-Gm-Message-State: AIkVDXKA0xzKyR/pHuVj0W2fMkdYut+T7RNfP38ZCqU34Qk2ebPRFbYJKzythy5SILKJDb2f0JjI/M1otY/ryUIP X-Received: by 10.194.94.166 with SMTP id dd6mr18551439wjb.88.1482206835354; Mon, 19 Dec 2016 20:07:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.35.5 with HTTP; Mon, 19 Dec 2016 20:06:54 -0800 (PST) In-Reply-To: References: <1481702104-8617-1-git-send-email-jaghu@google.com> <20161214125641.GA5379@kroah.com> <2512681.Wh85HyB8FH@wuerfel> From: Jaghathiswari Rankappagounder Natarajan Date: Mon, 19 Dec 2016 20:06:54 -0800 Message-ID: Subject: Re: [PATCH linux v1 0/4] Seven segment display support To: David Daney Cc: Arnd Bergmann , Neil Armstrong , Thomas Petazzoni , mark.rutland@arm.com, devicetree@vger.kernel.org, Greg KH , OpenBMC Maillist , linux@armlinux.org.uk, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Joel Stanley , linux-arm-kernel@lists.infradead.org Content-Type: multipart/alternative; boundary=047d7bb040c6e81a4a05440f2b1f X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 04:07:19 -0000 --047d7bb040c6e81a4a05440f2b1f Content-Type: text/plain; charset=UTF-8 Hi, Thanks all for the feedback; Further reimplementation of this driver will be handled by another member of my team. Please contact Nancy Yuen(yuenn@google.com) for any details. Summary of main points mentioned in the feedback were : - Address Russell's errno comments - Rebase per Joel's comment - Research fingerprint reader support (mentioned by Greg KH) - Research drivers/leds (mentioned by Arnd) - Reimplement either by making an API that all devices of this type could use or in drivers/leds model or the fingerprint reader model. On Wed, Dec 14, 2016 at 12:05 PM, David Daney wrote: > On 12/14/2016 06:15 AM, Arnd Bergmann wrote: > >> On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote: >> >>> On 12/14/2016 01:56 PM, Greg KH wrote: >>> >>>> On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote: >>>> >>>>> Hello, >>>>> >>>>> On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder >>>>> Natarajan wrote: >>>>> >>>>> Documentation for the binding which provides an interface for adding >>>>>> clock, >>>>>> data and clear signal GPIO lines to control seven segment display. >>>>>> >>>>>> The platform device driver provides an API for displaying on two >>>>>> 7-segment >>>>>> displays, and implements the required bit-banging. The hardware >>>>>> assumed is >>>>>> 74HC164 wired to two 7-segment displays. >>>>>> >>>>>> The character device driver implements the user-space API for letting >>>>>> a user >>>>>> write to two 7-segment displays including any conversion methods >>>>>> necessary >>>>>> to map the user input to two 7-segment displays. >>>>>> >>>>>> Adding clock, data and clear signal GPIO lines in the devicetree to >>>>>> control >>>>>> seven segment display on zaius platform. >>>>>> >>>>>> The platform driver matches on the device tree node; the platform >>>>>> driver also >>>>>> initializes the character device. >>>>>> >>>>>> Tested that the seven segment display works properly by writing to the >>>>>> character device file on a EVB AST2500 board which also has 74HC164 >>>>>> wired >>>>>> to two 7-segment displays. >>>>>> >>>>> >>>>> FWIW, I proposed a driver for seven segment displays back in 2013: >>>>> >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013- >>>>> January/139986.html >>>>> >>>>> And the feedback from Greg KH was: we don't need a driver for that, do >>>>> it from userspace. See: >>>>> >>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013- >>>>> January/139992.html >>>>> >>>>> So: good luck >>>>> >>>> >>>> Did anyone ever write a library for this type of thing? >>>> >>>> Again, I don't want to see one-off drivers for random devices like this >>>> that should be able to all be controlled from userspace in a common >>>> manner. Much like we did for fingerprint readers a long long time >>>> ago... >>>> >>>> >> Actually, it's more than a random interface, a lot of SoCs and boards >>> actually have such displays >>> and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly >>> stuff to only print a few >>> characters a simple and clean driver could achieve. >>> Some very well known SoCs even have integrated registers to lower the >>> BOM and bypass the need for >>> a 74HC164 like component and avoid gpio bit banging. >>> >>> My personal concern is that you could also need to drive more segments, >>> thus 7-segments >>> is too restrictive. >>> >>> But this driver is well structured, the gpio-bitbanging sub-driver is >>> welcome. >>> >> >> Maybe we can find a way to fit this into the existing drivers/leds/ >> subsystem? >> >> That already supports blinking, brightness and colour attributes of LEDs, >> so could this be extended to support (one of) digit, number, character >> or string with a common sysfs attribute and a way to hook up a led driver >> to that? >> > > We have a lot of boards with an 8-cell dot matrix LED. Each cell is > programmed with an 8-bit value. The mapping of these values to the dots > defaults to ASCII character rendering, but there is the facility to install > other bitmaps as well. > > Really I view these things not as part of the LED subsystem, but more as a > very small frame buffer. > > We like to display entire words, and the most useful interface from a user > point of view is something that consumes entire strings rather than having > to manage each cell independently. > > You could imagine that if the text to be displayed were longer than the > display, that the driver would make it continuously scroll. I would like > to see a framework where a simple character device were exposed, and from > userspace you could do: "echo message > /dev/small-display" and get > something sensible. > > >> Arnd >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> >> > --047d7bb040c6e81a4a05440f2b1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
Thanks all for the feedback; Further reimplementat= ion of this driver will be handled by
another member of my team. = Please contact Nancy Yuen(yuenn@google.= com) for any details.
Summary of main points mentioned in the= feedback were :
=C2=A0 - Addres= s=C2=A0Russell's=C2=A0errno comments
=C2=A0 - Rebase per Joel's comment
=C2=A0 - Research fingerprint reader su= pport (mentioned by Greg KH)
=C2=A0 - Research drivers/leds (mentioned by Arnd)<= /span>
=C2= =A0 - Reimplement either by=C2=A0ma= king an API that all devices of this type could use or in=C2=A0drivers/leds =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 model or the fingerprint reader model.

<= div>

On Wed, Dec 14, 2016 at 12:05 PM= , David Daney <ddaney.cavm@gmail.com> wrote:
On 12/14/201= 6 06:15 AM, Arnd Bergmann wrote:
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:
On 12/14/2016 01:56 PM, Greg KH wrote:
On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:
Hello,

On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder
Natarajan wrote:

Documentation for the binding which provides an interface for adding clock,=
data and clear signal GPIO lines to control seven segment display.

The platform device driver provides an API for displaying on two 7-segment<= br> displays, and implements the required bit-banging. The hardware assumed is<= br> 74HC164 wired to two 7-segment displays.

The character device driver implements the user-space API for letting a use= r
write to two 7-segment displays including any conversion methods necessary<= br> to map the user input to two 7-segment displays.

Adding clock, data and clear signal GPIO lines in the devicetree to control=
seven segment display on zaius platform.

The platform driver matches on the device tree node; the platform driver al= so
initializes the character device.

Tested that the seven segment display works properly by writing to the
character device file on a EVB AST2500 board which also has 74HC164 wired to two 7-segment displays.

FWIW, I proposed a driver for seven segment displays back in 2013:

=C2=A0 =C2=A0http://li= sts.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.= html

And the feedback from Greg KH was: we don't need a driver for that, do<= br> it from userspace. See:

=C2=A0 =C2=A0http://li= sts.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.= html

So: good luck

Did anyone ever write a library for this type of thing?

Again, I don't want to see one-off drivers for random devices like this=
that should be able to all be controlled from userspace in a common
manner.=C2=A0 Much like we did for fingerprint readers a long long time
ago...


Actually, it's more than a random interface, a lot of SoCs and boards a= ctually have such displays
and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly = stuff to only print a few
characters a simple and clean driver could achieve.
Some very well known SoCs even have integrated registers to lower the BOM a= nd bypass the need for
a 74HC164 like component and avoid gpio bit banging.

My personal concern is that you could also need to drive more segments, thu= s 7-segments
is too restrictive.

But this driver is well structured, the gpio-bitbanging sub-driver is welco= me.

Maybe we can find a way to fit this into the existing drivers/leds/ subsyst= em?

That already supports blinking, brightness and colour attributes of LEDs, so could this be extended to support (one of) digit, number, character
or string with a common sysfs attribute and a way to hook up a led driver to that?

We have a lot of boards with an 8-cell dot matrix LED. Each cell is program= med with an 8-bit value.=C2=A0 The mapping of these values to the dots defa= ults to ASCII character rendering, but there is the facility to install oth= er bitmaps as well.

Really I view these things not as part of the LED subsystem, but more as a = very small frame buffer.

We like to display entire words, and the most useful interface from a user = point of view is something that consumes entire strings rather than having = to manage each cell independently.

You could imagine that if the text to be displayed were longer than the dis= play, that the driver would make it continuously scroll.=C2=A0 I would like= to see a framework where a simple character device were exposed, and from = userspace you could do: "echo message > /dev/small-display" an= d get something sensible.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Arnd

_______________________________________________
linux-arm-kernel mailing list
l= inux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/= listinfo/linux-arm-kernel



--047d7bb040c6e81a4a05440f2b1f--