Re: [RFC PATCH] gpiolib: introduce gpio_set_multiple function

[Rojhalat Ibrahim <imr@rtschenk.de>]

Thanks for your replies. I'll try to come up with a new patch which addresses
at least some of your points when I get around to it.

   Rojhalat


On Friday 24 January 2014 13:36:55 Gerhard Sittig wrote:
> [ added Cc: to Roland Stigge ]
> 
> On Thu, Jan 23, 2014 at 13:19 +0100, Rojhalat Ibrahim wrote:
> > 
> > This patch introduces a new function gpio_set_multiple which allows setting
> > multiple GPIO lines on the same chip with just one function call. If a
> > corresponding set_multi function is defined for the chip performance can be
> > significantly improved. Otherwise gpio_set_multiple uses the chip's set
> > function and the performance stays the same as without the new function.
> > For my application, where I have to frequently set 9 GPIO lines in order to
> > configure an FPGA, configuration time goes down from 48 s to 15 s when I use
> > this new function. (Tested with a modified gpio-mpc8xxx module.)
> 
> It's worth noting that performance is not the only concern, it
> may be even more important to avoid glitches when adjusting the
> levels of multiple pins which form some kind of bus (think
> "parport").  Improved throughput may just be a byproduct.  How
> you see it depends on your use case.
> 
> ISTR that Roland suggested some "block GPIO" approach in the
> past, work on it has continued for quite long a period of time.
> Apparently it has not yet gone into mainline, as the subject is
> more complex than one might expect at first glance.
> 
> There are several concerns that need to get addressed in the
> design, before an implementation could follow:
> - do you want to restrict the use for groups of pins which all
>   reside on the same chip?
> - do you expect callers to know or make sure that these
>   constraints are met?
> - do you want to operate in a "best effort" manner, or will you
>   reject requests that cannot get serviced "at the same time"?
>   (see above, what is the motivation or use case?)
> 
> Current implementation of the Linux GPIO subsystem suggests
> - that callers don't expect gpio_set_value() could ever fail
> - that callers need not care, and should not care, which specific
>   pin they are controlling, as long as they get a handle to it
> 
> Which suggests that the best effort approach would be most
> appropriate:  Allow callers to specify any arbitrary group of
> pins and which values to drive to them, try to process the
> request with as few glitches as possible, still transparently
> adjust individual pins and/or individual banks if nothing better
> is available.  This results in
> - callers still not caring about how the pins are attached in
>   hardware (configuration is not encoded but data driven these
>   days)
> - best possible performance, automatically taking benefit from
>   optional support for advanced features
> - gpio chip drivers can get adjusted as they want to, or remain
>   as they are and still keep working
> - glitch free signal adjustment in "bus style" for those setups
>   where the pins reside on the same bank and the chip driver
>   supports parallel manipulation -- it's under control of the
>   board designers whether they need or want this feature
> 
> None of the above says anything about the implementation, whether
> a "parallel" code path is required to communicate multi-pin
> set-operations, or whether some kind of "prepare and commit"
> transaction style gets implemented (and what to do about
> concurrent requests then).
> 
> 
> There is not much one could say about your specific patch, as it
> only introduces one callback for a GPIO chip, while it neither
> provides an example implementation within a driver nor provides
> an example caller demonstrating how the API is meant to get used,
> and completely lacks any kind of documentation.
> 
> 
> virtually yours
> Gerhard Sittig
>