[V3,3/9] spi: add SPI_LSBYTE_FIRST mode
diff mbox series

Message ID 1555363834-32155-4-git-send-email-skomatineni@nvidia.com
State New, archived
Headers show
Series
  • bug fixes and more features to Tegra SPI
Related show

Commit Message

Sowjanya Komatineni April 15, 2019, 9:30 p.m. UTC
Some SPI slaves expect bytes to be in least significant first order
and some expects most significant first oder.

This patch adds support for requesting SPI master controllers for
least significant first order using SPI_LSBYTE_FIRST mode.

Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
---
 drivers/spi/spi.c       | 18 ++++++++++--------
 include/linux/spi/spi.h |  1 +
 2 files changed, 11 insertions(+), 8 deletions(-)

Comments

Mark Brown April 19, 2019, 3:22 p.m. UTC | #1
On Mon, Apr 15, 2019 at 02:30:28PM -0700, Sowjanya Komatineni wrote:
> Some SPI slaves expect bytes to be in least significant first order
> and some expects most significant first oder.
> 
> This patch adds support for requesting SPI master controllers for
> least significant first order using SPI_LSBYTE_FIRST mode.

This is byte ordering as opposed to bit ordering which the core already
supports.  Do you have any examples of devices that need this or is it
just being added for completeness?  If devices are going to rely on this
we probably need emulation support in the core I guess given that this
is a pretty unusual controller feature.
Sowjanya Komatineni April 27, 2019, 12:32 a.m. UTC | #2
> On Mon, Apr 15, 2019 at 02:30:28PM -0700, Sowjanya Komatineni wrote:
> > Some SPI slaves expect bytes to be in least significant first order 
> > and some expects most significant first oder.
> > 
> > This patch adds support for requesting SPI master controllers for 
> > least significant first order using SPI_LSBYTE_FIRST mode.
>
> This is byte ordering as opposed to bit ordering which the core already supports.  Do you have any examples of devices that need this or is it just being added for completeness?  If devices are going to rely on this we probably need emulation > support in the core I guess given that this is a pretty unusual controller feature.

Current upstream platforms have no specific device requirement but added this feature as Tegra support it for specific requirements of some slaves.

[Changed mail client message format word wrap limit to 74 columns]

Thanks
Sowjanya
Mark Brown May 6, 2019, 4:49 a.m. UTC | #3
On Sat, Apr 27, 2019 at 12:32:58AM +0000, Sowjanya Komatineni wrote:
> > On Mon, Apr 15, 2019 at 02:30:28PM -0700, Sowjanya Komatineni wrote:

> > This is byte ordering as opposed to bit ordering which the core
> > already supports.  Do you have any examples of devices that need
> > this or is it just being added for completeness?  If devices are
> > going to rely on this we probably need emulation > support in the
> > core I guess given that this is a pretty unusual controller feature.

> Current upstream platforms have no specific device requirement but
> added this feature as Tegra support it for specific requirements of
> some slaves.

Do we have any examples of such devices?  In any case I think the main
thing here would be a software implementation of the feature so that
drivers can use it sensibly - at the minute they'd have to provide code
to work without the feature anyway and it seems like a relatively small
optimization for most things.

> [Changed mail client message format word wrap limit to 74 columns]

It's not working, and it's also mangling quoted sections of the mail
too.

Patch
diff mbox series

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index bf4027b54a19..59b1e57cae74 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -2982,14 +2982,16 @@  int spi_setup(struct spi_device *spi)
 
 	spi_set_cs(spi, false);
 
-	dev_dbg(&spi->dev, "setup mode %d, %s%s%s%s%u bits/w, %u Hz max --> %d\n",
-			(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
-			(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
-			(spi->mode & SPI_LSB_FIRST) ? "lsb, " : "",
-			(spi->mode & SPI_3WIRE) ? "3wire, " : "",
-			(spi->mode & SPI_LOOP) ? "loopback, " : "",
-			spi->bits_per_word, spi->max_speed_hz,
-			status);
+	dev_dbg(&spi->dev,
+		"setup mode %d, %s%s%s%s%s%u bits/w, %u Hz max --> %d\n",
+		(int) (spi->mode & (SPI_CPOL | SPI_CPHA)),
+		(spi->mode & SPI_CS_HIGH) ? "cs_high, " : "",
+		(spi->mode & SPI_LSB_FIRST) ? "lsb, " : "",
+		(spi->mode & SPI_LSBYTE_FIRST) ? "lsbyte, " : "",
+		(spi->mode & SPI_3WIRE) ? "3wire, " : "",
+		(spi->mode & SPI_LOOP) ? "loopback, " : "",
+		spi->bits_per_word, spi->max_speed_hz,
+		status);
 
 	return status;
 }
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 053abd22ad31..fc4d21b4c2e4 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -164,6 +164,7 @@  struct spi_device {
 #define	SPI_TX_OCTAL	0x2000			/* transmit with 8 wires */
 #define	SPI_RX_OCTAL	0x4000			/* receive with 8 wires */
 #define	SPI_3WIRE_HIZ	0x8000			/* high impedance turnaround */
+#define SPI_LSBYTE_FIRST	0x10000		/* per-word bytes-on-wire */
 	int			irq;
 	void			*controller_state;
 	void			*controller_data;