<div dir="ltr">Hi,<div>Thanks all for the feedback; Further reimplementation of this driver will be handled by</div><div>another member of my team. Please contact Nancy Yuen(<a href="mailto:yuenn@google.com">yuenn@google.com</a>) for any details.</div><div>Summary of main points mentioned in the feedback were :</div><div><span style="font-size:12.8px"> - Address </span><span style="font-size:12.8px">Russell's </span><span style="font-size:12.8px">errno comments</span></div><div><span style="font-size:12.8px"> - Rebase per Joel's comment</span></div><div><span style="font-size:12.8px"> - Research fingerprint reader support (mentioned by Greg KH)</span><br style="font-size:12.8px"><span style="font-size:12.8px"> - Research drivers/leds (mentioned by Arnd)</span><br style="font-size:12.8px"><span style="font-size:12.8px"> - Reimplement either by</span><span style="font-size:12.8px"> making an API that all devices of this type could use or in </span><span style="font-size:12.8px">drivers/leds model or the fingerprint reader model.</span></div><div><br></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 12:05 PM, David Daney <span dir="ltr"><<a href="mailto:ddaney.cavm@gmail.com" target="_blank">ddaney.cavm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/14/2016 06:15 AM, Arnd Bergmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday, December 14, 2016 2:12:41 PM CET Neil Armstrong wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/14/2016 01:56 PM, Greg KH wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Dec 14, 2016 at 01:45:30PM +0100, Thomas Petazzoni wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
On Tue, 13 Dec 2016 23:55:00 -0800, Jaghathiswari Rankappagounder<br>
Natarajan wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Documentation for the binding which provides an interface for adding clock,<br>
data and clear signal GPIO lines to control seven segment display.<br>
<br>
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.<br>
<br>
The character device driver implements the user-space API for letting a user<br>
write to two 7-segment displays including any conversion methods necessary<br>
to map the user input to two 7-segment displays.<br>
<br>
Adding clock, data and clear signal GPIO lines in the devicetree to control<br>
seven segment display on zaius platform.<br>
<br>
The platform driver matches on the device tree node; the platform driver also<br>
initializes the character device.<br>
<br>
Tested that the seven segment display works properly by writing to the<br>
character device file on a EVB AST2500 board which also has 74HC164 wired<br>
to two 7-segment displays.<br>
</blockquote>
<br>
FWIW, I proposed a driver for seven segment displays back in 2013:<br>
<br>
<a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139986.html" rel="noreferrer" target="_blank">http://lists.infradead.org/pi<wbr>permail/linux-arm-kernel/2013-<wbr>January/139986.html</a><br>
<br>
And the feedback from Greg KH was: we don't need a driver for that, do<br>
it from userspace. See:<br>
<br>
<a href="http://lists.infradead.org/pipermail/linux-arm-kernel/2013-January/139992.html" rel="noreferrer" target="_blank">http://lists.infradead.org/pi<wbr>permail/linux-arm-kernel/2013-<wbr>January/139992.html</a><br>
<br>
So: good luck<br>
</blockquote>
<br>
Did anyone ever write a library for this type of thing?<br>
<br>
Again, I don't want to see one-off drivers for random devices like this<br>
that should be able to all be controlled from userspace in a common<br>
manner. Much like we did for fingerprint readers a long long time<br>
ago...<br>
<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Actually, it's more than a random interface, a lot of SoCs and boards actually have such displays<br>
and it's a pity to use UIO, sysfs gpio bitbanging and all sort of ugly stuff to only print a few<br>
characters a simple and clean driver could achieve.<br>
Some very well known SoCs even have integrated registers to lower the BOM and bypass the need for<br>
a 74HC164 like component and avoid gpio bit banging.<br>
<br>
My personal concern is that you could also need to drive more segments, thus 7-segments<br>
is too restrictive.<br>
<br>
But this driver is well structured, the gpio-bitbanging sub-driver is welcome.<br>
</blockquote>
<br>
Maybe we can find a way to fit this into the existing drivers/leds/ subsystem?<br>
<br>
That already supports blinking, brightness and colour attributes of LEDs,<br>
so could this be extended to support (one of) digit, number, character<br>
or string with a common sysfs attribute and a way to hook up a led driver<br>
to that?<br>
</blockquote>
<br></div></div>
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.<br>
<br>
Really I view these things not as part of the LED subsystem, but more as a very small frame buffer.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Arnd<br>
<br>
______________________________<wbr>_________________<br>
linux-arm-kernel mailing list<br>
<a href="mailto:linux-arm-kernel@lists.infradead.org" target="_blank">linux-arm-kernel@lists.infrade<wbr>ad.org</a><br>
<a href="http://lists.infradead.org/mailman/listinfo/linux-arm-kernel" rel="noreferrer" target="_blank">http://lists.infradead.org/mai<wbr>lman/listinfo/linux-arm-kernel</a><br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>