From: Angus G. <gu...@pr...> - 2014-12-11 00:36:59
|
Hi Jean-Christian, Glad you got the patch working with overrun mode. I have another minor comment on the patch but I'll make it via the gerrit interface. On Thu, Dec 11, 2014 at 01:08:47AM +0100, Jean-Christian de Rivaz wrote: > It make sense to fit the general organization of current OpenOCD code, but > using the sticky bits on a sysfsgpio driver is slow and against the purpose > of the sticky bits. Sticky bits have been designed for high latency and high > throughput driver, witch is exactly the contrary of the the sysfsgpio > driver: it has no latency at all and his throughput is minimal. But I agree > that this is the best solution to not touch more files with the patch. > >(As written, the driver in the patch still behaves a bit as if it were > >in overrun mode - it clocks the data bits regardless of the command > >response. It looks like you could change this instead without too much > >trouble, but I think supporting overrun is a better idea if possible to > >avoid another special case in the higher layer.) Yes, I agree on all these points. Although it's worth noting that overrun mode only hurts throughput in cases where you have a lot of FAULTs or WAITs - which is hopefully not the case most important to optimise for. The instances I've seen of WAIT states is still that even when they predictably happen they're thrown only occasionally, maybe 1% of transfers at most. Maybe that's not universal though (and it's been using openocd with the 'additional clocks' workaround in there, so maybe that changes things a bit). I should also confess I'm not an openocd developer, so the actual developers might have a different opinion about whether the higher transport layer should know what the preferences of the adapter are re:overrun mode. Angus |