On Sun, Sep 30, 2012 at 12:34 PM, Roland Stigge [off-list ref] wrote:

On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote:

quoted

quoted

Problem here is that it's only an intermediate format since hardware
often needs special preparation of the data.

But will evaluate what makes most sense.

the key point here is to avoid to manipualte data each time we call
gpio_block_set

hardware specific will have to be handle at driver level

Understand, thanks! I'm just trying to prevent overly complex API because:

* In our discussed scheme, the driver still needs to convert the data bits

The u32 mask scheme fits simple-gpio drivers (1 register for input/output,
1 for direction, e.g. mpc8xxx driver) pretty well. Consider that to get
true synchronous output behavior of multiple pins, this is probably the only
option anyway.
For the cavium octeon driver (which doesn't seem to be upstream yet; sports
a single register for readout, per-pin write register) you can only emulate
group behavior by looping over the mask, without synchronous behavior.

* In practice, the block gpio API is especially useful for use on single
gpio_chips (only there, a real simultaneous i/o is possible anyway)
* Wouldn't introduce this kind of optimization in lack of measurable
improvement
* The actual i/o data bits still need handling, generating a bit CPU
load anyway.

I believe it's not worth it to try and save some tens of CPU cycles, considering
that GPIO pins might be on some slower bus anyway. Even then, simple-gpio
drivers have 0 added overhead, because they can use the mask
straight away. That means all processing is done in gpiolib's code and
is limited
to a loop of 32 iterations at most...

For drivers where performance really is critical, you could probably precompute
the needed values:
sclmask = gpio_group_precompute(MY_I2C_SCL)
sdamask = gpio_group_precompute(MY_I2C_SDA)
gpio_group_set_direct(sclmask | sdamask)

Regards,
Stijn