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.
>
> 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.
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?
> 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.
Cheers,
Andrew
