On Sun, Sep 30, 2012 at 12:34 PM, Roland Stigge <sti...@antcom.de> wrote: > On 29/09/12 21:57, Jean-Christophe PLAGNIOL-VILLARD wrote: >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/