[PATCH 6/6 v14] gpio: Add block gpio to several gpio drivers

[Roland Stigge]

On 27/01/13 13:18, Stijn Devriendt wrote:
>>> In my patch, I go out of the way of this kind of thing for a simple reason:
>>> You may generate incorrect timing by doing this.
>>
>> You are right, certain things like synchronous on+off is not really
>> possible.
>>
>> However, the above at least supports switching on simulaneously, and
>> switching off simultaneously, which is an improvement in certain cases
>> (and this certain hardware part doesn't support more). Maybe this
>> certain driver behaviour can be documented even better than just in the
>> driver source.
>>
> 
> The question here is: do you expect a user of the block-GPIO API to
> go look into the base-driver code to see what will be supported?
> 
> In my version of the patch this means:
> - do not provide a single GPIO-block that crosses multiple base-drivers
> - only provide gpio_block_get/set for GPIO drivers that support the complete
> operation in a single go. (for example, in the above example there would be
> no gpio_block_set() function)
> 
> Perhaps the best approach is to make this explicit: Allow drivers to expose
> their capabilities wrt timing and allow users to request strict-timing or
> loose-timing. Loose-timing allows multiple gpio-drivers to be combined and
> allows drivers with separate set/clear, hi/lo registers to be used.

Interesting idea. However, it will be difficult to agree on good metrics
here. As Mark Brown pointed out, even when hardware seems to support
"simultaneousness" by registers, this doesn't actually mean that voltage
levels are switched simultaneously wrt. sub-nanosecond timing.

Also, it depends on further wiring between the actually supported GPIO
hardware chip and the integrated device's I/O connections.

Resulting in scenarios where GPIO chips (in terms of Linux drivers)
without explicit I/O set registers (e.g., set/clear regs) could be "more
simultaneous" than those having explicit I/O regs but hardware wiring
leading to bad "simultaneousness" behaviour.

Questionable if the kernel could address those details.

> Of course, for a first version you may as well leave it out. Perhaps the
> use-cases for cross-GPIO-driver blocks are not worth the extra complexity
> as of today?

I actually started the current block gpio patches to support this kind
of use case. :-)

Roland