SDIO firmware download error

[Alagu Sankar]

On Thu, Apr 1, 2010 at 12:41 PM, Dan Williams <dcbw at redhat.com> wrote:
> 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
>

Tried increasing the mdelay(1) upto mdelay(5) and it did not help. But
moving the mdelay(1) above the "if ((status & IF_SDIO_IO_RDY) &&" part
and increasing it to mdelay(2) resolved the issues on Davinci
platforms.

- Alagu Sankar