On Fri, Sep 6, 2019 at 11:46 AM David Laight <David.Laight@xxxxxxxxxx> wrote: > > On 06/09/2019 09:05:36+0000, David Laight wrote: > > It does improve gpio switching synchronisation when they are in the same > > bank as it will remove the 250ns delay. Of course, if you need this > > delay between clk and data, then the consumer driver should ensure the > > delay is present. > > With multiple requests the output pin changes will always be in the > same order and will be separated by (say) 250ns. > This is a guaranteed synchronisation. Do you mean that hardware will guarantee this synchronization? Linux device driver code cannot rely on that. We will simply grab two individual GPIO lines (not get_multiple()) then issue set() on the clock, ndelay(250) and then set() data. It doesn't matter much because bitbanging is always extremely slow anyways so one will get lots of delay, which is why e.g. spi-gpio doesn't insert any delay IIRC. The point is that the lines need be grabbed individually so the delay between can be controlled. > IIRC both SMBus and I2C now quote 0ns setup time. > Changing both clock and data with the same IOW isn't enough to > guarantee this. > (In practise the I2C setup time required by a device is probably > slightly negative (In order to support 0ns inputs) so a very small > -ve setup will (mostly) work.) If you are referring to drivers/i2c/busses/i2c-gpio.c it does seem to do proper delays using bit_data->udelay from the bitbang library. Yours, Linus Walleij