SPI trouble on Colibri 270 (PXA)...

[Eric Miao]

On Sat, Apr 24, 2010 at 3:57 AM, Jakob Viketoft <jakob at viketoft.se> wrote:
> Vernon Sauder wrote:
>>
>> Jakob Viketoft wrote, On 04/22/2010 10:36 AM:
>
> <...>
>>>
>>> The original code currently combines the two transfers in one message as
>>> you say (leaving CS asserted unless cs_change is set). However, I don't
>>> know if it's a problem with scheduling or that the interrupt takes too
>>> long to serve, but on my platform the two transfers (in the same
>>> message) doesn't go back-to-back as they should and CS gets deasserted
>>> in the middle. Thus I have combined the two transfers into one and the
>>> message only hold this single transfer. Now things work at my end, but
>>> it's annoying that I don't have time to track down the real issue at the
>>> moment...
>>>
>>>    /Jakob
>>>
>>
>> As part of this thread:
>> http://permalink.gmane.org/gmane.linux.kernel.spi.devel/1517
>> I added the following note to Documentation/spi/pxa2xx. I have not
>> checked to see if the patch hit mainline. Is this part of the answer to
>> your question?
>>
>>> +NOTE: the SPI driver cannot control the chip select if SSPFRM is used,
>>> so the
>>> +chipselect is dropped after each spi_transfer.  Most devices need chip
>>> select
>>> +asserted around the complete message.  Use SSPFRM as a GPIO (through
>>> cs_control)
>>> +to accomodate these chips.
>>
>> That was my solution to using the pxa2xx SPI with M25Pxx flash.
>>
>
> Yes, I saw that note in the documentation. Unfortunately it wasn't what was
> causing my problem. I think a code patch has been applied to control  the
> SSPFRM as a gpio through the .gpio_cs option, but this seem to be missing
> from the documentation.
>

You want to configure the SSPFRM pin as generic GPIO with MFP API
as well, if you want to set that pin as .gpio_cs.

> From the sound of it, I think I'm running into the same kind of trouble as
> shown by the SPI controller on the EP93xx.
>
>        /Jakob
>