GSPI Support

[Dan Williams]

On Fri, 2008-10-03 at 14:50 -0400, Angel Roman wrote:
> Hi Everyone,
> 
> I successfully ported the marvell bulverde gspi driver to the mx31 
> processor using the linux spi implementation and using a GPIO as the 
> chip select - the MX31 has some issues with keeping the chip select 
> signal active for longer than 8 spi word transfers.
> 
> Unfortunately, this work cannot be open sourced due the licensing 
> agreements. However, after searching the web, looking at the libertas 
> source code and the documentation from the module vendor, I was able to 
> gather all the information to implement a GSPI extension to the libertas 
> driver.
> 
> Currently, I have TX/RX data going to and from the chip as well as CMDs 
> under linux 2.6.24.4 and I am able to establish an association with a 
> local access points. Unfortunately, I had to uncomment the DATA_RATE 
> command since non of the firmware versions available from marvell (gspi 
> 8.70.8, 9.45.3, and 0.70.3) support it.

Sorry for the lag... but

Awesome!  Note that latest libertas drivers in 2.6.26 and 2.6.27 don't
issue data rate for newer firmware (I think).

> The current status of my driver is:
> - ability to read write to all registers in the GSPI module
> - ability to send and receive data
> - ability to send commands and receive command responses.
> - ability to scan for local access points and associate with them (at 
> least the associate command is successful and it the SSID shows up in 
> the iwconfig information).

Excellent.

> Unfortunately, I am unable to receive a DHCPOFFER from my wireless 
> router At this point, I plan to get 2.6.26.5 running on my board to test 
> and work with a later version of libertas.  In the meantime, does anyone 
> have any suggested workarounds for firmware that does not support the 
> DATA_RATE command? Is this still a requirement of the latest libertas 
> driver? I assume we can do something via the RATE_ADAPT_RATESET command. 
> Any thoughts?

Latest code already uses ADAPT_RATESET and if that returns an error,
falls back to DATA_RATE.  That should be sufficient, though we should
really protect the DATA_RATE with a firmware version check.

If you could pull down the latest code from 2.6.27 (shouldn't be hard to
backport, I can certainly help with issues you might have doing that)
and check the results, I'd be quite interested to hear about them.

Thanks!
Dan