[PATCH 3.9] Driver for 7-segment displays connected over GPIOs

[Jason Cooper]

On Mon, Jan 07, 2013 at 11:56:19AM -0600, H Hartley Sweeten wrote:
> On Monday, January 07, 2013 10:44 AM, Thomas Petazzoni wrote:
> > On Mon, 7 Jan 2013 18:40:22 +0100, Thomas Petazzoni wrote:
> >
> >>>> Not having a kernel driver means that gazillions of applications
> >>>> re-invent the same piece of code over and over again, have to hardcode
> >>>> the GPIO numbers for a given piece of hardware, while the kernel
> >>>> abstract all of this very nicely.
> >>> 
> >>> That sounds like a wonderful use of a userspace library to do this
> >>> properly.  Much like libusb does, right?
> >>> 
> >>> I still think as this can be done in userspace, it probably should be.
> >> 
> >> Understood. Patches discarded.
> >
> > Thinking more about this. How would your userspace library know on which
> > GPIOs your 7-seg segment device is connected? Should it parse the
> > Device Tree from userspace? Given by the user-space application who
> > would have to hardcode the GPIO numbers, completely defeating the
> > hardware abstraction layer that the kernel intends to be?
> 
> Maybe an 'init' of 'config' function in the library should allow the user to
> define the GPIOs that are connected to the 7-seg display? Or store the
> GPIOs in some config file that the library parses when it's loaded.
> 
> This does require the user to know what GPIOs are connected and
> forces then to do a bit of setup to use the display. But the actual use of
> the display is still abstracted.
> 
> The library should also allow for multiple 7-seg displays. The old PC "post"
> diagnostic boards usually had two displays on them.

However, Thomas has a valid point.  The DT is supposed to describe the
hardware.  The seven segment display is wired to three gpios on the
board.  Hence, it should be described in the DT for inferior OS's that
would handle this device in kernelspace.

Perhaps the library should be parsing /proc/devicetree ?

thx,

Jason.