lkml.org 
[lkml]   [2018]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 1/3] spi: Introduce one new field to set word delay
Date
On čtvrtek 16. srpna 2018 14:54:49 CEST, Baolin Wang wrote:
> + * @word_delay: clock cycles to inter word delay after each word size
> + * (set by bits_per_word) transmission.

I need a similar functionality for talking to a SPI device from userspace
-- see my attempt for implementing this in spi-orion.c at [1]. The device's
datasheet says that I should wait, e.g., 3µs between each two words. I
therefore like this patch :).

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.

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?

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.

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?

With kind regards,
Jan

[1] https://patchwork.kernel.org/patch/10221397/

\
 
 \ /
  Last update: 2018-08-29 13:34    [W:1.701 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site