spibus access serialization

[Luiz Otavio O Souza]

On Sep 2, 2012, at 4:38 PM, Warner Losh wrote:
> 
> On Sep 2, 2012, at 10:15 AM, Ian Lepore wrote:
> 
>> On Sun, 2012-09-02 at 08:47 -0600, Warner Losh wrote:
>>> On Sep 2, 2012, at 6:37 AM, Luiz Otavio O Souza wrote:
>>> 
>>>> 
>>>> The spi controller on arm/at91/at91_spi.c wasn't changed because looks like it will be need to move the device CS control from the controller and use it as a GPIO pin. I need to read more of at91 code before i can suggest some change there. Until there it will work just as now (no serialization and selecting/deselecting the device within each transfer).
>>> 
>>> The at91_spi controller controls which CS line is asserted.  So long as you don't change the bits in the registers, it will stay asserted.  I think it can fit with this scheme.  I'll have to take a closer look.  All my AT91 devices have only one chip on the spi bus.
>> 
>> Unfortunately, the atmel SPI controller will de-assert the chip select
>> when the transmit register (or PDC) runs out of data.  It's a bug that
>> may only affect rm9200; I haven't checked the errata and docs for the
>> sam9 series to see if they fixed it.
> 
> Yes, that's been fixed (which is why I didn't think it would be a problem, but it is).
> 
>> The way to fix the problem is indeed to take over the handling of chip
>> selects in the driver, by taking the pins away from the device and
>> managing them as GPIOs.  Doing that is on my to-do list, but I've been
>> waiting for some resolution of the "how do we manage device/gpio pin
>> setup across the atmel SoC family" questions.
> 
> That's the question still, alas.  I've been looking at how FDT does it in Linux land, and they punt on this issue.  We'll likely have to put some effort into defining these things with atmel's FDT efforts.  Their FDT comes close by defining groups, but doesn't seem to take it down to the individual pin to signal mapping.
> 
> Otherwise we'll have to fall back to arrays of pins that somehow get associated with the device...
> 
>> This auto-deassert in rm9200 is also the bug that causes us to run the
>> SPI bus at roughly 1/20th of its rated speed, to ensure that we never
>> get a spurios chip de-select in the middle of a transfer due to
>> momentary PDC bus starvation.
> 
> Yes.  The SAM9 processors have a new bit, CSAAT, which forces the line to be asserted until you deassert it, not just during data transfers.  A quick grep of the code indicates that we don't use it, but I haven't checked in detail...

Hmm. I was thinking that using CSAAT was the only way to control the CS pin from GPIO, but i didn't knew that CSAAT was something new (i was reading the SAM9260 datasheet).

Now I have no idea how to overcome that on older chips.

> 
>> Speaking of SPI bus speed, that's the other wart in our SPI support.  We
>> need a speed limit member in the spi request structure, so that drivers
>> of individual devices on the bus can indicate the limit for their
>> specific devices.  I'd be happy to see that get added sooner rather than
>> later, even if it takes a while to get all the low-level drivers
>> supporting it.  I think the new field in the struct should indicate the
>> fastest speed in Hz that the device can handle the bus running, with
>> zero meaning no limit.
> 
> Yes.  And SPI mode too.  These items should be programmed when the bus is requested, imho, but perhaps there's a reason not to do this.

The actual patch is just one piece of Patrick Kelsey's work on MMC/SD SPI driver (http://freebsd.1045724.n5.nabble.com/PATCH-MMC-SD-SPI-mode-driver-td5554034.html) which include new methods to limit the SPI speed for a device.

I'm breaking the patch in smaller parts so it can be easily reviewed.


Luiz