On Wed, Aug 29, 2018 at 01:33:24PM +0200, Jan Kundrát wrote:

On čtvrtek 16. srpna 2018 14:54:49 CEST, Baolin Wang wrote:

quoted

+ * @word_delay: clock cycles to inter word delay after each word size
+ *	(set by bits_per_word) transmission.

The description can be improved because it left me wondering what "clock
this is about. I suppose it's about the SPI clock cycles and not CPU clock
cycles, right? I'll be hapy to patch this once Baolin confirms that that is
the intended meaning.

That's certainly how I read it.

It seems that this is only implemented in one newly added driver. I'm
interested in supporting this in spi-orion.c, but that sounds like
driver-specific work for something which is pretty generic. How should this
be implemented? Given that drivers for SPI masters can implement a function
which transfers several words at once, there are not that many better
possibilities than adding udelay()s, though. Thoughts?

Yeah, you'd need to split the transfer into words and then add a delay
between which would be rather expensive but it's about as good as we can
get I think.

What is your plan to do with drivers which do not implement this (yet)? If a
spi_transfer gets queued which asks for a word_delay delay, it is silently
ignored now, AFAIU.

Yes.  A generic handler would be best.

What about userspace support, spidev and spi_ioc_transfer (that's my target,
actually)? Is it OK to s/pad/word_delay/ in the spidev code and pass that to
the generated struct spi_transfer? In my opinion, once we support specifying
this from userspace, one has to definitely check that the SPI controller is
ready to honor this request. Do we want a new bit in spi_controller.flags
for this?

Not seeing pad in the spidev code?  A feature flag would make sense along
with a generic implementation.