From mboxrd@z Thu Jan  1 00:00:00 1970
From: grygorii.strashko@ti.com (Grygorii Strashko)
Date: Mon, 8 Sep 2014 16:30:57 +0300
Subject: [PATCH 2/2] spi: davinci: support adding delay between
 transmission
In-Reply-To: <20140906143113.GI2601@sirena.org.uk>
References: <1408634706-5762-1-git-send-email-grygorii.strashko@ti.com>
 <1408634706-5762-3-git-send-email-grygorii.strashko@ti.com>
 <20140821182035.GM24407@sirena.org.uk> <53F74695.3010902@ti.com>
 <20140822150644.GX24407@sirena.org.uk> <5409C704.5070303@ti.com>
 <20140906143113.GI2601@sirena.org.uk>
Message-ID: <540DAF91.6090002@ti.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

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