mbox series

[v1,0/2] Add support for components requiring trailing clock after transfer

Message ID cover.1645950971.git.christophe.leroy@csgroup.eu
Headers show
Series Add support for components requiring trailing clock after transfer | expand

Message

Christophe Leroy Feb. 27, 2022, 10 a.m. UTC 
Some components require a few clock cycles with chipselect off before
or/and after the data transfer done with CS on.

Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK
should have one cycle before CS goes low, and two cycles after
CS goes high".

The cycles "before" are implicitely provided by all previous activity
on the SPI bus. But the cycles "after" must be provided in order to
achieve the SPI transfer.

In order to use that kind of component, implement a new option for
SPI slaves in order to implement a trailing clock of a few bits
with ChipSelect off at the end of the transfer.

This is based on a discussion we had a few years ago, see
https://lore.kernel.org/linux-spi/20160824112701.GE22076@sirena.org.uk/

IDT 801034 QUAD PCM CODEC datasheet can be found at
https://www.renesas.com/eu/en/document/dst/821034-data-sheet?language=en&r=24763

Christophe Leroy (2):
  spi: Add new mode to generate additional clock cycles
  spi: fsl-spi: Implement trailing clock mode

 .../bindings/spi/spi-peripheral-props.yaml        |  4 ++++
 drivers/spi/spi-fsl-lib.c                         |  2 +-
 drivers/spi/spi-fsl-spi.c                         | 15 +++++++++++++--
 drivers/spi/spi.c                                 |  5 ++++-
 include/uapi/linux/spi/spi.h                      |  3 ++-
 5 files changed, 24 insertions(+), 5 deletions(-)

Comments

Mark Brown Feb. 28, 2022, 1:20 p.m. UTC | #1 
On Sun, Feb 27, 2022 at 11:00:35AM +0100, Christophe Leroy wrote:

> +	if (!status && spi->mode & SPI_TRAILING) {
> +		struct spi_transfer t = {
> +			.len = 1,
> +			.tx_buf = "",
> +			.bits_per_word = 4
> +		};
> +
> +		status = fsl_spi_setup_transfer(spi, &t);
> +		if (!status)
> +			status = fsl_spi_bufs(spi, &t, 0);
> +	}
> +	m->status = status;

This seems to be begging for a generic implementation in the core rather
than being driver specific - drivers would for the most part need
updating to advertise less than 8 bit per word transfers but the basic
operation isn't really device specific and it pretty much fits with the
existing interfaces.