PXA168 + 88W8686 SDIO interrupt troubles

[Doug Brown]

On 6/10/2022 11:19 PM, James Cameron wrote:
> 
> Yay!  Well done.

Thank you!

>> 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 in fact:

https://web.archive.org/web/20150927160338/http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf

It turns out the "missing card IRQs" issue I'm running into is a known
silicon bug with the PXA168. The workaround is to reset the data port
logic after every successful SDIO transaction. However, due to another
issue described in the same errata document, this causes the clock to
stop, so you then have to do a dummy CMD0 to restart the clock (with the
CMD signal temporarily detached from the bus by setting the pin back to
a normal GPIO function, to avoid confusing the attached SDIO device).

I implemented this workaround, without the temporary detach for now
because I'm lazy, and it works perfectly. No hack to the libertas driver
necessary anymore. I'll be gradually working on getting the PXA168 SDHC
driver mainlined with the various errata fixes. Fun stuff!

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!