[PATCH linux v1 0/4] Seven segment display support

Tue Dec 20 15:06:54 AEDT 2016

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 at 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 <ddaney.cavm at gmail.com> 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 at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161219/807228e3/attachment-0001.html>