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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
