lkml.org 
[lkml]   [2018]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/4] spi: add new SPI_CS_WORD flag
From
Date


On 7/18/18 10:04 AM, Mark Brown wrote:
> On Mon, Jul 16, 2018 at 10:20:50PM -0500, David Lechner wrote:
>> This adds a new SPI mode flag, SPI_CS_WORD, that is used to indicate
>> that a SPI device requires the chip select to be toggled after each
>> word that is transferred.
>
> This feels like it should have a soft implementation if it is going to
> be truly usable, the vast majority of SPI controllers don't do this and

This occurred to me as well. Another possibility, though, would be to
leave it up to the client device drivers to support both cases, e.g.:

if (master has SPI_CS_WORD support)
setup message as single transfer
else
setup message as multiple one-word transfers

This seems like that would be more efficient than having a generic
implementation for masters that says:

if (master does not have SPI_CS_WORD support)
allocate enough transfers for each word of each
each transfer of the message
allocate and setup a new message for these transfers
loop through the original transfers of the original
message and copy them to the new transfers
send the new message
free allocated message and transfers

> I can only think of a few that have the hardware feature. I'd also
> expect to see some validation added to the core spi_setup() since at
> present a client driver could set the mode option but then have it
> ignored by the controller which would presumably break things, we
> currently only have checks for specific modes and nothing that'd catch
> an unknown flag like this.

There is already a generic mode flags check in spi_setup() that will
catch this and return an error if the device has the SPI_CS_WORD flag
set and the controller does not. (I know this works because I ran into
it during development.)

>
> Ideally we'd also have some ability to use this as an optimization where
> possible with longer sequences (I can see a regmap cache sync being able
> to take advantage of this for example) but that might be more trouble
> than it's worth.
>

\
 
 \ /
  Last update: 2018-07-18 18:48    [W:0.078 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site