PXA168 + 88W8686 SDIO interrupt troubles

[James Cameron]

On Wed, Jun 15, 2022 at 07:18:13PM -0700, Doug Brown wrote:
> On 6/10/2022 11:19 PM, James Cameron wrote:
> > > On 6/9/2022 2:49 PM, Doug Brown wrote:
> > > [...]
> > > After lots of experimentation, I also changed the libertas
> > > driver to re-read the interrupt status register from the 88W8686
> > > after re-enabling the interrupts in the host controller. That
> > > caused it to stop missing interrupts, which makes no sense, but
> > > it fixed it. [...]
> > 
> > That sounds familiar, but hard to be sure given the elapsed time.
> > 
> > We certainly found a few situations where (how shall I put it) vendor
> > drivers may have driven the testing of the silicon.  We had the
> > advantage of being able to ask the vendor about it, but no longer.
> 
> As one final update on this, and for future reference for anybody else
> crazy like me, I was somehow able to track down a Marvell errata
> document for the PXA168, linked from Linux kernel documentation [...]

Yep, that's consistent with our experience with the PXA2128/mmp3.
Marvell were _very_ helpful in resolving all these problems for us as
we spooled up production.  We had numerous mainboards around the lab
tied to specific problems.

> [...] I don't see this workaround implemented in Marvell's 2.6.28
> kernel, so somehow the way they coded it wasn't affected by the
> silicon bug -- kind of goes along with what you were saying!

It is the nature of the silicon IP trade; especially around ARM
processors; sometimes a functional block doesn't work quite right in
every scenario, and up will pop an errata.  It takes someone to notice
that the specifications aren't met, even if the vendor code seems to
work fine.

Thanks for closing the loop.  It's a nice end to the story.