Re: [PATCH 1/6 v14] gpio: Add a block GPIO API to gpiolib

[Roland Stigge]

On 27/01/13 14:19, Stijn Devriendt wrote:
>> +Block GPIO
>> +----------
>> +
>> +The above described interface concentrates on handling single GPIOs.  However,
>> +in applications where it is critical to set several GPIOs at once, this
>> +interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
>> +Consider a GPIO controller that is connected via a slow I2C line. When
>> +switching two or more GPIOs one after another, there can be considerable time
>> +between those events. This is solved by an interface called Block GPIO:
>> +
>> +struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size,
>> +                                    const char *name);
>> +
>> +This creates a new block of GPIOs as a list of GPIO numbers with the specified
>> +size which are accessible via the returned struct gpio_block and the accessor
>> +functions described below. Please note that you need to request the GPIOs
>> +separately via gpio_request(). Similarly, the direction of the used GPIOs need
>> +to be set by the user before using the block.
> 
> Is there anything holding you back from letting gpio_block_create() do
> the request
> for all the pins?

It's analoguous to plain GPIOs: They exist, but are not requested (by
whom?) by default.

> Also, wouldn't it make sense to have a gpio_block_direction_input()
> and _output()
> variant? On the other hand, for things like I2C and SPI emulation,
> some pins will
> naturally be always output (like clock lines) while other could be
> switched between
> in and output (like the i2c data line).

Right. Current implementation emphasizes on switching, not direction or
other convenience functions, which could be added, nevertheless.

Roland
--
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/