libertas: GSPI device patch performance

[Dan Williams]

On Sun, 2009-03-29 at 13:47 +0800, Mok Keith wrote:
> Hi all,
> 
> For the patch for GSPI devices, do we really need to create another
> kernel thread for sending spi command. Since doing so, we need to
> memcpy all the data from host to card, and it reduces performance. 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. Since
> hw_host_to_card is called by a kernel thread (lbs_thread) in main.c.

It depends on how if_spi_host_to_card() is really implemented by the
platform SPI driver whether or not it needs to sleep; the mainloop is
holding a spinlock with interrupts disabled.

The SPI controller may well have alignment restrictions that require
copying and realigning the data on certain boundaries; there's no
guarantee that priv->tx_pending_buf will be aligned on those boundaries.
It'll be aligned to _something_ since it's not a member of a packed
struct, but that's dependent on the compiler flags at build-time rather
than the actual hardware requirements.

All that said, I don't see anything offhand that would prevent
tx_pending_buf being used directly by those interface drivers that need
it.  The device's queue should be blocked until the card has finished
processing the packet in lbs_send_tx_feedback().  Need to verify that in
all the corner cases though (like error conditions) that the main stack
won't overwrite priv->tx_pending_buf before the card is done with it.

Second, are you sure the memcpy is the bottleneck?  ie, is that memcpy
the bottleneck, or are there other bottlenecks in the driver or your SPI
controller code that are causing problems?

Thoughts Colin?

Dan


> For interrupt event, we can just do a scheduled work to read the event cause.
> 
> Keith Mok
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev