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