[PATCH 2/2] spi: davinci: support adding delay between transmission

[Grygorii Strashko]

Hi Mark,

On 09/06/2014 05:31 PM, Mark Brown wrote:
> On Fri, Sep 05, 2014 at 05:21:56PM +0300, Grygorii Strashko wrote:
> 
>> I think we have some misunderstanding here :(
>> 1) All new properties a optional and should be specified for SPI Slave devices
>> 2) Seems we are talking using different terms:
>> - you referring to the term "transfers" - sequence of packets.
>>    Each packet is one transfer (array of words).
>> - while these new properties affect on "transmissions" - sequence of words.
>>    Each word is one transmission.
> 
> That's *very* unusual terminology which doesn't match my expectations at
> all.  Please describe words as words, that'll be much more obvious.

These terms are used in DM/TRM :(

I'll split this patch and first introduce WDELAY, C2TDELAY, T2CDELAY
(with updated documentation).
The only question is - Should they be somehow common or specific for spi-davinci?

> 
>> Also, below is additional information about properties which
>> are used in 5-pin mode (SPI_READY) to improve error detection
>> [OMAP-L138/da830 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf]:
> 
> This is a *whole* other thing, please split these out and work on this
> separately.  The client device is going to need to be doing the same
> thing here so implementing this as a local option in the controller
> driver isn't the best way forwards.
> 
>>>> SPIFMTn[23].PARPOL - Parity polarity: even or odd. PARPOL can be modified in privilege mode only.
>>>>    0 An even parity flag is added at the end of the transmit data stream.
>>>>    1 An odd parity flag is added at the end of the transmit data stream.
> 
>>> Why would these be specified in DT and not with runtime flags enabled by
>>> the device?  It looks like they affect the data stream generated by the
>>> controller so the client device needs to know about them; I'd expect
>>> that it's device driver would be controlling when they are enabled if
>>> the controller supports them.
> 
>> Could you clarify, pls - Do you mean that struct spi_device.mode and
>> common SPI DT bindings should be extended to support this?
> 
> Yes, if they aren't something that's purely internal to the device they
> need to be generic so that both devices can be configured appropriately.
> 

Regards,
-grygorii