SDIO firmware download error

[Dan Williams]

On Wed, 2010-03-31 at 11:11 +0100, Jonathan Cameron wrote:
> On 03/30/10 21:29, Dan Williams wrote:
> > On Thu, 2010-03-11 at 13:49 +0530, Alagu Sankar wrote:
> >> Trying my luck with a different subject as the previous one was rejected..
> >>
> >> I am in the process of adding SDIO Support for Davinci and using the
> >> Libertas SDIO driver as my standard test setup.  I am using the Linux
> >> 2.6.33-rc6 Linux kernel and the associated libertas driver. I have
> >> access to 8385, 8686 and 8688 cards from different vendors, with
> >> diferent firmware versions. I would like to get some inputs from the
> >> list for the following issue that I am facing.
> >>
> >> When I use the libertas driver as is, the helper download is always
> >> successful, but the primary firmware loading fails after the first
> >> transfer.  I get a req_size of 17 after the initial 16 byte transfer,
> >> indicating that the error bit is set. For a typical working setup,
> >> there is a 16 byte transfer, followed by a 12 byte transfer and so on.
> >>  If I introduce a delay of 2 milli-seconds between each transfer of
> >> the helper firmware, then there is no problem in downloading the
> >> primary firmware.  Even enabling the debug message
> >> "lbs_deb_sdio("sending %d bytes chunk\n", chunk_size);" alone would
> >> result in successful firmware download.
> > 
> > If we can reproduce this issue on some other platform (to determine that
> > the host controller is *not* the culprit) I'm not necessarily opposed to
> > adding a small delay during helper firmware download in the driver.  But
> > beyond adding some debugging prints to the MMC layer to conclusively
> > determine that the HC is responding correctly or incorrectly to the
> > transfers, I'm not really sure.  Are you aware of any errata for your
> > SDIO controller that might affect this?
> A similar problem exists on a pxa271.  I'm carrying the following patch
> for it...  Note this is against a fairly old kernel, 2.6.32-rc6
> 
> Symptoms were exactly the same though.  There was a previous thread on this
> list about it:
> 
> sdio 8686 firmware load problem
> 
> back on the 11th of August last year. 

Any chance if you see the issue you could make the mdelay() just a few
lines higher inside the while (1) loop into mdelay(2) ?  If that doesn't
work, move the mdelay(1) in the while(1) loop up somewhere above the "if
((status & IF_SDIO_IO_RDY) &&" part.

Dan