On Mon, Aug 01, 2022 at 11:49:09AM +0930, Andrew Jeffery wrote: > > > On Sun, 31 Jul 2022, at 06:48, Cédric Le Goater wrote: > > On 7/29/22 19:30, Peter Delevoryas wrote: > >> Certainly we'd like to use IRQ's instead, but she ran into correctness > >> problems. Maybe we can investigate that further and fix it. > > Yes, let's not work around problems that we have the ability to fix.
+1 > > > > > So much is happening in that mode. > > Yes, though while there's no-doubt accidental complexity in terms of > its implementation, the underlying hardware is also quite haphazard and > we need an approach that scales to the large number of GPIOs it > provides. So I'd argue there's a bunch of essential complexity involved > as well. +1 > > Do we start with a fresh implementation that allows us to get the > expected behaviour and then build that out to replace the current > implementation? > > Or, can we add more tests for the existing model to pin down where the > bugs are? Mmmm good question, I think we might end up doing both. Tests would make it much easier to develop either way though. > > > We need more trace events in the Aspeed > > GPIO model at least an extra in aspeed_gpio_update() > > We can always fall back to this but my hope is we can get better test > coverage to iron out the bugs. Maybe that gets us a more refined and > maintainable model implementation along the way. +1 > > Cheers, > > Andrew >