libertas SPI Interface and the GPIO / chipselect issue

[Andrey Yurovsky]

On Tue, May 26, 2009 at 2:12 PM, David Brownell <david-b at pacbell.net> wrote:
> 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

Thanks Dave (and also Sebastian).  I suspect that we've made some
incorrect assumptions and I will test this with the SPI controller in
question.  I need to rewire my boards to connect the SPI controller
Chip Select signal to the WiFi module and test things.  I intend to
submit a patch to if_spi.c that removes the use of GPIO chip select
entirely.

  -Andrey