Re: [PATCH] spi: pxa2xx_spi introduce chip select gpio to simplify the common cases

[Jonathan Cameron <jic23-KWPb1pKIrIJaa/9Udqfwiw@public.gmane.org>]

David Brownell wrote:
> On Thursday 11 September 2008, Ned Forrester wrote:
> 
>> I'm puzzled.  What is there about the pxa2xx_spi.c that would be
>> simplified by doing anything with respect to SSPFRM?
> 
> The usage model ... callers must understand that option,
> evaluate whether it's even usable on their board, and
> then have an extra set of possibilities to debug.  And
> it's not a model needed with other SPI controllers...
> 
> The code ... has to support that more complex model.
> 
> Developers ... have to answer questions about that
> mechanism when they could be doing more useful things.

Having converted the boards I use over to a gpio model
(was all sfrm based before) I agree that this is probably 
the way to go.

There are a few use cases though where using the hardware
support (though broken as it is) would give higher performance.

For some devices it is necessary to deselect them for
between transfers for an amount of time equal to say 
4 times the SCK period.  Clearly the only way to
make this happen on various spi controllers is to 
set mdelay_usecs to the best value you can manage.
(at high speed this is somewhat tedious, and in most cases
the time to turn the gpio off and on again is sufficient)

However, there is always a fixed min delay between the 
transfers due to the passing of interrupts back to the
driver etc so in many cases the use of SFRM allows
this to be harnessed as it switches much closer to the
actual transmission than a gpio based control. 

As an example, take the vti sca3000 range of accelerometers.
The specs say that they must be deselected for 4 * the SCK
period.  As some of these devices go at 325kHz this comes
to 12.3 microsecs and a typical time I've observed for gpio
deselecting is only 7 microsecs this would be a device that
would benefit from such strategy (as long as the board
config had the option of specifying a minimum delay between
SRFM being deselected and control hitting the delay_usecs
code in pxa2xx_spi.c.

Still, despite the above being the case, I'm inclined
to agree that at the very least people should be strongly
discouraged from using SRFM!

Jonathan

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/