2018-07-24 21:04:02 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
|
|
|
//
|
|
|
|
// Copyright 2013 Freescale Semiconductor, Inc.
|
2020-04-24 14:12:16 +08:00
|
|
|
// Copyright 2020 NXP
|
2018-07-24 21:04:02 +08:00
|
|
|
//
|
|
|
|
// Freescale DSPI driver
|
|
|
|
// This file contains a driver for the Freescale DSPI
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2014-09-29 10:57:06 +08:00
|
|
|
#include <linux/clk.h>
|
|
|
|
#include <linux/delay.h>
|
2016-11-10 20:19:15 +08:00
|
|
|
#include <linux/dmaengine.h>
|
|
|
|
#include <linux/dma-mapping.h>
|
2014-09-29 10:57:06 +08:00
|
|
|
#include <linux/interrupt.h>
|
2013-08-16 11:08:55 +08:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
2014-09-29 10:57:06 +08:00
|
|
|
#include <linux/of_device.h>
|
2015-06-13 00:55:22 +08:00
|
|
|
#include <linux/pinctrl/consumer.h>
|
2014-02-12 15:29:05 +08:00
|
|
|
#include <linux/regmap.h>
|
2013-08-16 11:08:55 +08:00
|
|
|
#include <linux/spi/spi.h>
|
2017-10-28 06:23:01 +08:00
|
|
|
#include <linux/spi/spi-fsl-dspi.h>
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:02 +08:00
|
|
|
#define DRIVER_NAME "fsl-dspi"
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:02 +08:00
|
|
|
#define SPI_MCR 0x00
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_MCR_MASTER BIT(31)
|
2020-03-18 08:15:52 +08:00
|
|
|
#define SPI_MCR_PCSIS(x) ((x) << 16)
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_MCR_CLR_TXF BIT(11)
|
|
|
|
#define SPI_MCR_CLR_RXF BIT(10)
|
|
|
|
#define SPI_MCR_XSPI BIT(3)
|
2020-04-24 14:12:16 +08:00
|
|
|
#define SPI_MCR_DIS_TXF BIT(13)
|
|
|
|
#define SPI_MCR_DIS_RXF BIT(12)
|
|
|
|
#define SPI_MCR_HALT BIT(0)
|
2019-08-19 02:01:02 +08:00
|
|
|
|
|
|
|
#define SPI_TCR 0x08
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_TCR_GET_TCNT(x) (((x) & GENMASK(31, 16)) >> 16)
|
|
|
|
|
|
|
|
#define SPI_CTAR(x) (0x0c + (((x) & GENMASK(1, 0)) * 4))
|
|
|
|
#define SPI_CTAR_FMSZ(x) (((x) << 27) & GENMASK(30, 27))
|
2019-08-19 02:01:06 +08:00
|
|
|
#define SPI_CTAR_CPOL BIT(26)
|
|
|
|
#define SPI_CTAR_CPHA BIT(25)
|
|
|
|
#define SPI_CTAR_LSBFE BIT(24)
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_CTAR_PCSSCK(x) (((x) << 22) & GENMASK(23, 22))
|
|
|
|
#define SPI_CTAR_PASC(x) (((x) << 20) & GENMASK(21, 20))
|
|
|
|
#define SPI_CTAR_PDT(x) (((x) << 18) & GENMASK(19, 18))
|
|
|
|
#define SPI_CTAR_PBR(x) (((x) << 16) & GENMASK(17, 16))
|
|
|
|
#define SPI_CTAR_CSSCK(x) (((x) << 12) & GENMASK(15, 12))
|
|
|
|
#define SPI_CTAR_ASC(x) (((x) << 8) & GENMASK(11, 8))
|
|
|
|
#define SPI_CTAR_DT(x) (((x) << 4) & GENMASK(7, 4))
|
|
|
|
#define SPI_CTAR_BR(x) ((x) & GENMASK(3, 0))
|
2019-08-19 02:01:02 +08:00
|
|
|
#define SPI_CTAR_SCALE_BITS 0xf
|
|
|
|
|
|
|
|
#define SPI_CTAR0_SLAVE 0x0c
|
|
|
|
|
|
|
|
#define SPI_SR 0x2c
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_SR_TCFQF BIT(31)
|
|
|
|
#define SPI_SR_EOQF BIT(28)
|
2019-08-19 02:01:05 +08:00
|
|
|
#define SPI_SR_TFUF BIT(27)
|
|
|
|
#define SPI_SR_TFFF BIT(25)
|
|
|
|
#define SPI_SR_CMDTCF BIT(23)
|
|
|
|
#define SPI_SR_SPEF BIT(21)
|
|
|
|
#define SPI_SR_RFOF BIT(19)
|
|
|
|
#define SPI_SR_TFIWF BIT(18)
|
|
|
|
#define SPI_SR_RFDF BIT(17)
|
|
|
|
#define SPI_SR_CMDFFF BIT(16)
|
|
|
|
#define SPI_SR_CLEAR (SPI_SR_TCFQF | SPI_SR_EOQF | \
|
|
|
|
SPI_SR_TFUF | SPI_SR_TFFF | \
|
|
|
|
SPI_SR_CMDTCF | SPI_SR_SPEF | \
|
|
|
|
SPI_SR_RFOF | SPI_SR_TFIWF | \
|
|
|
|
SPI_SR_RFDF | SPI_SR_CMDFFF)
|
2019-08-19 02:01:02 +08:00
|
|
|
|
|
|
|
#define SPI_RSER_TFFFE BIT(25)
|
|
|
|
#define SPI_RSER_TFFFD BIT(24)
|
|
|
|
#define SPI_RSER_RFDFE BIT(17)
|
|
|
|
#define SPI_RSER_RFDFD BIT(16)
|
|
|
|
|
|
|
|
#define SPI_RSER 0x30
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_RSER_TCFQE BIT(31)
|
|
|
|
#define SPI_RSER_EOQFE BIT(28)
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
#define SPI_RSER_CMDTCFE BIT(23)
|
2019-08-19 02:01:02 +08:00
|
|
|
|
|
|
|
#define SPI_PUSHR 0x34
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_PUSHR_CMD_CONT BIT(15)
|
|
|
|
#define SPI_PUSHR_CMD_CTAS(x) (((x) << 12 & GENMASK(14, 12)))
|
|
|
|
#define SPI_PUSHR_CMD_EOQ BIT(11)
|
|
|
|
#define SPI_PUSHR_CMD_CTCNT BIT(10)
|
|
|
|
#define SPI_PUSHR_CMD_PCS(x) (BIT(x) & GENMASK(5, 0))
|
2019-08-19 02:01:02 +08:00
|
|
|
|
|
|
|
#define SPI_PUSHR_SLAVE 0x34
|
|
|
|
|
|
|
|
#define SPI_POPR 0x38
|
|
|
|
|
|
|
|
#define SPI_TXFR0 0x3c
|
|
|
|
#define SPI_TXFR1 0x40
|
|
|
|
#define SPI_TXFR2 0x44
|
|
|
|
#define SPI_TXFR3 0x48
|
|
|
|
#define SPI_RXFR0 0x7c
|
|
|
|
#define SPI_RXFR1 0x80
|
|
|
|
#define SPI_RXFR2 0x84
|
|
|
|
#define SPI_RXFR3 0x88
|
|
|
|
|
2019-08-19 02:01:04 +08:00
|
|
|
#define SPI_CTARE(x) (0x11c + (((x) & GENMASK(1, 0)) * 4))
|
2019-08-19 02:01:02 +08:00
|
|
|
#define SPI_CTARE_FMSZE(x) (((x) & 0x1) << 16)
|
|
|
|
#define SPI_CTARE_DTCP(x) ((x) & 0x7ff)
|
|
|
|
|
|
|
|
#define SPI_SREX 0x13c
|
|
|
|
|
|
|
|
#define SPI_FRAME_BITS(bits) SPI_CTAR_FMSZ((bits) - 1)
|
|
|
|
#define SPI_FRAME_EBITS(bits) SPI_CTARE_FMSZE(((bits) - 1) >> 4)
|
2018-06-20 15:34:39 +08:00
|
|
|
|
2019-08-19 02:01:02 +08:00
|
|
|
#define DMA_COMPLETION_TIMEOUT msecs_to_jiffies(3000)
|
2016-11-10 20:19:15 +08:00
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
struct chip_data {
|
2019-08-19 02:01:02 +08:00
|
|
|
u32 ctar_val;
|
2013-08-16 11:08:55 +08:00
|
|
|
};
|
|
|
|
|
2015-06-09 19:45:27 +08:00
|
|
|
enum dspi_trans_mode {
|
|
|
|
DSPI_EOQ_MODE = 0,
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
DSPI_XSPI_MODE,
|
2016-11-10 20:19:15 +08:00
|
|
|
DSPI_DMA_MODE,
|
2015-06-09 19:45:27 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct fsl_dspi_devtype_data {
|
2019-08-19 02:01:02 +08:00
|
|
|
enum dspi_trans_mode trans_mode;
|
|
|
|
u8 max_clock_factor;
|
2020-03-02 08:19:55 +08:00
|
|
|
int fifo_size;
|
2015-06-09 19:45:27 +08:00
|
|
|
};
|
|
|
|
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
enum {
|
|
|
|
LS1021A,
|
|
|
|
LS1012A,
|
2020-03-18 08:16:01 +08:00
|
|
|
LS1028A,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
LS1043A,
|
|
|
|
LS1046A,
|
|
|
|
LS2080A,
|
|
|
|
LS2085A,
|
|
|
|
LX2160A,
|
|
|
|
MCF5441X,
|
|
|
|
VF610,
|
2015-06-09 19:45:27 +08:00
|
|
|
};
|
|
|
|
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
static const struct fsl_dspi_devtype_data devtype_data[] = {
|
|
|
|
[VF610] = {
|
|
|
|
.trans_mode = DSPI_DMA_MODE,
|
|
|
|
.max_clock_factor = 2,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 4,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[LS1021A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
/* Has A-011218 DMA erratum */
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
.trans_mode = DSPI_XSPI_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 4,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[LS1012A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
/* Has A-011218 DMA erratum */
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
.trans_mode = DSPI_XSPI_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 16,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
2020-03-18 08:16:01 +08:00
|
|
|
[LS1028A] = {
|
|
|
|
.trans_mode = DSPI_XSPI_MODE,
|
|
|
|
.max_clock_factor = 8,
|
|
|
|
.fifo_size = 4,
|
|
|
|
},
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
[LS1043A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
/* Has A-011218 DMA erratum */
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
.trans_mode = DSPI_XSPI_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 16,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[LS1046A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
/* Has A-011218 DMA erratum */
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
.trans_mode = DSPI_XSPI_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 16,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[LS2080A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
.trans_mode = DSPI_DMA_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 4,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[LS2085A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
.trans_mode = DSPI_DMA_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 4,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[LX2160A] = {
|
2020-03-02 08:19:58 +08:00
|
|
|
.trans_mode = DSPI_DMA_MODE,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 4,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
|
|
|
[MCF5441X] = {
|
|
|
|
.trans_mode = DSPI_EOQ_MODE,
|
|
|
|
.max_clock_factor = 8,
|
2020-03-02 08:19:55 +08:00
|
|
|
.fifo_size = 16,
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
},
|
2017-10-28 06:23:01 +08:00
|
|
|
};
|
|
|
|
|
2016-11-10 20:19:15 +08:00
|
|
|
struct fsl_dspi_dma {
|
2019-08-19 02:01:02 +08:00
|
|
|
u32 *tx_dma_buf;
|
|
|
|
struct dma_chan *chan_tx;
|
|
|
|
dma_addr_t tx_dma_phys;
|
|
|
|
struct completion cmd_tx_complete;
|
|
|
|
struct dma_async_tx_descriptor *tx_desc;
|
|
|
|
|
|
|
|
u32 *rx_dma_buf;
|
|
|
|
struct dma_chan *chan_rx;
|
|
|
|
dma_addr_t rx_dma_phys;
|
|
|
|
struct completion cmd_rx_complete;
|
|
|
|
struct dma_async_tx_descriptor *rx_desc;
|
2016-11-10 20:19:15 +08:00
|
|
|
};
|
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
struct fsl_dspi {
|
2019-08-19 02:01:10 +08:00
|
|
|
struct spi_controller *ctlr;
|
2019-08-19 02:01:02 +08:00
|
|
|
struct platform_device *pdev;
|
|
|
|
|
|
|
|
struct regmap *regmap;
|
|
|
|
struct regmap *regmap_pushr;
|
|
|
|
int irq;
|
|
|
|
struct clk *clk;
|
|
|
|
|
|
|
|
struct spi_transfer *cur_transfer;
|
|
|
|
struct spi_message *cur_msg;
|
|
|
|
struct chip_data *cur_chip;
|
2019-12-27 09:24:17 +08:00
|
|
|
size_t progress;
|
2019-08-19 02:01:02 +08:00
|
|
|
size_t len;
|
|
|
|
const void *tx;
|
|
|
|
void *rx;
|
|
|
|
u16 tx_cmd;
|
|
|
|
const struct fsl_dspi_devtype_data *devtype_data;
|
|
|
|
|
spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion
Currently the driver puts the process in interruptible sleep waiting for
the interrupt train to finish transfer to/from the tx_buf and rx_buf.
But exiting the process with ctrl-c may make the kernel panic: the
wait_event_interruptible call will return -ERESTARTSYS, which a proper
driver implementation is perhaps supposed to handle, but nonetheless
this one doesn't, and aborts the transfer altogether.
Actually when the task is interrupted, there is still a high chance that
the dspi_interrupt is still triggering. And if dspi_transfer_one_message
returns execution all the way to the spi_device driver, that can free
the spi_message and spi_transfer structures, leaving the interrupts to
access a freed tx_buf and rx_buf.
hexdump -C /dev/mtd0
00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff
|.uhu............|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
*
^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed!
[ 38.503097] spi_master spi2: failed to transfer one message from queue
[ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377
[ 38.517676] Mem abort info:
[ 38.520474] ESR = 0x96000045
[ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits
[ 38.528861] SET = 0, FnV = 0
[ 38.531921] EA = 0, S1PTW = 0
[ 38.535067] Data abort info:
[ 38.537952] ISV = 0, ISS = 0x00000045
[ 38.541797] CM = 0, WnR = 1
[ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000
[ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000
[ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[ 38.565819] Modules linked in:
[ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
[ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
[ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
[ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110
[ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90
[ 38.601203] sp : ffff800010003d90
[ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000
[ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400
[ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
[ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
[ 38.625841] x21: 000000000000146e x20: ffff8000120c3000
[ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
[ 38.636498] x17: 0000000000000000 x16: 0000000000000000
[ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720
[ 38.647155] x13: 0720072007200765 x12: 0775076507750771
[ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040
[ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
[ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
[ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
[ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
[ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
[ 38.684454] Call trace:
[ 38.686905] ktime_get_real_ts64+0x3c/0x110
[ 38.691100] spi_take_timestamp_pre+0x40/0x90
[ 38.695470] dspi_fifo_write+0x58/0x2c0
[ 38.699315] dspi_interrupt+0xbc/0xd0
[ 38.702987] __handle_irq_event_percpu+0x78/0x2c0
[ 38.707706] handle_irq_event_percpu+0x3c/0x90
[ 38.712161] handle_irq_event+0x4c/0xd0
[ 38.716008] handle_fasteoi_irq+0xbc/0x170
[ 38.720115] generic_handle_irq+0x2c/0x40
[ 38.724135] __handle_domain_irq+0x68/0xc0
[ 38.728243] gic_handle_irq+0xc8/0x160
[ 38.732000] el1_irq+0xb8/0x180
[ 38.735149] spi_nor_spimem_read_data+0xe0/0x140
[ 38.739779] spi_nor_read+0xc4/0x120
[ 38.743364] mtd_read_oob+0xa8/0xc0
[ 38.746860] mtd_read+0x4c/0x80
[ 38.750007] mtdchar_read+0x108/0x2a0
[ 38.753679] __vfs_read+0x20/0x50
[ 38.757002] vfs_read+0xa4/0x190
[ 38.760237] ksys_read+0x6c/0xf0
[ 38.763471] __arm64_sys_read+0x20/0x30
[ 38.767319] el0_svc_common.constprop.3+0x90/0x160
[ 38.772125] do_el0_svc+0x28/0x90
[ 38.775449] el0_sync_handler+0x118/0x190
[ 38.779468] el0_sync+0x140/0x180
[ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
[ 38.788910] ---[ end trace 55da560db4d6bef7 ]---
[ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt
[ 38.799914] SMP: stopping secondary CPUs
[ 38.803849] Kernel Offset: disabled
[ 38.807344] CPU features: 0x10002,20006008
[ 38.811451] Memory Limit: none
[ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
So it is clear that the "interruptible" part isn't handled correctly.
When the process receives a signal, one could either attempt a clean
abort (which appears to be difficult with this hardware) or just keep
restarting the sleep until the wait queue really completes. But checking
in a loop for -ERESTARTSYS is a bit too complicated for this driver, so
just make the sleep uninterruptible, to avoid all that nonsense.
The wait queue was actually restructured as a completion, after polling
other drivers for the most "popular" approach.
Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:57 +08:00
|
|
|
struct completion xfer_done;
|
2019-08-19 02:01:02 +08:00
|
|
|
|
|
|
|
struct fsl_dspi_dma *dma;
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
int oper_word_size;
|
|
|
|
int oper_bits_per_word;
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
int words_in_flight;
|
2020-03-05 06:00:41 +08:00
|
|
|
|
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:53 +08:00
|
|
|
/*
|
|
|
|
* Offsets for CMD and TXDATA within SPI_PUSHR when accessed
|
|
|
|
* individually (in XSPI mode)
|
|
|
|
*/
|
|
|
|
int pushr_cmd;
|
|
|
|
int pushr_tx;
|
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
void (*host_to_dev)(struct fsl_dspi *dspi, u32 *txdata);
|
|
|
|
void (*dev_to_host)(struct fsl_dspi *dspi, u32 rxdata);
|
2013-08-16 11:08:55 +08:00
|
|
|
};
|
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
static void dspi_native_host_to_dev(struct fsl_dspi *dspi, u32 *txdata)
|
|
|
|
{
|
2020-05-30 03:57:56 +08:00
|
|
|
switch (dspi->oper_word_size) {
|
|
|
|
case 1:
|
|
|
|
*txdata = *(u8 *)dspi->tx;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
*txdata = *(u16 *)dspi->tx;
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
*txdata = *(u32 *)dspi->tx;
|
|
|
|
break;
|
|
|
|
}
|
2020-03-05 06:00:41 +08:00
|
|
|
dspi->tx += dspi->oper_word_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_native_dev_to_host(struct fsl_dspi *dspi, u32 rxdata)
|
|
|
|
{
|
2020-05-30 03:57:56 +08:00
|
|
|
switch (dspi->oper_word_size) {
|
|
|
|
case 1:
|
|
|
|
*(u8 *)dspi->rx = rxdata;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
*(u16 *)dspi->rx = rxdata;
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
*(u32 *)dspi->rx = rxdata;
|
|
|
|
break;
|
|
|
|
}
|
2020-03-05 06:00:41 +08:00
|
|
|
dspi->rx += dspi->oper_word_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_8on32_host_to_dev(struct fsl_dspi *dspi, u32 *txdata)
|
|
|
|
{
|
|
|
|
*txdata = cpu_to_be32(*(u32 *)dspi->tx);
|
|
|
|
dspi->tx += sizeof(u32);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_8on32_dev_to_host(struct fsl_dspi *dspi, u32 rxdata)
|
|
|
|
{
|
|
|
|
*(u32 *)dspi->rx = be32_to_cpu(rxdata);
|
|
|
|
dspi->rx += sizeof(u32);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_8on16_host_to_dev(struct fsl_dspi *dspi, u32 *txdata)
|
|
|
|
{
|
|
|
|
*txdata = cpu_to_be16(*(u16 *)dspi->tx);
|
|
|
|
dspi->tx += sizeof(u16);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_8on16_dev_to_host(struct fsl_dspi *dspi, u32 rxdata)
|
|
|
|
{
|
|
|
|
*(u16 *)dspi->rx = be16_to_cpu(rxdata);
|
|
|
|
dspi->rx += sizeof(u16);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_16on32_host_to_dev(struct fsl_dspi *dspi, u32 *txdata)
|
|
|
|
{
|
|
|
|
u16 hi = *(u16 *)dspi->tx;
|
|
|
|
u16 lo = *(u16 *)(dspi->tx + 2);
|
|
|
|
|
|
|
|
*txdata = (u32)hi << 16 | lo;
|
|
|
|
dspi->tx += sizeof(u32);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_16on32_dev_to_host(struct fsl_dspi *dspi, u32 rxdata)
|
|
|
|
{
|
|
|
|
u16 hi = rxdata & 0xffff;
|
|
|
|
u16 lo = rxdata >> 16;
|
|
|
|
|
|
|
|
*(u16 *)dspi->rx = lo;
|
|
|
|
*(u16 *)(dspi->rx + 2) = hi;
|
|
|
|
dspi->rx += sizeof(u32);
|
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:36 +08:00
|
|
|
/*
|
|
|
|
* Pop one word from the TX buffer for pushing into the
|
|
|
|
* PUSHR register (TX FIFO)
|
|
|
|
*/
|
2018-06-20 15:34:40 +08:00
|
|
|
static u32 dspi_pop_tx(struct fsl_dspi *dspi)
|
2018-06-20 15:34:35 +08:00
|
|
|
{
|
2018-06-20 15:34:40 +08:00
|
|
|
u32 txdata = 0;
|
2018-06-20 15:34:35 +08:00
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
if (dspi->tx)
|
|
|
|
dspi->host_to_dev(dspi, &txdata);
|
|
|
|
dspi->len -= dspi->oper_word_size;
|
2018-06-20 15:34:35 +08:00
|
|
|
return txdata;
|
|
|
|
}
|
2016-11-22 15:01:31 +08:00
|
|
|
|
2020-03-05 06:00:36 +08:00
|
|
|
/* Prepare one TX FIFO entry (txdata plus cmd) */
|
2018-06-20 15:34:35 +08:00
|
|
|
static u32 dspi_pop_tx_pushr(struct fsl_dspi *dspi)
|
2013-08-16 11:08:55 +08:00
|
|
|
{
|
2018-06-20 15:34:35 +08:00
|
|
|
u16 cmd = dspi->tx_cmd, data = dspi_pop_tx(dspi);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
if (spi_controller_is_slave(dspi->ctlr))
|
2019-02-06 06:13:49 +08:00
|
|
|
return data;
|
|
|
|
|
2018-06-20 15:34:35 +08:00
|
|
|
if (dspi->len > 0)
|
|
|
|
cmd |= SPI_PUSHR_CMD_CONT;
|
|
|
|
return cmd << 16 | data;
|
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:36 +08:00
|
|
|
/* Push one word to the RX buffer from the POPR register (RX FIFO) */
|
2018-06-20 15:34:35 +08:00
|
|
|
static void dspi_push_rx(struct fsl_dspi *dspi, u32 rxdata)
|
|
|
|
{
|
|
|
|
if (!dspi->rx)
|
|
|
|
return;
|
2020-03-05 06:00:41 +08:00
|
|
|
dspi->dev_to_host(dspi, rxdata);
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2016-11-10 20:19:15 +08:00
|
|
|
static void dspi_tx_dma_callback(void *arg)
|
|
|
|
{
|
|
|
|
struct fsl_dspi *dspi = arg;
|
|
|
|
struct fsl_dspi_dma *dma = dspi->dma;
|
|
|
|
|
|
|
|
complete(&dma->cmd_tx_complete);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_rx_dma_callback(void *arg)
|
|
|
|
{
|
|
|
|
struct fsl_dspi *dspi = arg;
|
|
|
|
struct fsl_dspi_dma *dma = dspi->dma;
|
2016-11-22 15:01:30 +08:00
|
|
|
int i;
|
2016-11-10 20:19:15 +08:00
|
|
|
|
2018-06-20 15:34:32 +08:00
|
|
|
if (dspi->rx) {
|
2020-03-18 08:15:54 +08:00
|
|
|
for (i = 0; i < dspi->words_in_flight; i++)
|
2018-06-20 15:34:35 +08:00
|
|
|
dspi_push_rx(dspi, dspi->dma->rx_dma_buf[i]);
|
2016-11-10 20:19:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
complete(&dma->cmd_rx_complete);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
|
|
|
|
{
|
|
|
|
struct device *dev = &dspi->pdev->dev;
|
2019-08-19 02:01:11 +08:00
|
|
|
struct fsl_dspi_dma *dma = dspi->dma;
|
2016-11-10 20:19:15 +08:00
|
|
|
int time_left;
|
2016-11-22 15:01:30 +08:00
|
|
|
int i;
|
2016-11-10 20:19:15 +08:00
|
|
|
|
2020-03-18 08:15:54 +08:00
|
|
|
for (i = 0; i < dspi->words_in_flight; i++)
|
2018-06-20 15:34:35 +08:00
|
|
|
dspi->dma->tx_dma_buf[i] = dspi_pop_tx_pushr(dspi);
|
2016-11-10 20:19:15 +08:00
|
|
|
|
|
|
|
dma->tx_desc = dmaengine_prep_slave_single(dma->chan_tx,
|
|
|
|
dma->tx_dma_phys,
|
2020-03-18 08:15:54 +08:00
|
|
|
dspi->words_in_flight *
|
2016-11-22 15:01:30 +08:00
|
|
|
DMA_SLAVE_BUSWIDTH_4_BYTES,
|
|
|
|
DMA_MEM_TO_DEV,
|
2016-11-10 20:19:15 +08:00
|
|
|
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
|
|
|
|
if (!dma->tx_desc) {
|
|
|
|
dev_err(dev, "Not able to get desc for DMA xfer\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
dma->tx_desc->callback = dspi_tx_dma_callback;
|
|
|
|
dma->tx_desc->callback_param = dspi;
|
|
|
|
if (dma_submit_error(dmaengine_submit(dma->tx_desc))) {
|
|
|
|
dev_err(dev, "DMA submit failed\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
dma->rx_desc = dmaengine_prep_slave_single(dma->chan_rx,
|
|
|
|
dma->rx_dma_phys,
|
2020-03-18 08:15:54 +08:00
|
|
|
dspi->words_in_flight *
|
2016-11-22 15:01:30 +08:00
|
|
|
DMA_SLAVE_BUSWIDTH_4_BYTES,
|
|
|
|
DMA_DEV_TO_MEM,
|
2016-11-10 20:19:15 +08:00
|
|
|
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
|
|
|
|
if (!dma->rx_desc) {
|
|
|
|
dev_err(dev, "Not able to get desc for DMA xfer\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
dma->rx_desc->callback = dspi_rx_dma_callback;
|
|
|
|
dma->rx_desc->callback_param = dspi;
|
|
|
|
if (dma_submit_error(dmaengine_submit(dma->rx_desc))) {
|
|
|
|
dev_err(dev, "DMA submit failed\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
reinit_completion(&dspi->dma->cmd_rx_complete);
|
|
|
|
reinit_completion(&dspi->dma->cmd_tx_complete);
|
|
|
|
|
|
|
|
dma_async_issue_pending(dma->chan_rx);
|
|
|
|
dma_async_issue_pending(dma->chan_tx);
|
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
if (spi_controller_is_slave(dspi->ctlr)) {
|
2019-02-06 06:13:49 +08:00
|
|
|
wait_for_completion_interruptible(&dspi->dma->cmd_rx_complete);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-11-10 20:19:15 +08:00
|
|
|
time_left = wait_for_completion_timeout(&dspi->dma->cmd_tx_complete,
|
2019-08-19 02:01:02 +08:00
|
|
|
DMA_COMPLETION_TIMEOUT);
|
2016-11-10 20:19:15 +08:00
|
|
|
if (time_left == 0) {
|
|
|
|
dev_err(dev, "DMA tx timeout\n");
|
|
|
|
dmaengine_terminate_all(dma->chan_tx);
|
|
|
|
dmaengine_terminate_all(dma->chan_rx);
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
time_left = wait_for_completion_timeout(&dspi->dma->cmd_rx_complete,
|
2019-08-19 02:01:02 +08:00
|
|
|
DMA_COMPLETION_TIMEOUT);
|
2016-11-10 20:19:15 +08:00
|
|
|
if (time_left == 0) {
|
|
|
|
dev_err(dev, "DMA rx timeout\n");
|
|
|
|
dmaengine_terminate_all(dma->chan_tx);
|
|
|
|
dmaengine_terminate_all(dma->chan_rx);
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-18 08:15:54 +08:00
|
|
|
static void dspi_setup_accel(struct fsl_dspi *dspi);
|
|
|
|
|
2016-11-10 20:19:15 +08:00
|
|
|
static int dspi_dma_xfer(struct fsl_dspi *dspi)
|
|
|
|
{
|
2018-07-17 12:33:29 +08:00
|
|
|
struct spi_message *message = dspi->cur_msg;
|
2019-08-19 02:01:11 +08:00
|
|
|
struct device *dev = &dspi->pdev->dev;
|
2016-11-10 20:19:15 +08:00
|
|
|
int ret = 0;
|
|
|
|
|
2020-03-18 08:15:54 +08:00
|
|
|
/*
|
|
|
|
* dspi->len gets decremented by dspi_pop_tx_pushr in
|
|
|
|
* dspi_next_xfer_dma_submit
|
|
|
|
*/
|
|
|
|
while (dspi->len) {
|
|
|
|
/* Figure out operational bits-per-word for this chunk */
|
|
|
|
dspi_setup_accel(dspi);
|
|
|
|
|
|
|
|
dspi->words_in_flight = dspi->len / dspi->oper_word_size;
|
|
|
|
if (dspi->words_in_flight > dspi->devtype_data->fifo_size)
|
|
|
|
dspi->words_in_flight = dspi->devtype_data->fifo_size;
|
|
|
|
|
|
|
|
message->actual_length += dspi->words_in_flight *
|
|
|
|
dspi->oper_word_size;
|
2016-11-10 20:19:15 +08:00
|
|
|
|
|
|
|
ret = dspi_next_xfer_dma_submit(dspi);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "DMA transfer failed\n");
|
2020-03-18 08:15:54 +08:00
|
|
|
break;
|
2016-11-10 20:19:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dspi_request_dma(struct fsl_dspi *dspi, phys_addr_t phy_addr)
|
|
|
|
{
|
2020-03-18 08:15:54 +08:00
|
|
|
int dma_bufsize = dspi->devtype_data->fifo_size * 2;
|
2016-11-10 20:19:15 +08:00
|
|
|
struct device *dev = &dspi->pdev->dev;
|
2019-08-19 02:01:11 +08:00
|
|
|
struct dma_slave_config cfg;
|
|
|
|
struct fsl_dspi_dma *dma;
|
2016-11-10 20:19:15 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
dma = devm_kzalloc(dev, sizeof(*dma), GFP_KERNEL);
|
|
|
|
if (!dma)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-12-12 21:55:48 +08:00
|
|
|
dma->chan_rx = dma_request_chan(dev, "rx");
|
|
|
|
if (IS_ERR(dma->chan_rx)) {
|
2016-11-10 20:19:15 +08:00
|
|
|
dev_err(dev, "rx dma channel not available\n");
|
2019-12-12 21:55:48 +08:00
|
|
|
ret = PTR_ERR(dma->chan_rx);
|
2016-11-10 20:19:15 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2019-12-12 21:55:48 +08:00
|
|
|
dma->chan_tx = dma_request_chan(dev, "tx");
|
|
|
|
if (IS_ERR(dma->chan_tx)) {
|
2016-11-10 20:19:15 +08:00
|
|
|
dev_err(dev, "tx dma channel not available\n");
|
2019-12-12 21:55:48 +08:00
|
|
|
ret = PTR_ERR(dma->chan_tx);
|
2016-11-10 20:19:15 +08:00
|
|
|
goto err_tx_channel;
|
|
|
|
}
|
|
|
|
|
2020-03-10 15:33:13 +08:00
|
|
|
dma->tx_dma_buf = dma_alloc_coherent(dma->chan_tx->device->dev,
|
2020-03-18 08:15:54 +08:00
|
|
|
dma_bufsize, &dma->tx_dma_phys,
|
|
|
|
GFP_KERNEL);
|
2016-11-10 20:19:15 +08:00
|
|
|
if (!dma->tx_dma_buf) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_tx_dma_buf;
|
|
|
|
}
|
|
|
|
|
2020-03-10 15:33:13 +08:00
|
|
|
dma->rx_dma_buf = dma_alloc_coherent(dma->chan_rx->device->dev,
|
2020-03-18 08:15:54 +08:00
|
|
|
dma_bufsize, &dma->rx_dma_phys,
|
|
|
|
GFP_KERNEL);
|
2016-11-10 20:19:15 +08:00
|
|
|
if (!dma->rx_dma_buf) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_rx_dma_buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
cfg.src_addr = phy_addr + SPI_POPR;
|
|
|
|
cfg.dst_addr = phy_addr + SPI_PUSHR;
|
|
|
|
cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
|
|
|
|
cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
|
|
|
|
cfg.src_maxburst = 1;
|
|
|
|
cfg.dst_maxburst = 1;
|
|
|
|
|
|
|
|
cfg.direction = DMA_DEV_TO_MEM;
|
|
|
|
ret = dmaengine_slave_config(dma->chan_rx, &cfg);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "can't configure rx dma channel\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_slave_config;
|
|
|
|
}
|
|
|
|
|
|
|
|
cfg.direction = DMA_MEM_TO_DEV;
|
|
|
|
ret = dmaengine_slave_config(dma->chan_tx, &cfg);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "can't configure tx dma channel\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_slave_config;
|
|
|
|
}
|
|
|
|
|
|
|
|
dspi->dma = dma;
|
|
|
|
init_completion(&dma->cmd_tx_complete);
|
|
|
|
init_completion(&dma->cmd_rx_complete);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_slave_config:
|
2020-03-10 15:33:13 +08:00
|
|
|
dma_free_coherent(dma->chan_rx->device->dev,
|
2020-03-18 08:15:54 +08:00
|
|
|
dma_bufsize, dma->rx_dma_buf, dma->rx_dma_phys);
|
2016-11-10 20:19:15 +08:00
|
|
|
err_rx_dma_buf:
|
2020-03-10 15:33:13 +08:00
|
|
|
dma_free_coherent(dma->chan_tx->device->dev,
|
2020-03-18 08:15:54 +08:00
|
|
|
dma_bufsize, dma->tx_dma_buf, dma->tx_dma_phys);
|
2016-11-10 20:19:15 +08:00
|
|
|
err_tx_dma_buf:
|
|
|
|
dma_release_channel(dma->chan_tx);
|
|
|
|
err_tx_channel:
|
|
|
|
dma_release_channel(dma->chan_rx);
|
|
|
|
|
|
|
|
devm_kfree(dev, dma);
|
|
|
|
dspi->dma = NULL;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void dspi_release_dma(struct fsl_dspi *dspi)
|
|
|
|
{
|
2020-03-18 08:15:54 +08:00
|
|
|
int dma_bufsize = dspi->devtype_data->fifo_size * 2;
|
2016-11-10 20:19:15 +08:00
|
|
|
struct fsl_dspi_dma *dma = dspi->dma;
|
|
|
|
|
2019-08-19 02:01:07 +08:00
|
|
|
if (!dma)
|
|
|
|
return;
|
2016-11-10 20:19:15 +08:00
|
|
|
|
2019-08-19 02:01:07 +08:00
|
|
|
if (dma->chan_tx) {
|
2020-06-10 23:41:57 +08:00
|
|
|
dma_free_coherent(dma->chan_tx->device->dev, dma_bufsize,
|
|
|
|
dma->tx_dma_buf, dma->tx_dma_phys);
|
2019-08-19 02:01:07 +08:00
|
|
|
dma_release_channel(dma->chan_tx);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dma->chan_rx) {
|
2020-06-10 23:41:57 +08:00
|
|
|
dma_free_coherent(dma->chan_rx->device->dev, dma_bufsize,
|
|
|
|
dma->rx_dma_buf, dma->rx_dma_phys);
|
2019-08-19 02:01:07 +08:00
|
|
|
dma_release_channel(dma->chan_rx);
|
2016-11-10 20:19:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
static void hz_to_spi_baud(char *pbr, char *br, int speed_hz,
|
2019-08-19 02:01:02 +08:00
|
|
|
unsigned long clkrate)
|
2013-08-16 11:08:55 +08:00
|
|
|
{
|
|
|
|
/* Valid baud rate pre-scaler values */
|
|
|
|
int pbr_tbl[4] = {2, 3, 5, 7};
|
|
|
|
int brs[16] = { 2, 4, 6, 8,
|
2019-08-19 02:01:02 +08:00
|
|
|
16, 32, 64, 128,
|
|
|
|
256, 512, 1024, 2048,
|
|
|
|
4096, 8192, 16384, 32768 };
|
spi: fsl-dspi: Fix clock rate scale values
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-31 01:49:15 +08:00
|
|
|
int scale_needed, scale, minscale = INT_MAX;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
scale_needed = clkrate / speed_hz;
|
spi: fsl-dspi: Fix clock rate scale values
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-04 04:39:29 +08:00
|
|
|
if (clkrate % speed_hz)
|
|
|
|
scale_needed++;
|
spi: fsl-dspi: Fix clock rate scale values
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-31 01:49:15 +08:00
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(brs); i++)
|
|
|
|
for (j = 0; j < ARRAY_SIZE(pbr_tbl); j++) {
|
|
|
|
scale = brs[i] * pbr_tbl[j];
|
|
|
|
if (scale >= scale_needed) {
|
|
|
|
if (scale < minscale) {
|
|
|
|
minscale = scale;
|
|
|
|
*br = i;
|
|
|
|
*pbr = j;
|
|
|
|
}
|
|
|
|
break;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
spi: fsl-dspi: Fix clock rate scale values
Previous algorithm had an outer loop with the values {2,3,5,7} and an
inner loop with {2,4,6,8,16,32,...,32768}, and would pick the first
value over the required scaling value (where the total scale was the two
numbers multiplied).
Since the inner loop went up to 32768 it would always pick a value of 2
for PBR and a much higher than necessary value for BR. The desired
scale factor was being divided by two I believe to compensate for the
much higher scale factors (the divide by two not specified in the
reference manual).
Updated to check all values and find the smallest scale factor possible
without going over the desired clock rate.
Signed-off-by: Aaron Brice <aaron.brice@datasoft.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-31 01:49:15 +08:00
|
|
|
if (minscale == INT_MAX) {
|
|
|
|
pr_warn("Can not find valid baud rate,speed_hz is %d,clkrate is %ld, we use the max prescaler value.\n",
|
|
|
|
speed_hz, clkrate);
|
|
|
|
*pbr = ARRAY_SIZE(pbr_tbl) - 1;
|
|
|
|
*br = ARRAY_SIZE(brs) - 1;
|
|
|
|
}
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2015-04-04 04:39:31 +08:00
|
|
|
static void ns_delay_scale(char *psc, char *sc, int delay_ns,
|
2019-08-19 02:01:02 +08:00
|
|
|
unsigned long clkrate)
|
2015-04-04 04:39:31 +08:00
|
|
|
{
|
|
|
|
int scale_needed, scale, minscale = INT_MAX;
|
2019-08-19 02:01:11 +08:00
|
|
|
int pscale_tbl[4] = {1, 3, 5, 7};
|
2015-04-04 04:39:31 +08:00
|
|
|
u32 remainder;
|
2019-08-19 02:01:11 +08:00
|
|
|
int i, j;
|
2015-04-04 04:39:31 +08:00
|
|
|
|
|
|
|
scale_needed = div_u64_rem((u64)delay_ns * clkrate, NSEC_PER_SEC,
|
2019-08-19 02:01:02 +08:00
|
|
|
&remainder);
|
2015-04-04 04:39:31 +08:00
|
|
|
if (remainder)
|
|
|
|
scale_needed++;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(pscale_tbl); i++)
|
|
|
|
for (j = 0; j <= SPI_CTAR_SCALE_BITS; j++) {
|
|
|
|
scale = pscale_tbl[i] * (2 << j);
|
|
|
|
if (scale >= scale_needed) {
|
|
|
|
if (scale < minscale) {
|
|
|
|
minscale = scale;
|
|
|
|
*psc = i;
|
|
|
|
*sc = j;
|
|
|
|
}
|
|
|
|
break;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-04 04:39:31 +08:00
|
|
|
if (minscale == INT_MAX) {
|
|
|
|
pr_warn("Cannot find correct scale values for %dns delay at clkrate %ld, using max prescaler value",
|
|
|
|
delay_ns, clkrate);
|
|
|
|
*psc = ARRAY_SIZE(pscale_tbl) - 1;
|
|
|
|
*sc = SPI_CTAR_SCALE_BITS;
|
|
|
|
}
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:37 +08:00
|
|
|
static void dspi_pushr_write(struct fsl_dspi *dspi)
|
2013-08-16 11:08:55 +08:00
|
|
|
{
|
2018-06-20 15:34:35 +08:00
|
|
|
regmap_write(dspi->regmap, SPI_PUSHR, dspi_pop_tx_pushr(dspi));
|
2015-06-09 19:45:27 +08:00
|
|
|
}
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2020-03-05 06:00:43 +08:00
|
|
|
static void dspi_pushr_cmd_write(struct fsl_dspi *dspi, u16 cmd)
|
2018-06-20 15:34:40 +08:00
|
|
|
{
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
/*
|
|
|
|
* The only time when the PCS doesn't need continuation after this word
|
|
|
|
* is when it's last. We need to look ahead, because we actually call
|
|
|
|
* dspi_pop_tx (the function that decrements dspi->len) _after_
|
|
|
|
* dspi_pushr_cmd_write with XSPI mode. As for how much in advance? One
|
|
|
|
* word is enough. If there's more to transmit than that,
|
|
|
|
* dspi_xspi_write will know to split the FIFO writes in 2, and
|
|
|
|
* generate a new PUSHR command with the final word that will have PCS
|
|
|
|
* deasserted (not continued) here.
|
|
|
|
*/
|
2020-03-05 06:00:41 +08:00
|
|
|
if (dspi->len > dspi->oper_word_size)
|
2018-06-20 15:34:40 +08:00
|
|
|
cmd |= SPI_PUSHR_CMD_CONT;
|
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:53 +08:00
|
|
|
regmap_write(dspi->regmap_pushr, dspi->pushr_cmd, cmd);
|
2018-06-20 15:34:40 +08:00
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:37 +08:00
|
|
|
static void dspi_pushr_txdata_write(struct fsl_dspi *dspi, u16 txdata)
|
2018-06-20 15:34:40 +08:00
|
|
|
{
|
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:53 +08:00
|
|
|
regmap_write(dspi->regmap_pushr, dspi->pushr_tx, txdata);
|
2018-06-20 15:34:40 +08:00
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
static void dspi_xspi_fifo_write(struct fsl_dspi *dspi, int num_words)
|
2015-06-09 19:45:27 +08:00
|
|
|
{
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
int num_bytes = num_words * dspi->oper_word_size;
|
2020-03-05 06:00:43 +08:00
|
|
|
u16 tx_cmd = dspi->tx_cmd;
|
2018-06-20 15:34:40 +08:00
|
|
|
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
/*
|
|
|
|
* If the PCS needs to de-assert (i.e. we're at the end of the buffer
|
|
|
|
* and cs_change does not want the PCS to stay on), then we need a new
|
|
|
|
* PUSHR command, since this one (for the body of the buffer)
|
|
|
|
* necessarily has the CONT bit set.
|
|
|
|
* So send one word less during this go, to force a split and a command
|
|
|
|
* with a single word next time, when CONT will be unset.
|
|
|
|
*/
|
|
|
|
if (!(dspi->tx_cmd & SPI_PUSHR_CMD_CONT) && num_bytes == dspi->len)
|
2020-03-05 06:00:43 +08:00
|
|
|
tx_cmd |= SPI_PUSHR_CMD_EOQ;
|
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
/* Update CTARE */
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
regmap_write(dspi->regmap, SPI_CTARE(0),
|
2020-03-05 06:00:41 +08:00
|
|
|
SPI_FRAME_EBITS(dspi->oper_bits_per_word) |
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
SPI_CTARE_DTCP(num_words));
|
2018-06-20 15:34:40 +08:00
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
/*
|
|
|
|
* Write the CMD FIFO entry first, and then the two
|
|
|
|
* corresponding TX FIFO entries (or one...).
|
|
|
|
*/
|
2020-03-05 06:00:43 +08:00
|
|
|
dspi_pushr_cmd_write(dspi, tx_cmd);
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
|
|
|
|
/* Fill TX FIFO with as many transfers as possible */
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
while (num_words--) {
|
2018-06-20 15:34:40 +08:00
|
|
|
u32 data = dspi_pop_tx(dspi);
|
|
|
|
|
2020-03-05 06:00:37 +08:00
|
|
|
dspi_pushr_txdata_write(dspi, data & 0xFFFF);
|
2020-03-05 06:00:41 +08:00
|
|
|
if (dspi->oper_bits_per_word > 16)
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
dspi_pushr_txdata_write(dspi, data >> 16);
|
2018-06-20 15:34:40 +08:00
|
|
|
}
|
2015-06-09 19:45:27 +08:00
|
|
|
}
|
2013-08-16 11:08:55 +08:00
|
|
|
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
static void dspi_eoq_fifo_write(struct fsl_dspi *dspi, int num_words)
|
2015-06-09 19:45:27 +08:00
|
|
|
{
|
2018-08-18 07:51:58 +08:00
|
|
|
u16 xfer_cmd = dspi->tx_cmd;
|
2018-06-20 15:34:35 +08:00
|
|
|
|
|
|
|
/* Fill TX FIFO with as many transfers as possible */
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
while (num_words--) {
|
2018-08-18 07:51:58 +08:00
|
|
|
dspi->tx_cmd = xfer_cmd;
|
2018-06-20 15:34:35 +08:00
|
|
|
/* Request EOQF for last transfer in FIFO */
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
if (num_words == 0)
|
2018-06-20 15:34:35 +08:00
|
|
|
dspi->tx_cmd |= SPI_PUSHR_CMD_EOQ;
|
|
|
|
/* Write combined TX FIFO and CMD FIFO entry */
|
2020-03-05 06:00:37 +08:00
|
|
|
dspi_pushr_write(dspi);
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
2015-06-09 19:45:27 +08:00
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
static u32 dspi_popr_read(struct fsl_dspi *dspi)
|
2015-06-09 19:45:27 +08:00
|
|
|
{
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
u32 rxdata = 0;
|
2015-06-09 19:45:27 +08:00
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
regmap_read(dspi->regmap, SPI_POPR, &rxdata);
|
|
|
|
return rxdata;
|
|
|
|
}
|
2015-06-09 19:45:27 +08:00
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
static void dspi_fifo_read(struct fsl_dspi *dspi)
|
|
|
|
{
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
int num_fifo_entries = dspi->words_in_flight;
|
|
|
|
|
2019-08-19 02:01:12 +08:00
|
|
|
/* Read one FIFO entry and push to rx buffer */
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
while (num_fifo_entries--)
|
2020-03-05 06:00:37 +08:00
|
|
|
dspi_push_rx(dspi, dspi_popr_read(dspi));
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
static void dspi_setup_accel(struct fsl_dspi *dspi)
|
2019-08-19 02:01:13 +08:00
|
|
|
{
|
2020-03-05 06:00:41 +08:00
|
|
|
struct spi_transfer *xfer = dspi->cur_transfer;
|
2020-03-05 06:00:42 +08:00
|
|
|
bool odd = !!(dspi->len & 1);
|
2019-08-23 05:15:10 +08:00
|
|
|
|
2020-03-05 06:00:42 +08:00
|
|
|
/* No accel for frames not multiple of 8 bits at the moment */
|
|
|
|
if (xfer->bits_per_word % 8)
|
|
|
|
goto no_accel;
|
2019-09-05 09:01:13 +08:00
|
|
|
|
2020-03-05 06:00:42 +08:00
|
|
|
if (!odd && dspi->len <= dspi->devtype_data->fifo_size * 2) {
|
|
|
|
dspi->oper_bits_per_word = 16;
|
|
|
|
} else if (odd && dspi->len <= dspi->devtype_data->fifo_size) {
|
|
|
|
dspi->oper_bits_per_word = 8;
|
|
|
|
} else {
|
|
|
|
/* Start off with maximum supported by hardware */
|
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE)
|
|
|
|
dspi->oper_bits_per_word = 32;
|
|
|
|
else
|
|
|
|
dspi->oper_bits_per_word = 16;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And go down only if the buffer can't be sent with
|
|
|
|
* words this big
|
|
|
|
*/
|
|
|
|
do {
|
|
|
|
if (dspi->len >= DIV_ROUND_UP(dspi->oper_bits_per_word, 8))
|
|
|
|
break;
|
2020-03-05 06:00:41 +08:00
|
|
|
|
2020-03-05 06:00:42 +08:00
|
|
|
dspi->oper_bits_per_word /= 2;
|
|
|
|
} while (dspi->oper_bits_per_word > 8);
|
|
|
|
}
|
2020-03-05 06:00:41 +08:00
|
|
|
|
|
|
|
if (xfer->bits_per_word == 8 && dspi->oper_bits_per_word == 32) {
|
|
|
|
dspi->dev_to_host = dspi_8on32_dev_to_host;
|
|
|
|
dspi->host_to_dev = dspi_8on32_host_to_dev;
|
|
|
|
} else if (xfer->bits_per_word == 8 && dspi->oper_bits_per_word == 16) {
|
|
|
|
dspi->dev_to_host = dspi_8on16_dev_to_host;
|
|
|
|
dspi->host_to_dev = dspi_8on16_host_to_dev;
|
|
|
|
} else if (xfer->bits_per_word == 16 && dspi->oper_bits_per_word == 32) {
|
|
|
|
dspi->dev_to_host = dspi_16on32_dev_to_host;
|
|
|
|
dspi->host_to_dev = dspi_16on32_host_to_dev;
|
|
|
|
} else {
|
2020-03-05 06:00:42 +08:00
|
|
|
no_accel:
|
2020-03-05 06:00:41 +08:00
|
|
|
dspi->dev_to_host = dspi_native_dev_to_host;
|
|
|
|
dspi->host_to_dev = dspi_native_host_to_dev;
|
|
|
|
dspi->oper_bits_per_word = xfer->bits_per_word;
|
|
|
|
}
|
|
|
|
|
|
|
|
dspi->oper_word_size = DIV_ROUND_UP(dspi->oper_bits_per_word, 8);
|
|
|
|
|
|
|
|
/*
|
2020-03-18 08:15:54 +08:00
|
|
|
* Update CTAR here (code is common for EOQ, XSPI and DMA modes).
|
2020-03-05 06:00:41 +08:00
|
|
|
* We will update CTARE in the portion specific to XSPI, when we
|
|
|
|
* also know the preload value (DTCP).
|
2019-08-23 05:15:10 +08:00
|
|
|
*/
|
2020-03-05 06:00:41 +08:00
|
|
|
regmap_write(dspi->regmap, SPI_CTAR(0),
|
|
|
|
dspi->cur_chip->ctar_val |
|
|
|
|
SPI_FRAME_BITS(dspi->oper_bits_per_word));
|
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
static void dspi_fifo_write(struct fsl_dspi *dspi)
|
|
|
|
{
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
int num_fifo_entries = dspi->devtype_data->fifo_size;
|
2020-03-05 06:00:44 +08:00
|
|
|
struct spi_transfer *xfer = dspi->cur_transfer;
|
|
|
|
struct spi_message *msg = dspi->cur_msg;
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
int num_words, num_bytes;
|
2020-03-05 06:00:44 +08:00
|
|
|
|
2020-03-05 06:00:41 +08:00
|
|
|
dspi_setup_accel(dspi);
|
|
|
|
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
/* In XSPI mode each 32-bit word occupies 2 TX FIFO entries */
|
|
|
|
if (dspi->oper_word_size == 4)
|
|
|
|
num_fifo_entries /= 2;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Integer division intentionally trims off odd (or non-multiple of 4)
|
|
|
|
* numbers of bytes at the end of the buffer, which will be sent next
|
|
|
|
* time using a smaller oper_word_size.
|
|
|
|
*/
|
|
|
|
num_words = dspi->len / dspi->oper_word_size;
|
|
|
|
if (num_words > num_fifo_entries)
|
|
|
|
num_words = num_fifo_entries;
|
|
|
|
|
|
|
|
/* Update total number of bytes that were transferred */
|
|
|
|
num_bytes = num_words * dspi->oper_word_size;
|
|
|
|
msg->actual_length += num_bytes;
|
|
|
|
dspi->progress += num_bytes / DIV_ROUND_UP(xfer->bits_per_word, 8);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update shared variable for use in the next interrupt (both in
|
|
|
|
* dspi_fifo_read and in dspi_fifo_write).
|
|
|
|
*/
|
|
|
|
dspi->words_in_flight = num_words;
|
|
|
|
|
2020-03-05 06:00:44 +08:00
|
|
|
spi_take_timestamp_pre(dspi->ctlr, xfer, dspi->progress, !dspi->irq);
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_EOQ_MODE)
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
dspi_eoq_fifo_write(dspi, num_words);
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
else
|
spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight
dspi->words_in_flight is a variable populated in the *_write functions
and used in the dspi_fifo_read function. It is also used in
dspi_fifo_write, immediately after transmission, to update the
message->actual_length variable used by higher layers such as spi-mem
for integrity checking.
But it may happen that the IRQ which calls dspi_fifo_read to be
triggered before the updating of message->actual_length takes place. In
that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
and that will cause an invalid modification of message->actual_length.
For that, we make the simplest fix possible: to not decrement the actual
shared variable in dspi->words_in_flight from dspi_fifo_read, but
actually a copy of it which is on stack.
But even if dspi_fifo_read from the next IRQ does not interfere with the
dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
can. So we must assume that everything after the last write to the TX
FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
function must be safe against that. This means refactoring the 2
flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
the number of words to be written is common and happens a priori. This
way, the code for updating the message->actual_length variable works
with a copy and not with the volatile dspi->words_in_flight.
After some interior debate, the dspi->progress variable used for
software timestamping was *not* backed up against preemption in a copy
on stack. Because if preemption does occur between
spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
point in trying to save anything. The first-in-time
spi_take_timestamp_post call with a dspi->progress higher than the
requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
anyway and will close the deal.
To understand the above a bit better, consider a transfer with
xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
controller timestamps in chunks of 4 bytes at a time, and preemption
occurs in the middle of timestamping the first chunk:
spi_take_timestamp_pre(0)
.
. (preemption)
.
. spi_take_timestamp_pre(4)
.
. spi_take_timestamp_post(7)
.
spi_take_timestamp_post(3)
So the reason I'm not bothering to back up dspi->progress for that
spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
to (a) be more honest, (b) provide better accuracy and (c) already
render the spi_take_timestamp_post(3) into a noop by setting
xfer->timestamped = true anyway.
Fixes: d59c90a2400f ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:56 +08:00
|
|
|
dspi_xspi_fifo_write(dspi, num_words);
|
|
|
|
/*
|
|
|
|
* Everything after this point is in a potential race with the next
|
|
|
|
* interrupt, so we must never use dspi->words_in_flight again since it
|
|
|
|
* might already be modified by the next dspi_fifo_write.
|
|
|
|
*/
|
2019-08-23 05:15:10 +08:00
|
|
|
|
2019-09-05 09:01:13 +08:00
|
|
|
spi_take_timestamp_post(dspi->ctlr, dspi->cur_transfer,
|
2019-12-27 09:24:17 +08:00
|
|
|
dspi->progress, !dspi->irq);
|
2020-03-05 06:00:44 +08:00
|
|
|
}
|
2019-09-05 09:01:13 +08:00
|
|
|
|
2020-03-05 06:00:44 +08:00
|
|
|
static int dspi_rxtx(struct fsl_dspi *dspi)
|
|
|
|
{
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
dspi_fifo_read(dspi);
|
2019-08-19 02:01:13 +08:00
|
|
|
|
2019-08-23 05:15:13 +08:00
|
|
|
if (!dspi->len)
|
|
|
|
/* Success! */
|
|
|
|
return 0;
|
2019-08-19 02:01:13 +08:00
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
dspi_fifo_write(dspi);
|
2019-08-19 02:01:13 +08:00
|
|
|
|
2019-08-23 05:15:13 +08:00
|
|
|
return -EINPROGRESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dspi_poll(struct fsl_dspi *dspi)
|
|
|
|
{
|
|
|
|
int tries = 1000;
|
|
|
|
u32 spi_sr;
|
|
|
|
|
|
|
|
do {
|
|
|
|
regmap_read(dspi->regmap, SPI_SR, &spi_sr);
|
|
|
|
regmap_write(dspi->regmap, SPI_SR, spi_sr);
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (spi_sr & (SPI_SR_EOQF | SPI_SR_CMDTCF))
|
2019-08-23 05:15:13 +08:00
|
|
|
break;
|
|
|
|
} while (--tries);
|
|
|
|
|
|
|
|
if (!tries)
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
|
|
|
return dspi_rxtx(dspi);
|
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t dspi_interrupt(int irq, void *dev_id)
|
|
|
|
{
|
|
|
|
struct fsl_dspi *dspi = (struct fsl_dspi *)dev_id;
|
|
|
|
u32 spi_sr;
|
|
|
|
|
|
|
|
regmap_read(dspi->regmap, SPI_SR, &spi_sr);
|
|
|
|
regmap_write(dspi->regmap, SPI_SR, spi_sr);
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (!(spi_sr & (SPI_SR_EOQF | SPI_SR_CMDTCF)))
|
2019-08-23 05:15:13 +08:00
|
|
|
return IRQ_NONE;
|
|
|
|
|
spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion
Currently the driver puts the process in interruptible sleep waiting for
the interrupt train to finish transfer to/from the tx_buf and rx_buf.
But exiting the process with ctrl-c may make the kernel panic: the
wait_event_interruptible call will return -ERESTARTSYS, which a proper
driver implementation is perhaps supposed to handle, but nonetheless
this one doesn't, and aborts the transfer altogether.
Actually when the task is interrupted, there is still a high chance that
the dspi_interrupt is still triggering. And if dspi_transfer_one_message
returns execution all the way to the spi_device driver, that can free
the spi_message and spi_transfer structures, leaving the interrupts to
access a freed tx_buf and rx_buf.
hexdump -C /dev/mtd0
00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff
|.uhu............|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
*
^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed!
[ 38.503097] spi_master spi2: failed to transfer one message from queue
[ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377
[ 38.517676] Mem abort info:
[ 38.520474] ESR = 0x96000045
[ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits
[ 38.528861] SET = 0, FnV = 0
[ 38.531921] EA = 0, S1PTW = 0
[ 38.535067] Data abort info:
[ 38.537952] ISV = 0, ISS = 0x00000045
[ 38.541797] CM = 0, WnR = 1
[ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000
[ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000
[ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[ 38.565819] Modules linked in:
[ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
[ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
[ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
[ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110
[ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90
[ 38.601203] sp : ffff800010003d90
[ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000
[ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400
[ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
[ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
[ 38.625841] x21: 000000000000146e x20: ffff8000120c3000
[ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
[ 38.636498] x17: 0000000000000000 x16: 0000000000000000
[ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720
[ 38.647155] x13: 0720072007200765 x12: 0775076507750771
[ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040
[ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
[ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
[ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
[ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
[ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
[ 38.684454] Call trace:
[ 38.686905] ktime_get_real_ts64+0x3c/0x110
[ 38.691100] spi_take_timestamp_pre+0x40/0x90
[ 38.695470] dspi_fifo_write+0x58/0x2c0
[ 38.699315] dspi_interrupt+0xbc/0xd0
[ 38.702987] __handle_irq_event_percpu+0x78/0x2c0
[ 38.707706] handle_irq_event_percpu+0x3c/0x90
[ 38.712161] handle_irq_event+0x4c/0xd0
[ 38.716008] handle_fasteoi_irq+0xbc/0x170
[ 38.720115] generic_handle_irq+0x2c/0x40
[ 38.724135] __handle_domain_irq+0x68/0xc0
[ 38.728243] gic_handle_irq+0xc8/0x160
[ 38.732000] el1_irq+0xb8/0x180
[ 38.735149] spi_nor_spimem_read_data+0xe0/0x140
[ 38.739779] spi_nor_read+0xc4/0x120
[ 38.743364] mtd_read_oob+0xa8/0xc0
[ 38.746860] mtd_read+0x4c/0x80
[ 38.750007] mtdchar_read+0x108/0x2a0
[ 38.753679] __vfs_read+0x20/0x50
[ 38.757002] vfs_read+0xa4/0x190
[ 38.760237] ksys_read+0x6c/0xf0
[ 38.763471] __arm64_sys_read+0x20/0x30
[ 38.767319] el0_svc_common.constprop.3+0x90/0x160
[ 38.772125] do_el0_svc+0x28/0x90
[ 38.775449] el0_sync_handler+0x118/0x190
[ 38.779468] el0_sync+0x140/0x180
[ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
[ 38.788910] ---[ end trace 55da560db4d6bef7 ]---
[ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt
[ 38.799914] SMP: stopping secondary CPUs
[ 38.803849] Kernel Offset: disabled
[ 38.807344] CPU features: 0x10002,20006008
[ 38.811451] Memory Limit: none
[ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
So it is clear that the "interruptible" part isn't handled correctly.
When the process receives a signal, one could either attempt a clean
abort (which appears to be difficult with this hardware) or just keep
restarting the sleep until the wait queue really completes. But checking
in a loop for -ERESTARTSYS is a bit too complicated for this driver, so
just make the sleep uninterruptible, to avoid all that nonsense.
The wait queue was actually restructured as a completion, after polling
other drivers for the most "popular" approach.
Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:57 +08:00
|
|
|
if (dspi_rxtx(dspi) == 0)
|
|
|
|
complete(&dspi->xfer_done);
|
2019-08-23 05:15:13 +08:00
|
|
|
|
2019-08-19 02:01:13 +08:00
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
static int dspi_transfer_one_message(struct spi_controller *ctlr,
|
2019-08-19 02:01:02 +08:00
|
|
|
struct spi_message *message)
|
2013-08-16 11:08:55 +08:00
|
|
|
{
|
2019-08-19 02:01:10 +08:00
|
|
|
struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
|
2015-01-27 18:57:22 +08:00
|
|
|
struct spi_device *spi = message->spi;
|
|
|
|
struct spi_transfer *transfer;
|
|
|
|
int status = 0;
|
2015-06-09 19:45:27 +08:00
|
|
|
|
2015-01-27 18:57:22 +08:00
|
|
|
message->actual_length = 0;
|
|
|
|
|
|
|
|
list_for_each_entry(transfer, &message->transfers, transfer_list) {
|
|
|
|
dspi->cur_transfer = transfer;
|
|
|
|
dspi->cur_msg = message;
|
|
|
|
dspi->cur_chip = spi_get_ctldata(spi);
|
2018-06-20 15:34:33 +08:00
|
|
|
/* Prepare command word for CMD FIFO */
|
|
|
|
dspi->tx_cmd = SPI_PUSHR_CMD_CTAS(0) |
|
2019-08-19 02:01:02 +08:00
|
|
|
SPI_PUSHR_CMD_PCS(spi->chip_select);
|
2016-04-05 20:33:14 +08:00
|
|
|
if (list_is_last(&dspi->cur_transfer->transfer_list,
|
2018-06-20 15:34:33 +08:00
|
|
|
&dspi->cur_msg->transfers)) {
|
|
|
|
/* Leave PCS activated after last transfer when
|
|
|
|
* cs_change is set.
|
|
|
|
*/
|
|
|
|
if (transfer->cs_change)
|
|
|
|
dspi->tx_cmd |= SPI_PUSHR_CMD_CONT;
|
|
|
|
} else {
|
|
|
|
/* Keep PCS active between transfers in same message
|
|
|
|
* when cs_change is not set, and de-activate PCS
|
|
|
|
* between transfers in the same message when
|
|
|
|
* cs_change is set.
|
|
|
|
*/
|
|
|
|
if (!transfer->cs_change)
|
|
|
|
dspi->tx_cmd |= SPI_PUSHR_CMD_CONT;
|
|
|
|
}
|
|
|
|
|
2018-06-20 15:34:35 +08:00
|
|
|
dspi->tx = transfer->tx_buf;
|
2015-01-27 18:57:22 +08:00
|
|
|
dspi->rx = transfer->rx_buf;
|
|
|
|
dspi->len = transfer->len;
|
2019-12-27 09:24:17 +08:00
|
|
|
dspi->progress = 0;
|
2015-01-27 18:57:22 +08:00
|
|
|
|
|
|
|
regmap_update_bits(dspi->regmap, SPI_MCR,
|
2018-06-20 15:34:37 +08:00
|
|
|
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF,
|
|
|
|
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-09-05 09:01:13 +08:00
|
|
|
spi_take_timestamp_pre(dspi->ctlr, dspi->cur_transfer,
|
2019-12-27 09:24:17 +08:00
|
|
|
dspi->progress, !dspi->irq);
|
2019-09-05 09:01:13 +08:00
|
|
|
|
2020-03-18 08:16:00 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
|
2016-11-10 20:19:15 +08:00
|
|
|
status = dspi_dma_xfer(dspi);
|
2020-03-18 08:16:00 +08:00
|
|
|
} else {
|
|
|
|
dspi_fifo_write(dspi);
|
2014-02-12 15:29:05 +08:00
|
|
|
|
2020-03-18 08:15:59 +08:00
|
|
|
if (dspi->irq) {
|
|
|
|
wait_for_completion(&dspi->xfer_done);
|
|
|
|
reinit_completion(&dspi->xfer_done);
|
|
|
|
} else {
|
|
|
|
do {
|
|
|
|
status = dspi_poll(dspi);
|
|
|
|
} while (status == -EINPROGRESS);
|
|
|
|
}
|
2016-11-17 20:16:48 +08:00
|
|
|
}
|
2020-03-18 08:16:00 +08:00
|
|
|
if (status)
|
|
|
|
break;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-09-26 18:51:37 +08:00
|
|
|
spi_transfer_delay_exec(transfer);
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2015-01-27 18:57:22 +08:00
|
|
|
message->status = status;
|
2019-08-19 02:01:10 +08:00
|
|
|
spi_finalize_current_message(ctlr);
|
2015-01-27 18:57:22 +08:00
|
|
|
|
|
|
|
return status;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2015-01-27 18:57:22 +08:00
|
|
|
static int dspi_setup(struct spi_device *spi)
|
2013-08-16 11:08:55 +08:00
|
|
|
{
|
2019-08-19 02:01:10 +08:00
|
|
|
struct fsl_dspi *dspi = spi_controller_get_devdata(spi->controller);
|
2015-04-04 04:39:31 +08:00
|
|
|
unsigned char br = 0, pbr = 0, pcssck = 0, cssck = 0;
|
2019-08-19 02:01:11 +08:00
|
|
|
u32 cs_sck_delay = 0, sck_cs_delay = 0;
|
|
|
|
struct fsl_dspi_platform_data *pdata;
|
2018-06-20 15:34:35 +08:00
|
|
|
unsigned char pasc = 0, asc = 0;
|
2019-08-19 02:01:11 +08:00
|
|
|
struct chip_data *chip;
|
2015-04-04 04:39:31 +08:00
|
|
|
unsigned long clkrate;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
|
|
|
/* Only alloc on first setup */
|
|
|
|
chip = spi_get_ctldata(spi);
|
|
|
|
if (chip == NULL) {
|
2015-01-27 18:57:20 +08:00
|
|
|
chip = kzalloc(sizeof(struct chip_data), GFP_KERNEL);
|
2013-08-16 11:08:55 +08:00
|
|
|
if (!chip)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2017-10-28 06:23:01 +08:00
|
|
|
pdata = dev_get_platdata(&dspi->pdev->dev);
|
2015-04-04 04:39:31 +08:00
|
|
|
|
2017-10-28 06:23:01 +08:00
|
|
|
if (!pdata) {
|
|
|
|
of_property_read_u32(spi->dev.of_node, "fsl,spi-cs-sck-delay",
|
2019-08-19 02:01:02 +08:00
|
|
|
&cs_sck_delay);
|
2017-10-28 06:23:01 +08:00
|
|
|
|
|
|
|
of_property_read_u32(spi->dev.of_node, "fsl,spi-sck-cs-delay",
|
2019-08-19 02:01:02 +08:00
|
|
|
&sck_cs_delay);
|
2017-10-28 06:23:01 +08:00
|
|
|
} else {
|
|
|
|
cs_sck_delay = pdata->cs_sck_delay;
|
|
|
|
sck_cs_delay = pdata->sck_cs_delay;
|
|
|
|
}
|
2015-04-04 04:39:31 +08:00
|
|
|
|
|
|
|
clkrate = clk_get_rate(dspi->clk);
|
|
|
|
hz_to_spi_baud(&pbr, &br, spi->max_speed_hz, clkrate);
|
|
|
|
|
|
|
|
/* Set PCS to SCK delay scale values */
|
|
|
|
ns_delay_scale(&pcssck, &cssck, cs_sck_delay, clkrate);
|
|
|
|
|
|
|
|
/* Set After SCK delay scale values */
|
|
|
|
ns_delay_scale(&pasc, &asc, sck_cs_delay, clkrate);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:06 +08:00
|
|
|
chip->ctar_val = 0;
|
|
|
|
if (spi->mode & SPI_CPOL)
|
|
|
|
chip->ctar_val |= SPI_CTAR_CPOL;
|
|
|
|
if (spi->mode & SPI_CPHA)
|
|
|
|
chip->ctar_val |= SPI_CTAR_CPHA;
|
2019-02-06 06:13:49 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
if (!spi_controller_is_slave(dspi->ctlr)) {
|
2019-08-19 02:01:06 +08:00
|
|
|
chip->ctar_val |= SPI_CTAR_PCSSCK(pcssck) |
|
|
|
|
SPI_CTAR_CSSCK(cssck) |
|
|
|
|
SPI_CTAR_PASC(pasc) |
|
|
|
|
SPI_CTAR_ASC(asc) |
|
|
|
|
SPI_CTAR_PBR(pbr) |
|
|
|
|
SPI_CTAR_BR(br);
|
|
|
|
|
|
|
|
if (spi->mode & SPI_LSB_FIRST)
|
|
|
|
chip->ctar_val |= SPI_CTAR_LSBFE;
|
2019-02-06 06:13:49 +08:00
|
|
|
}
|
2013-08-16 11:08:55 +08:00
|
|
|
|
|
|
|
spi_set_ctldata(spi, chip);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-01-27 18:57:20 +08:00
|
|
|
static void dspi_cleanup(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
struct chip_data *chip = spi_get_ctldata((struct spi_device *)spi);
|
|
|
|
|
|
|
|
dev_dbg(&spi->dev, "spi_device %u.%u cleanup\n",
|
2019-08-19 02:01:10 +08:00
|
|
|
spi->controller->bus_num, spi->chip_select);
|
2015-01-27 18:57:20 +08:00
|
|
|
|
|
|
|
kfree(chip);
|
|
|
|
}
|
|
|
|
|
2014-05-07 15:45:41 +08:00
|
|
|
static const struct of_device_id fsl_dspi_dt_ids[] = {
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
{
|
|
|
|
.compatible = "fsl,vf610-dspi",
|
|
|
|
.data = &devtype_data[VF610],
|
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls1021a-v1.0-dspi",
|
|
|
|
.data = &devtype_data[LS1021A],
|
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls1012a-dspi",
|
|
|
|
.data = &devtype_data[LS1012A],
|
2020-03-18 08:16:01 +08:00
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls1028a-dspi",
|
|
|
|
.data = &devtype_data[LS1028A],
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls1043a-dspi",
|
|
|
|
.data = &devtype_data[LS1043A],
|
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls1046a-dspi",
|
|
|
|
.data = &devtype_data[LS1046A],
|
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls2080a-dspi",
|
|
|
|
.data = &devtype_data[LS2080A],
|
|
|
|
}, {
|
|
|
|
.compatible = "fsl,ls2085a-dspi",
|
|
|
|
.data = &devtype_data[LS2085A],
|
|
|
|
}, {
|
|
|
|
.compatible = "fsl,lx2160a-dspi",
|
|
|
|
.data = &devtype_data[LX2160A],
|
|
|
|
},
|
2013-08-16 11:08:55 +08:00
|
|
|
{ /* sentinel */ }
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, fsl_dspi_dt_ids);
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
static int dspi_suspend(struct device *dev)
|
|
|
|
{
|
2019-08-19 02:01:10 +08:00
|
|
|
struct spi_controller *ctlr = dev_get_drvdata(dev);
|
|
|
|
struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2020-06-22 19:05:42 +08:00
|
|
|
if (dspi->irq)
|
|
|
|
disable_irq(dspi->irq);
|
2019-08-19 02:01:10 +08:00
|
|
|
spi_controller_suspend(ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
clk_disable_unprepare(dspi->clk);
|
|
|
|
|
2015-06-13 00:55:22 +08:00
|
|
|
pinctrl_pm_select_sleep_state(dev);
|
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dspi_resume(struct device *dev)
|
|
|
|
{
|
2019-08-19 02:01:10 +08:00
|
|
|
struct spi_controller *ctlr = dev_get_drvdata(dev);
|
|
|
|
struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
|
2016-08-22 10:05:30 +08:00
|
|
|
int ret;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2015-06-13 00:55:22 +08:00
|
|
|
pinctrl_pm_select_default_state(dev);
|
|
|
|
|
2016-08-22 10:05:30 +08:00
|
|
|
ret = clk_prepare_enable(dspi->clk);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-08-19 02:01:10 +08:00
|
|
|
spi_controller_resume(ctlr);
|
2020-06-22 19:05:42 +08:00
|
|
|
if (dspi->irq)
|
|
|
|
enable_irq(dspi->irq);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
|
|
|
|
2014-02-26 09:30:14 +08:00
|
|
|
static SIMPLE_DEV_PM_OPS(dspi_pm, dspi_suspend, dspi_resume);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2018-06-20 15:34:36 +08:00
|
|
|
static const struct regmap_range dspi_volatile_ranges[] = {
|
|
|
|
regmap_reg_range(SPI_MCR, SPI_TCR),
|
|
|
|
regmap_reg_range(SPI_SR, SPI_SR),
|
|
|
|
regmap_reg_range(SPI_PUSHR, SPI_RXFR3),
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct regmap_access_table dspi_volatile_table = {
|
2019-08-19 02:01:02 +08:00
|
|
|
.yes_ranges = dspi_volatile_ranges,
|
|
|
|
.n_yes_ranges = ARRAY_SIZE(dspi_volatile_ranges),
|
2018-06-20 15:34:36 +08:00
|
|
|
};
|
|
|
|
|
2014-10-09 11:27:45 +08:00
|
|
|
static const struct regmap_config dspi_regmap_config = {
|
2019-08-19 02:01:02 +08:00
|
|
|
.reg_bits = 32,
|
|
|
|
.val_bits = 32,
|
|
|
|
.reg_stride = 4,
|
|
|
|
.max_register = 0x88,
|
|
|
|
.volatile_table = &dspi_volatile_table,
|
2013-08-16 11:08:55 +08:00
|
|
|
};
|
|
|
|
|
2018-06-20 15:34:38 +08:00
|
|
|
static const struct regmap_range dspi_xspi_volatile_ranges[] = {
|
|
|
|
regmap_reg_range(SPI_MCR, SPI_TCR),
|
|
|
|
regmap_reg_range(SPI_SR, SPI_SR),
|
|
|
|
regmap_reg_range(SPI_PUSHR, SPI_RXFR3),
|
|
|
|
regmap_reg_range(SPI_SREX, SPI_SREX),
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct regmap_access_table dspi_xspi_volatile_table = {
|
2019-08-19 02:01:02 +08:00
|
|
|
.yes_ranges = dspi_xspi_volatile_ranges,
|
|
|
|
.n_yes_ranges = ARRAY_SIZE(dspi_xspi_volatile_ranges),
|
2018-06-20 15:34:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct regmap_config dspi_xspi_regmap_config[] = {
|
|
|
|
{
|
2019-08-19 02:01:02 +08:00
|
|
|
.reg_bits = 32,
|
|
|
|
.val_bits = 32,
|
|
|
|
.reg_stride = 4,
|
|
|
|
.max_register = 0x13c,
|
|
|
|
.volatile_table = &dspi_xspi_volatile_table,
|
2018-06-20 15:34:38 +08:00
|
|
|
},
|
|
|
|
{
|
2019-08-19 02:01:02 +08:00
|
|
|
.name = "pushr",
|
|
|
|
.reg_bits = 16,
|
|
|
|
.val_bits = 16,
|
|
|
|
.reg_stride = 2,
|
|
|
|
.max_register = 0x2,
|
2018-06-20 15:34:38 +08:00
|
|
|
},
|
|
|
|
};
|
|
|
|
|
2020-03-18 08:16:00 +08:00
|
|
|
static int dspi_init(struct fsl_dspi *dspi)
|
2016-10-17 18:02:34 +08:00
|
|
|
{
|
2020-03-18 08:15:52 +08:00
|
|
|
unsigned int mcr;
|
|
|
|
|
|
|
|
/* Set idle states for all chip select signals to high */
|
|
|
|
mcr = SPI_MCR_PCSIS(GENMASK(dspi->ctlr->num_chipselect - 1, 0));
|
2019-02-06 06:13:49 +08:00
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE)
|
2019-08-19 02:01:06 +08:00
|
|
|
mcr |= SPI_MCR_XSPI;
|
2019-08-19 02:01:10 +08:00
|
|
|
if (!spi_controller_is_slave(dspi->ctlr))
|
2019-02-06 06:13:49 +08:00
|
|
|
mcr |= SPI_MCR_MASTER;
|
|
|
|
|
|
|
|
regmap_write(dspi->regmap, SPI_MCR, mcr);
|
2016-10-17 18:02:34 +08:00
|
|
|
regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR);
|
2020-03-18 08:16:00 +08:00
|
|
|
|
|
|
|
switch (dspi->devtype_data->trans_mode) {
|
|
|
|
case DSPI_EOQ_MODE:
|
|
|
|
regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE);
|
|
|
|
break;
|
|
|
|
case DSPI_XSPI_MODE:
|
|
|
|
regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_CMDTCFE);
|
|
|
|
break;
|
|
|
|
case DSPI_DMA_MODE:
|
|
|
|
regmap_write(dspi->regmap, SPI_RSER,
|
|
|
|
SPI_RSER_TFFFE | SPI_RSER_TFFFD |
|
|
|
|
SPI_RSER_RFDFE | SPI_RSER_RFDFD);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
dev_err(&dspi->pdev->dev, "unsupported trans_mode %u\n",
|
|
|
|
dspi->devtype_data->trans_mode);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
2016-10-17 18:02:34 +08:00
|
|
|
}
|
|
|
|
|
2019-09-24 19:05:47 +08:00
|
|
|
static int dspi_slave_abort(struct spi_master *master)
|
|
|
|
{
|
|
|
|
struct fsl_dspi *dspi = spi_master_get_devdata(master);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Terminate all pending DMA transactions for the SPI working
|
|
|
|
* in SLAVE mode.
|
|
|
|
*/
|
2020-03-18 08:15:58 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
|
|
|
|
dmaengine_terminate_sync(dspi->dma->chan_rx);
|
|
|
|
dmaengine_terminate_sync(dspi->dma->chan_tx);
|
|
|
|
}
|
2019-09-24 19:05:47 +08:00
|
|
|
|
|
|
|
/* Clear the internal DSPI RX and TX FIFO buffers */
|
|
|
|
regmap_update_bits(dspi->regmap, SPI_MCR,
|
|
|
|
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF,
|
|
|
|
SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-05 06:00:38 +08:00
|
|
|
/*
|
|
|
|
* EOQ mode will inevitably deassert its PCS signal on last word in a queue
|
|
|
|
* (hardware limitation), so we need to inform the spi_device that larger
|
|
|
|
* buffers than the FIFO size are going to have the chip select randomly
|
|
|
|
* toggling, so it has a chance to adapt its message sizes.
|
|
|
|
*/
|
|
|
|
static size_t dspi_max_message_size(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
struct fsl_dspi *dspi = spi_controller_get_devdata(spi->controller);
|
|
|
|
|
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_EOQ_MODE)
|
|
|
|
return dspi->devtype_data->fifo_size;
|
|
|
|
|
|
|
|
return SIZE_MAX;
|
|
|
|
}
|
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
static int dspi_probe(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct device_node *np = pdev->dev.of_node;
|
2019-08-19 02:01:11 +08:00
|
|
|
const struct regmap_config *regmap_config;
|
|
|
|
struct fsl_dspi_platform_data *pdata;
|
2019-08-19 02:01:10 +08:00
|
|
|
struct spi_controller *ctlr;
|
2020-03-05 19:55:46 +08:00
|
|
|
int ret, cs_num, bus_num = -1;
|
2013-08-16 11:08:55 +08:00
|
|
|
struct fsl_dspi *dspi;
|
|
|
|
struct resource *res;
|
2014-02-12 15:29:05 +08:00
|
|
|
void __iomem *base;
|
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:53 +08:00
|
|
|
bool big_endian;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr = spi_alloc_master(&pdev->dev, sizeof(struct fsl_dspi));
|
|
|
|
if (!ctlr)
|
2013-08-16 11:08:55 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
dspi = spi_controller_get_devdata(ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
dspi->pdev = pdev;
|
2019-08-19 02:01:10 +08:00
|
|
|
dspi->ctlr = ctlr;
|
2015-01-27 18:57:22 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->setup = dspi_setup;
|
|
|
|
ctlr->transfer_one_message = dspi_transfer_one_message;
|
2020-03-05 06:00:38 +08:00
|
|
|
ctlr->max_message_size = dspi_max_message_size;
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->dev.of_node = pdev->dev.of_node;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->cleanup = dspi_cleanup;
|
2019-09-24 19:05:47 +08:00
|
|
|
ctlr->slave_abort = dspi_slave_abort;
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->mode_bits = SPI_CPOL | SPI_CPHA | SPI_LSB_FIRST;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2017-10-28 06:23:01 +08:00
|
|
|
pdata = dev_get_platdata(&pdev->dev);
|
|
|
|
if (pdata) {
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->num_chipselect = pdata->cs_num;
|
|
|
|
ctlr->bus_num = pdata->bus_num;
|
2013-08-16 11:08:55 +08:00
|
|
|
|
spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations
Currently, the device tree bindings submitted in mainline for Layerscape
SoCs look like this:
LS1021A:
compatible = "fsl,ls1021a-v1.0-dspi";
LS1012A:
compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi";
LS2085A:
compatible = "fsl,ls2085a-dspi";
LS2088A:
compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
LX2160A:
compatible = "fsl,lx2160a-dspi", "fsl,ls2085a-dspi";
LS1043A:
compatible = "fsl,ls1043a-dspi", "fsl,ls1021a-v1.0-dspi";
LS1046A:
compatible = "fsl,ls1021a-v1.0-dspi";
Due to a lack of a more specific compatible string, LS1012A, LS1043A and
LS1046A will fall under the LS1021A umbrella, and LS2088A and LX2160A
under the LS2085A umbrella.
They do work in those modes, but there are slight differences in the
hardware instantiations, mostly related to FIFO sizes (with the more
specific compatible strings, the FIFO size can be increased properly).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Message-Id: <20200302001958.11105-3-olteanv@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-02 08:19:54 +08:00
|
|
|
/* Only Coldfire uses platform data */
|
|
|
|
dspi->devtype_data = &devtype_data[MCF5441X];
|
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:53 +08:00
|
|
|
big_endian = true;
|
2017-10-28 06:23:01 +08:00
|
|
|
} else {
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2017-10-28 06:23:01 +08:00
|
|
|
ret = of_property_read_u32(np, "spi-num-chipselects", &cs_num);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(&pdev->dev, "can't get spi-num-chipselects\n");
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2017-10-28 06:23:01 +08:00
|
|
|
}
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->num_chipselect = cs_num;
|
2017-10-28 06:23:01 +08:00
|
|
|
|
2020-03-05 19:55:46 +08:00
|
|
|
of_property_read_u32(np, "bus-num", &bus_num);
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->bus_num = bus_num;
|
2017-10-28 06:23:01 +08:00
|
|
|
|
2019-02-06 06:13:49 +08:00
|
|
|
if (of_property_read_bool(np, "spi-slave"))
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->slave = true;
|
2019-02-06 06:13:49 +08:00
|
|
|
|
2017-10-28 06:23:01 +08:00
|
|
|
dspi->devtype_data = of_device_get_match_data(&pdev->dev);
|
|
|
|
if (!dspi->devtype_data) {
|
|
|
|
dev_err(&pdev->dev, "can't get devtype_data\n");
|
|
|
|
ret = -EFAULT;
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2017-10-28 06:23:01 +08:00
|
|
|
}
|
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.
This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.
The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.
So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.
Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:53 +08:00
|
|
|
|
|
|
|
big_endian = of_device_is_big_endian(np);
|
|
|
|
}
|
|
|
|
if (big_endian) {
|
|
|
|
dspi->pushr_cmd = 0;
|
|
|
|
dspi->pushr_tx = 2;
|
|
|
|
} else {
|
|
|
|
dspi->pushr_cmd = 2;
|
|
|
|
dspi->pushr_tx = 0;
|
2015-06-09 19:45:27 +08:00
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE)
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
|
2018-06-20 15:34:41 +08:00
|
|
|
else
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 16);
|
2018-06-20 15:34:41 +08:00
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
2014-02-12 15:29:05 +08:00
|
|
|
base = devm_ioremap_resource(&pdev->dev, res);
|
|
|
|
if (IS_ERR(base)) {
|
|
|
|
ret = PTR_ERR(base);
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE)
|
2018-06-20 15:34:38 +08:00
|
|
|
regmap_config = &dspi_xspi_regmap_config[0];
|
|
|
|
else
|
|
|
|
regmap_config = &dspi_regmap_config;
|
|
|
|
dspi->regmap = devm_regmap_init_mmio(&pdev->dev, base, regmap_config);
|
2014-02-12 15:29:05 +08:00
|
|
|
if (IS_ERR(dspi->regmap)) {
|
|
|
|
dev_err(&pdev->dev, "failed to init regmap: %ld\n",
|
|
|
|
PTR_ERR(dspi->regmap));
|
2017-02-19 21:19:02 +08:00
|
|
|
ret = PTR_ERR(dspi->regmap);
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2014-02-12 15:29:05 +08:00
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
The Transfer Complete Flag (TCF) interrupt gets raised after each write
to the TX FIFO (PUSHR) which means that it is not possible to devise a
transfer procedure that makes full utilization of the FIFO depth (4
entries on most controllers, 16 entries on some).
On the other hand, XSPI mode has a feature called "command cycling",
which allows a single TX command to be run for a pre-specified number of
TX words. When the command cycle ends, the Command Transfer Complete
Flag bit asserts and raises an interrupt. The advantage in this mode is
that the TX FIFO can be better utilized (more words can be batched at
once).
Other changes brought by this patch:
- The dspi->rx_end variable has been removed, since now the
dspi_fifo_write function sets up dspi->words_in_flight, so
dspi_fifo_read knows how much to read without overrunning the RX
buffer.
- Stop using poll mode unconditionally for TCFQ mode, since XSPI mode
is a little less efficient than that, and so, poll mode doesn't bring
as many improvements for XSPI.
- Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and
instead increment the message->actual_length based on the newly
introduced dspi->words_in_flight variable.
- The CTARE register is now written in the hotpath instead of just at
transfer init time, since it contains the DTCP field (transfer
preload - the counter indicating how many txdata words will follow),
which is a dynamic value.
Due to the fact that the Chip Select toggling setting is part of the
command written to the TX FIFO, the ending word of each buffer needs to
be sent via its own TX command, so that we have a chance to emit a
1-word command with deasserted PCS.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05 06:00:40 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE) {
|
2018-06-20 15:34:38 +08:00
|
|
|
dspi->regmap_pushr = devm_regmap_init_mmio(
|
|
|
|
&pdev->dev, base + SPI_PUSHR,
|
|
|
|
&dspi_xspi_regmap_config[1]);
|
|
|
|
if (IS_ERR(dspi->regmap_pushr)) {
|
|
|
|
dev_err(&pdev->dev,
|
|
|
|
"failed to init pushr regmap: %ld\n",
|
|
|
|
PTR_ERR(dspi->regmap_pushr));
|
2018-06-21 21:22:09 +08:00
|
|
|
ret = PTR_ERR(dspi->regmap_pushr);
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2018-06-20 15:34:38 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-06-29 19:33:09 +08:00
|
|
|
dspi->clk = devm_clk_get(&pdev->dev, "dspi");
|
|
|
|
if (IS_ERR(dspi->clk)) {
|
|
|
|
ret = PTR_ERR(dspi->clk);
|
|
|
|
dev_err(&pdev->dev, "unable to get clock\n");
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2018-06-29 19:33:09 +08:00
|
|
|
}
|
|
|
|
ret = clk_prepare_enable(dspi->clk);
|
|
|
|
if (ret)
|
2019-08-19 02:01:10 +08:00
|
|
|
goto out_ctlr_put;
|
2018-06-29 19:33:09 +08:00
|
|
|
|
2020-03-18 08:16:00 +08:00
|
|
|
ret = dspi_init(dspi);
|
|
|
|
if (ret)
|
|
|
|
goto out_clk_put;
|
2019-08-23 05:15:13 +08:00
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
dspi->irq = platform_get_irq(pdev, 0);
|
2019-08-23 05:15:13 +08:00
|
|
|
if (dspi->irq <= 0) {
|
|
|
|
dev_info(&pdev->dev,
|
|
|
|
"can't get platform irq, using poll mode\n");
|
|
|
|
dspi->irq = 0;
|
|
|
|
goto poll_mode;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
2020-06-22 19:05:42 +08:00
|
|
|
ret = request_threaded_irq(dspi->irq, dspi_interrupt, NULL,
|
|
|
|
IRQF_SHARED, pdev->name, dspi);
|
2013-08-16 11:08:55 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
|
2018-06-29 19:33:09 +08:00
|
|
|
goto out_clk_put;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion
Currently the driver puts the process in interruptible sleep waiting for
the interrupt train to finish transfer to/from the tx_buf and rx_buf.
But exiting the process with ctrl-c may make the kernel panic: the
wait_event_interruptible call will return -ERESTARTSYS, which a proper
driver implementation is perhaps supposed to handle, but nonetheless
this one doesn't, and aborts the transfer altogether.
Actually when the task is interrupted, there is still a high chance that
the dspi_interrupt is still triggering. And if dspi_transfer_one_message
returns execution all the way to the spi_device driver, that can free
the spi_message and spi_transfer structures, leaving the interrupts to
access a freed tx_buf and rx_buf.
hexdump -C /dev/mtd0
00000000 00 75 68 75 0a ff ff ff ff ff ff ff ff ff ff ff
|.uhu............|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
*
^C[ 38.495955] fsl-dspi 2120000.spi: Waiting for transfer to complete failed!
[ 38.503097] spi_master spi2: failed to transfer one message from queue
[ 38.509729] Unable to handle kernel paging request at virtual address ffff800095ab3377
[ 38.517676] Mem abort info:
[ 38.520474] ESR = 0x96000045
[ 38.523533] EC = 0x25: DABT (current EL), IL = 32 bits
[ 38.528861] SET = 0, FnV = 0
[ 38.531921] EA = 0, S1PTW = 0
[ 38.535067] Data abort info:
[ 38.537952] ISV = 0, ISS = 0x00000045
[ 38.541797] CM = 0, WnR = 1
[ 38.544771] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082621000
[ 38.551494] [ffff800095ab3377] pgd=00000020fffff003, p4d=00000020fffff003, pud=0000000000000000
[ 38.560229] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[ 38.565819] Modules linked in:
[ 38.568882] CPU: 0 PID: 2729 Comm: hexdump Not tainted 5.6.0-rc4-next-20200306-00052-gd8730cdc8a0b-dirty #193
[ 38.578834] Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
[ 38.587129] pstate: 20000085 (nzCv daIf -PAN -UAO)
[ 38.591941] pc : ktime_get_real_ts64+0x3c/0x110
[ 38.596487] lr : spi_take_timestamp_pre+0x40/0x90
[ 38.601203] sp : ffff800010003d90
[ 38.604525] x29: ffff800010003d90 x28: ffff80001200e000
[ 38.609854] x27: ffff800011da9000 x26: ffff002079c40400
[ 38.615184] x25: ffff8000117fe018 x24: ffff800011daa1a0
[ 38.620513] x23: ffff800015ab3860 x22: ffff800095ab3377
[ 38.625841] x21: 000000000000146e x20: ffff8000120c3000
[ 38.631170] x19: ffff0020795f6e80 x18: ffff800011da9948
[ 38.636498] x17: 0000000000000000 x16: 0000000000000000
[ 38.641826] x15: ffff800095ab3377 x14: 0720072007200720
[ 38.647155] x13: 0720072007200765 x12: 0775076507750771
[ 38.652483] x11: 0720076d076f0772 x10: 0000000000000040
[ 38.657812] x9 : ffff8000108e2100 x8 : ffff800011dcabe8
[ 38.663139] x7 : 0000000000000000 x6 : ffff800015ab3a60
[ 38.668468] x5 : 0000000007200720 x4 : ffff800095ab3377
[ 38.673796] x3 : 0000000000000000 x2 : 0000000000000ab0
[ 38.679125] x1 : ffff800011daa000 x0 : 0000000000000026
[ 38.684454] Call trace:
[ 38.686905] ktime_get_real_ts64+0x3c/0x110
[ 38.691100] spi_take_timestamp_pre+0x40/0x90
[ 38.695470] dspi_fifo_write+0x58/0x2c0
[ 38.699315] dspi_interrupt+0xbc/0xd0
[ 38.702987] __handle_irq_event_percpu+0x78/0x2c0
[ 38.707706] handle_irq_event_percpu+0x3c/0x90
[ 38.712161] handle_irq_event+0x4c/0xd0
[ 38.716008] handle_fasteoi_irq+0xbc/0x170
[ 38.720115] generic_handle_irq+0x2c/0x40
[ 38.724135] __handle_domain_irq+0x68/0xc0
[ 38.728243] gic_handle_irq+0xc8/0x160
[ 38.732000] el1_irq+0xb8/0x180
[ 38.735149] spi_nor_spimem_read_data+0xe0/0x140
[ 38.739779] spi_nor_read+0xc4/0x120
[ 38.743364] mtd_read_oob+0xa8/0xc0
[ 38.746860] mtd_read+0x4c/0x80
[ 38.750007] mtdchar_read+0x108/0x2a0
[ 38.753679] __vfs_read+0x20/0x50
[ 38.757002] vfs_read+0xa4/0x190
[ 38.760237] ksys_read+0x6c/0xf0
[ 38.763471] __arm64_sys_read+0x20/0x30
[ 38.767319] el0_svc_common.constprop.3+0x90/0x160
[ 38.772125] do_el0_svc+0x28/0x90
[ 38.775449] el0_sync_handler+0x118/0x190
[ 38.779468] el0_sync+0x140/0x180
[ 38.782793] Code: 91000294 1400000f d50339bf f9405e80 (f90002c0)
[ 38.788910] ---[ end trace 55da560db4d6bef7 ]---
[ 38.793540] Kernel panic - not syncing: Fatal exception in interrupt
[ 38.799914] SMP: stopping secondary CPUs
[ 38.803849] Kernel Offset: disabled
[ 38.807344] CPU features: 0x10002,20006008
[ 38.811451] Memory Limit: none
[ 38.814513] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
So it is clear that the "interruptible" part isn't handled correctly.
When the process receives a signal, one could either attempt a clean
abort (which appears to be difficult with this hardware) or just keep
restarting the sleep until the wait queue really completes. But checking
in a loop for -ERESTARTSYS is a bit too complicated for this driver, so
just make the sleep uninterruptible, to avoid all that nonsense.
The wait queue was actually restructured as a completion, after polling
other drivers for the most "popular" approach.
Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
Reported-by: Michael Walle <michael@walle.cc>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-7-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-18 08:15:57 +08:00
|
|
|
init_completion(&dspi->xfer_done);
|
2019-08-23 05:15:13 +08:00
|
|
|
|
|
|
|
poll_mode:
|
2019-09-05 09:01:13 +08:00
|
|
|
|
2016-11-10 20:19:15 +08:00
|
|
|
if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
|
2017-05-22 21:19:20 +08:00
|
|
|
ret = dspi_request_dma(dspi, res->start);
|
|
|
|
if (ret < 0) {
|
2016-11-10 20:19:15 +08:00
|
|
|
dev_err(&pdev->dev, "can't get dma channels\n");
|
2020-06-22 19:05:42 +08:00
|
|
|
goto out_free_irq;
|
2016-11-10 20:19:15 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
ctlr->max_speed_hz =
|
2016-03-22 04:11:52 +08:00
|
|
|
clk_get_rate(dspi->clk) / dspi->devtype_data->max_clock_factor;
|
|
|
|
|
2020-03-02 08:19:57 +08:00
|
|
|
if (dspi->devtype_data->trans_mode != DSPI_DMA_MODE)
|
|
|
|
ctlr->ptp_sts_supported = true;
|
2019-09-05 09:01:13 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
platform_set_drvdata(pdev, ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
2019-08-19 02:01:10 +08:00
|
|
|
ret = spi_register_controller(ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
if (ret != 0) {
|
2019-08-19 02:01:10 +08:00
|
|
|
dev_err(&pdev->dev, "Problem registering DSPI ctlr\n");
|
2020-06-22 19:05:42 +08:00
|
|
|
goto out_free_irq;
|
2013-08-16 11:08:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
2020-06-22 19:05:42 +08:00
|
|
|
out_free_irq:
|
|
|
|
if (dspi->irq)
|
|
|
|
free_irq(dspi->irq, dspi);
|
2013-08-16 11:08:55 +08:00
|
|
|
out_clk_put:
|
|
|
|
clk_disable_unprepare(dspi->clk);
|
2019-08-19 02:01:10 +08:00
|
|
|
out_ctlr_put:
|
|
|
|
spi_controller_put(ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dspi_remove(struct platform_device *pdev)
|
|
|
|
{
|
2019-08-19 02:01:10 +08:00
|
|
|
struct spi_controller *ctlr = platform_get_drvdata(pdev);
|
|
|
|
struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
|
|
|
/* Disconnect from the SPI framework */
|
2020-06-22 19:05:40 +08:00
|
|
|
spi_unregister_controller(dspi->ctlr);
|
|
|
|
|
|
|
|
/* Disable RX and TX */
|
|
|
|
regmap_update_bits(dspi->regmap, SPI_MCR,
|
|
|
|
SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF,
|
|
|
|
SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF);
|
|
|
|
|
|
|
|
/* Stop Running */
|
|
|
|
regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
|
|
|
|
|
2016-11-10 20:19:15 +08:00
|
|
|
dspi_release_dma(dspi);
|
2020-06-22 19:05:42 +08:00
|
|
|
if (dspi->irq)
|
|
|
|
free_irq(dspi->irq, dspi);
|
2013-10-12 15:15:31 +08:00
|
|
|
clk_disable_unprepare(dspi->clk);
|
2013-08-16 11:08:55 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-04-24 14:12:16 +08:00
|
|
|
static void dspi_shutdown(struct platform_device *pdev)
|
|
|
|
{
|
2020-06-22 19:05:41 +08:00
|
|
|
dspi_remove(pdev);
|
2020-04-24 14:12:16 +08:00
|
|
|
}
|
|
|
|
|
2013-08-16 11:08:55 +08:00
|
|
|
static struct platform_driver fsl_dspi_driver = {
|
2019-08-19 02:01:02 +08:00
|
|
|
.driver.name = DRIVER_NAME,
|
|
|
|
.driver.of_match_table = fsl_dspi_dt_ids,
|
|
|
|
.driver.owner = THIS_MODULE,
|
|
|
|
.driver.pm = &dspi_pm,
|
|
|
|
.probe = dspi_probe,
|
|
|
|
.remove = dspi_remove,
|
2020-04-24 14:12:16 +08:00
|
|
|
.shutdown = dspi_shutdown,
|
2013-08-16 11:08:55 +08:00
|
|
|
};
|
|
|
|
module_platform_driver(fsl_dspi_driver);
|
|
|
|
|
|
|
|
MODULE_DESCRIPTION("Freescale DSPI Controller Driver");
|
2013-09-10 16:46:33 +08:00
|
|
|
MODULE_LICENSE("GPL");
|
2013-08-16 11:08:55 +08:00
|
|
|
MODULE_ALIAS("platform:" DRIVER_NAME);
|