Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

On Sun, 2008-12-28 at 13:46 -0500, Robin Getz wrote:

quoted

gpio_set_batch(DB0, value, 0xFFFF, 16)

which has the nice performance benefit of skipping all the bit
counting in the most common use case scenario.

but has the requirement that the driver know exactly the board level 
impmentation details (something that doesn't sound generic).

The original use case for these batch operations was in a fastpath -
setting data lines on a framebuffer.  Sure it's arguably not as generic
as may be, but it optimises for speed and current usage patterns - I'm
OK with that.  Other usage patterns which don't have a speed requirement
can be done using the individual pin operations and a loop.

quoted

While we are here, I was thinking about it, and its better if I give
gpio_request/free/direction_batch a miss for now. Nothing prevents
those features being added at a later point.

I don't think that request/free are optional.

For example - in most SoC implementations - gpios are implemented as banks of 
16 or 32. (a 16 or 32 bit register).

Are there facilities to span these registers? 
 - can you request 64 gpios as a 'bank'?
 - can you request gpio_8 -> gpio_40 as a 'bank' on a 32-bit system?

Are non-adjacent/non-contiguous gpios avaliable to be put into 
a 'bank/batch/bus'? can you use gpio_8 -> 11 &  28 -> 31 as a 8-bit 'bus'? 

How do you know what is avaliable to be talked to as a bank/bus/batch without 
the request/free operation?

I think the read/write operations should be able to fail if you give
them invalid chunks of gpio, sure.  Request/free are not really designed
for that operation - they just ensure exclusive access to a gpio if
that's what the driver wants.  In the batch case the
request/free/direction operations can once again be performed by single
pin operations and iteration.

I have seen various hardware designs (both at the PCB and SoC level) require 
all of these options, and would like to see common infrastructure which 
handles this.

The issue is that on many SoC implementations - dedicated peripherals can also 
be GPIOs - so it someone wants to use SPI (for example) GPIO's 3->7 might be 
removed from the avaliable 'gpio' resources. This is determined by the 
silicon designer - and even the PCB designer has little to no flexibility on 
this. It gets worse as multiple SPI or I2C are used on the PCB (which can 
have lots of small (less than 5) dedicated pins in the middle of the larger 
gpio resources)....

Yeah the request/free operation doesn't deal with muxing or any other
platform-specific kinda gumph, that was an original design decision.
They're really just a usage counter.

An example which comes to mind is the avr32-specific userspace gpio
interface.  This takes a bitmask, loops over the set bits and fails if
any of the gpio are previously requested or have been assigned to
non-gpio peripherals.  I don't really see a need to streamline this.

I would think that a 'bank' / 'bus' (whatever) would be a collection of 
random/multiple GPIOs (a struct of gpio_port_t) rather than a start/length 
(as you described) - or better yet - the request function takes a list (of 
individual GPIO's - defined in the platform data), and creates the struct 
itself.

Hmm, this seems a little overengineered for the basic use-cases I can
think of.  If this can be cranked up to the same speed as the current
proposition then OK maybe someone will like it but otherwise, once
again, I think most people will be happy with individual operations and
iteration.


	--Ben.