The latest SPI controllers embedded inside sama5d2x SoCs come with FIFOs.
When FIFOs are enabled, they can either work in SINGLE data mode or
MULTIPLE data mode. The selected mode depends on the configuration of the
SPI controller (see below).
In SINGLE data mode (or legacy mode), for a single I/O access, only one
data can be read from the Receive Data Register (RDR) or written into the
Transmit Data Register (TDR). On the other hand, in MULTIPLE data mode, up
to 4 data can be read from the RDR or up 2 data can be written into the
TDR in a single 32bit I/O access. So programmers should take good care of
the width of the I/O access to read/write the right number of data. The
exact number of read/written data depends on both the I/O access width and
the data width (from 8 up to 16 bits).
To enable the FIFO feature a "atmel,fifo-size" property must be set to
provide the maximum number of data (not bytes) the RX and TX FIFOs can
store. Hence a 32 data FIFO can always store up to 32 data unrelated with
the actual data width.
When FIFOs are enabled, the RX one is forced to operate in SINGLE data
mode because this driver configures the spi controller as a master. In
master mode only, the Received Data Register has an additionnal Peripheral
Chip Select field, which prevents us from reading more than a single data
at each register access.
Besides, the TX FIFO operates in MULTIPLE data mode. However, even when a
8bit data size is used, only two data by access could be written into the
Transmit Data Register. Indeed the first data has to be written into the
lowest 16 bits whereas the second data has to be written into the highest
16 bits of the TDR. When DMA transfers are used to send data, we don't
rework the transmit buffer to cope with this hardware limitation: the
additional copies required to prepare a new input buffer suited to both
the DMA controller and the spi controller would waste all the benefit of
the DMA transfer. Instead, the DMA controller is configured to write only
one data at time into the TDR.
In pio mode, two data are written in the TDR in a single access.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for GQSPI controller driver used by
Zynq Ultrascale+ MPSoC
Signed-off-by: Ranjit Waghmode <ranjit.waghmode@xilinx.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI hardware spec for Keystone specify a lower value of 0 for pre-scale
divider which determine what max value of spi clock (spi-max-frequency)
the device can support. This translates to a clock divider of 2. So fix
the lower limit value used for the boundary check in
davinci_spi_get_prescale() function to 1 so that a maximum of spi device
clock rate / 2 is possible to be set for spi-max-frequency.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In current driver, we increase actual_length in the following way:
message->actual_length += dspi_xxx_transfer()
It has two defects.
First, transmitting maybe in process when the function call finished and
we don't know the transmitting result in this moment.
Secondly, the last sentence in function before returning is accessing the
SPI register and trigger the data transmitting. If we enable interrupt,
interrupt may be generated before function return and we also have the same
sentence "message->actual_length += dspi_xxx_transfer()"
in the IRQ handler.
And usually dspi_xxx_transfer will trigger a new IRQ.
The original dspi_xxx_transfer call may return when no new IRQ generate.
This may mess the variable spi_message->actual_length.
Now we increase the variable in the IRQ handler and only when we get the
TCF or EOQ interrupt
And we get the transmitted data length from the SPI transfer counter
instead of the function return value.
Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DSPI module has two optional interrupts when complete data transfer.
One is EOQ interrupt, the other one is TCF interrupt.
EOQ indicates a queue of data frame has been transmitted.
TCF indicates a frame has been transmitted.
This patch enable support TCF mode.
Driver binds a correct interrupt mode to every compatible string.
User should use the correct compatible string in the dts node.
Signed-off-by: Haikun Wang <haikun.wang@freescale.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch relies on the CSAAT (Chip Select Active After Transfer) feature
introduced by the version 2 of the spi controller. This new mode allows to
use properly the internal chip-select output pin of the spi controller
instead of using external gpios. Consequently, the "cs-gpios" device-tree
property becomes optional.
When the new CSAAT bit is set into the Chip Select Register, the internal
chip-select output pin remains asserted till both the following conditions
become true:
- the LASTXFER bit is set into the Control Register (or the Transmit Data
Register)
- the Transmit Data Register and its shift register are empty.
WARNING: if the LASTXFER bit is set into the Control Register then new
data are written into the Transmit Data Register fast enough to keep its
shifter not empty, the chip-select output pin remains asserted. Only when
the shifter becomes empty, the chip-select output pin is unasserted.
When the CSAAT bit is clear in the Chip Select Register, the LASTXFER bit
is ignored in both the Control Register and the Transmit Data Register.
The internal chip-select output pin remains active as long as the Transmit
Data Register or its shift register are not empty.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Generic DMA support was already implemented by commit cd7bed0034
("spi/pxa2xx: break out the private DMA API usage into a separate file")
which moved all the legacy PXA DMA implementation code into its own
file.
With generic DMA available for PXA, we can now just trash this file.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Mark Brown <broonie@linaro.org>
[respin after pxa dmaengine support upstream]
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
General register located in LPSS SPI private register space is not found in
upcoming Intel LPSS platforms. Access it conditionally depending is it
defined in configuration.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of the Intel LPSS SPI properties will be different in upcoming
platforms compared to existing Lynxpoint and BayTrail/Braswell. LPSS SPI
private registers will be at different offset and there will be changes in
individual registers and default FIFO thresholds too.
Add configuration for these differences and use them in runtime based on
LPSS SSP type. With this change private registers offset autodetection
becomes needless.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel LPSS SPI properties differ between between platforms. Now private
registers offset 0x400 or 0x800 is autodetected but there is need to
support also other offset and handle a few other differences.
Prepare for that by splitting the LPSS_SSP type into compatible hardware
types and set it now based on PCI or ACPI ID. That type will be used to set
properties that differ between current and upcoming platforms.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The case where spi_master sets the flags SPI_MASTER_MUST_RX/TX while
CONFIG_HAS_DMA is unset (which is unlikley) together with a driver
that reuses spi_messages with rx/tx_buff set to NULL, can result in:
* data disclosure over the SPI (for tx_buf == NULL)
* memory corruption (for rx_buf == NULL)
This happenes when dummy_rx/dummy_tx are changing address due to krealloc
or free and an allocation of the memory by a different part of the kernel.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
To reduce complexity of code, drop "ret" then qspi_transfer_out_in function
should return the value of "qspi_trigger_transfer_out_in" directly.
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
The name of "qspi_trigger_transfer_out_int" function should be
"qspi_trigger_transfer_out_in" without "t".
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown
Cyrille Pitchen
Mathias Krause
Ranjit Waghmode
Mirza Krak
Murali Karicheri
Haikun Wang
Daniel Mack
Jarkko Nikula
Martin Sperl
Hiep Cao Minh