libertas: GSPI device patch performance

[Colin McCabe]

Hi Mok.

On Sat, Mar 28, 2009 at 10:47 PM, Mok Keith <ek9852 at gmail.com> wrote:
> Can
> we just send the command directly in host_to_card function, I believe
> the comment that if_spi_host_to_card can't sleep is wrong.

In libertas/main.c, you'll find the following code...

spin_lock_irq(&priv->driver_lock);
if (!priv->dnld_sent && priv->tx_pending_len > 0) {
    int ret = priv->hw_host_to_card(priv, MVMS_DAT,
                                                          priv->tx_pending_buf,
                                                          priv->tx_pending_len);
   < .... >
spin_unlock_irq(&priv->driver_lock);

We can't sleep while holding the spinlock, with interrupts disabled.
Now... some particular SPI drivers might busy-wait instead of
sleeping. But in general spi_read / spi_write are "slow" operations
that can block.

I don't think eliminating memcpy is the low-hanging fruit here.
One thing that I always wanted to try is boosting the priority of
lbs_spi_thread.
Scheduler latencies are measured in milliseconds.
I observed a noticeable performance different when adjusting the
scheduler quantum.

Also, if you have a newer WLAN module, you can try reducing the
ndelay() value in spu_transaction_init.
The 400 ns value is a conservative number put there to accommodate the
oldest possible chiprev. I would have liked to load different values
there for different chips, but again, never got time to calibrate.

There is also a way to reduce the number of dummy clocks per
transaction by sending a CMD_GSPI_BUS_CONFIG.
The usage is fairly arcane. You must send the command to the WLAN
module (not the SPU) after loading the firmware.
As far as I know, there is no way to know what the minimum number of
dummy clocks is for your chip other than trial and error...

Good luck with your optimizations. Hope this was helpful.

regards,
Colin