On Sat, Nov 20, 2021 at 1:40 PM Andreas Fritiofson <andreas.fritiof...@gmail.com> wrote: > > > > On Fri, Nov 19, 2021 at 11:31 AM Laszlo Sitzer <dlsit...@gmail.com> wrote: >> >> >> I wanted to ask if there is anything speaking against making linuxgpio.c >> support >> using pin of multiple GPIO ports/chip (and not only of one as it is right >> now). >> > > Are gpiod accesses synchronous even across different chips? Otherwise it > probably won't work to have e.g. TCK and TMS on different chips. With that > caveat it seems like a good improvement to OpenOCD.
Andreas, sysfsgpio driver cannot guarantee synchronous access to two gpios, but it worked well, so far. Also gpiod cannot guarantee synchronous access to GPIOs that are on different gpiochip, not only when they are on GPIO expander on I2C, but even when they are peripherals part of the same SoC. JTAG spec requires TMS to be sampled on TCK rising edge (even if I'm aware of bogus chips whose boundary scan samples TMS on TCK falling edge). src/jtag/drivers/bitbang.c changes TMS and TDI on falling edge of TCK and keeps them stable during rising edge of TCK. So this change should be ok. Nevertheless, it could be interesting to add a slower "safe mode" to our bitbang driver to change TMS and TDI only during TCK level low, so to handle bogus chips too. Laszlo, I forgot to mention that any change that modifies the existing commands should provide a backward compatible mode to help those users that have their own private configuration scripts. The driver should accept the old syntax and dump a DEPRECATED message. After a few years the old syntax would be dropped. >From another msg I sent to the list, this driver has no documentation of its commands. It's the fault of the initial developer of that driver (me!!!), so you are not forced to add it, the initial developer can do it after your patch. Antonio
