libertas SPI Interface and the GPIO / chipselect issue

David Brownell david-b at pacbell.net
Tue May 26 17:12:10 EDT 2009


On Friday 22 May 2009, Andrey Yurovsky wrote:
> Hi Sebastian.  We're indeed working on converting the transfers to
> spi_async() for other reasons, but that's an interesting point.  For
> GSPI we require "transaction"-style chip select, and if all
> controllers can do that, we're fine, however many of the ones I've
> seen toggle the chip select every X bytes, where X is the register
> size (8, 16, or 32-bit) regardless of how the host sees it.

The requirement for any SPI controlller driver in Linux is that it
hold the chipselect active for the entire spi_message ... with a
small exception that kicks in if cs_change is set.  (That allows
one message to package a group of transfers, each of which needs
to be terminated by chip de-select and all of which need to be
completed in sequence, as a group.)

That's a basic definitional thing.  If there's a hardware notion
of chipselect that doesn't work that way, it must not be used.
It's usually easy enough to just use a GPIO.

Deactivating chipselect is a protocol operation, and it must not be
done except at clearly defined moments.


So I'm thinking this driver must currently be written to assume a
deeply buggy spi_master controller driver... I noticed this in
the libertas/if_spi.c code:

> >         /* Pin number for our GPIO chip-select. */
> >         /* TODO: Once the generic SPI layer has some additional
> >          * features, we should take this out and use the normal
> >          * chip select here.  We need support for chip select
> >          * delays, and not dropping chipselect after each word. */
> >         int                             gpio_cs;

That fairly reeks of relying on a buggy spi_master driver.

There is *NO WAY* that a spi_master driver should ever drop
chipselect after each word.  No spi_driver needs to defend
against such bugs.

Similarly, there are some per-"spi_transfer" delays that have
so far sufficed to address the need for protocol delays, and
that includes delays between chipselect and data transfer,
on both sides.

- Dave





More information about the libertas-dev mailing list