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

From: Ben Nizette
Date: Sun Dec 28 2008 - 17:10:43 EST


On Sun, 2008-12-28 at 13:46 -0500, Robin Getz wrote:
> > 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.

>
> > 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.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/