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

[Stijn Devriendt]

On Sun, Jan 27, 2013 at 2:48 PM, Roland Stigge <stigge at antcom.de> wrote:
> 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.
>

True, but does the kernel _need_ to address that? If this is fixed at the
kernel level, at least the kernel is not the cause of the effect.
Strict-timing could mean as much as "the kernel will do everything it can
(int this case impose limits) to make sure timings are strict - actual
results may
depend on your H/W".
It allows graceful degradation at the driver level (e.g. fallback to requesting
separate pins and toggling them in the right order - or calling the request
function again with loose-timing + dev_warn(... "things may break!") )

OTOH, is it worth it? There may be extra work involved when doing the latter.
Usage of block GPIO for things like emulating busses will need testing anyway.

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

Right, our use-cases were less advanced... ;)

Regards,
Stijn

>
> Roland