Libertas SDIO on TC7901 Arm

[Andrey Yurovsky]

On Sun, Feb 28, 2010 at 9:36 AM, Tom Maughan <tom at tmaughan.co.uk> wrote:
> Thanks for the reply.
>
> At 19:28 26/02/2010, Andrey Yurovsky wrote:
>>
>> Hi Tom,
>>
>> On Wed, Feb 24, 2010 at 10:09 AM, Tom Maughan <tom at tmaughan.co.uk> wrote:
>> > Searching this list has been very helpful as initially I couldn't even
>> > load
>> > the firmware.   The hotplug script and adding msleep(1) into the
>> > firmware
>> > loading loop helped.
>>
>> Where in if_spi.c are you adding the msleep(1) and why?
>
> It was in if_sdio.c.

Sorry, that's what I meant.

> I was getting 'failed to load helper firmware' very early in the process.
> After reading:
> http://www.gossamer-threads.com/lists/linux/kernel/863162
>
> I added msleep(1) just after the call:
> ret = sdio_writesb(card->func, card->ioport,chunk_buffer, 64);
>
> This fixed the helper loader but the real firmware now failed to load, so I
> added the same msleep in if_sdio_prog_real.   Now it gets to the end of both
> helper and real.

Interesting!  I wonder if your controller needs time to 'settle' or
clean up after a data buffer transfer (CMF53)?  Typically the path
through the driver (and controller) is a bit different when data
buffers (vs. just a command, like CMD52) are involved.

>> For what it's worth, the Libertas SDIO driver worked quite well in
>> 2.6.24 last time I used it and a diff between that and
>> wireless-testing shows very few changes (nothing that I'd consider
>> critical anyway).  There are a few minor fixes though.
>
> This is good to know.   Chasing one bug is much easier.
>
>> Please turn on MMC debugging (CONFIG_MMC_DEBUG) and log what you see
>> from the MMC layer.
>
> I have done but the driver for this chip is VERY light on debug.   The only
> output is:
>
>> libertas thread: firmware wants 16 bytes
>> libertas thread: sending 16 bytes (32 bytes) chunk
>> tcc_mmc_start_command: opcode=53, arg=92000020
>> tcc_mmc_finish_command: R1: resp[0]=0x00002000
>> tcc_mmc_start_command: opcode=52, arg=10004000
>> tcc_mmc_finish_command: R1: resp[0]=0x0000100d
>> tcc_mmc_start_command: opcode=52, arg=10002000
>> tcc_mmc_finish_command: R1: resp[0]=0x000010b0
>> tcc_mmc_start_command: opcode=52, arg=10002200
>> tcc_mmc_finish_command: R1: resp[0]=0x00001000
>> libertas thread: firmware wants 512 bytes
>> libertas thread: sending 512 bytes (512 bytes) chunk
>
> The driver also has quite a few lines commented out and some 'fix me'
> comments.

Ah, it looks like the 2.6.24 mmc layer provides less information than
in later kernels.  On my 2.6.31 system, I have useful messages from
mmc (rather than just the controller driver).  For example:

mmc0: starting CMD53 arg 92000040 flags 000001b5
mmc0:     blksz 64 blocks 1 flags 00000100 tsac 1000 ms nsac 0

...and I can then see what SDIO command was sent, the block size, etc.
 You might want to consider carefully backporting the 2.6.31 mmc stack
to get better debugging, or at least just these debug statements.  The
stack is actually pretty self-contained in drivers/mmc/core and
include/linux/mmc in case you're interested in trying.

> I think I need to read up on SDIO and put more debug in the driver.   Its as
> if the driver has issues sending 512 byte chunks.   The helper loads OK as
> its only sent 60 bytes at a time.

Sure, and you can also modify what the driver tells the mmc stack when
it registers.  For example, max_blk_size and max_blk_count.

  -Andrey