Re: [RFC, PATCH, RESEND] spi, spidev: Add support for long SPI transfers

[Mark Brown]

On Tue, Nov 25, 2014 at 01:18:45PM -0800, Andrey Smirnov wrote:

> >> in my wording of the summary and not use the word "transfer" anywhere,
> >> but it looks like I slipped twice and that might have contributed to
> >> this confusion. I apologize for this and hope that my comments
> >> clarified my meaning/intent

> > Sorry it's still not at all clear, please re-read what I wrote about
> > what bits_per_word means since I really don't think you've understood
> > what it's for.

> OK, I think I use too generic terms and descriptions and maybe that's
> why it is not very clear what I mean. Just to give more context I am
> working with i.MX6 SPI peripheral, and AFAIK I have two options of
> using it:

Ah, i.MX...  When I've worked with it I managed the chip select with
GPIO since it was flipping the chip select per word.

> - Use a generic GPIO as SS/CS. This way everything works exactly as
> you describe, but unfortunately using GPIO leads to a significant
> overhead for SS/CS assertion/deassertion.

It's really surprising that it's expensive to use a GPIO, I've not seen
other users complaining about that.  Do we understand why (I'm guessing
you have some extremely performance sensitive application here so you're
just more picky than most)?

> - Use hardware controlled SS/CS in which case peripheral toggles the
> line every "burst" it transmits, "burst" is n bits where n can be from
> 1 to 2^12
>  For 1 <= n <= 32, and software SS/CS the concept of a "burst" matches
> the meaning of "bits_per_word" field and this is exactly how it is
> setup in the driver.

But if we go over 32 bits it doesn't do the byte swapping?  Hardware
designers are wonderful, creative people sometimes.  In general this
isn't going to be sufficient for all transfers even with the non swapped
case since it means we can't do more than one transfer per message
unless we start coalescing in the core and putting in dummies for cases
where transfers change (we should do these things, they're a win in
general since we can just set the message up and let the hardware do the
transfer, but it's not completely trivial).

> So with all of this in mind what I am trying to achive is to have
> longest transaction with minimal CS/SS switching overhead. The change
> in my patch allows me to set the length of a burst to its limit.

The driver should probably just be doing that where it can, it seems
like the burst size should be based on the transfer length not the word
size - we might need to just manually mangle the data for short
transfers.

The *easiest* thing would be to manage as a GPIO, though - it's normally
fast enough.  Some more information about your application might help -
what sort of transfers is it doing for example?

Attachment: signature.asc
Description: Digital signature