- 12 Mar, 2020 5 commits
-
-
Neil Armstrong authored
The SPICC controller in Meson-AXG is capable of running at 80M clock. The ASIC IP is improved and the clock is actually running higher than previous old SoCs. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
Yixun Lan <yixun.lan@amlogic.com> Signed-off-by:
Sunny Luo <sunny.luo@amlogic.com> Link: https://lore.kernel.org/r/20200312133131.26430-5-narmstrong@baylibre.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Sunny Luo authored
The SPICC controller in Meson-AXG SoC is capable of using a linear clock divider to reach a much fine tuned range of clocks, while the old controller only use a power of two clock divider, result at a more coarse clock range. Also convert the clock registration into Common Clock Framework. Signed-off-by:
-
Sunny Luo authored
The SPICC controller in Meson-AXG is capable of driving the CLK/MOSI/SS signal lines through the idle state (between two transmission operation), which avoid the signals floating in unexpected state. Signed-off-by:
-
Neil Armstrong authored
Remove unused variables from spicc data struct. Signed-off-by:
-
Dan Carpenter authored
The platform_get_resource_byname() function returns NULL on error, it doesn't return error pointers. Fixes: d166a735 ("spi: fspi: dynamically alloc AHB memory") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20200312113154.GC20562@mwandaSigned-off-by:
-
- 11 Mar, 2020 6 commits
-
-
Mark Brown authored
Merge tag 'mtk-mtd-spi-move' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.7 spi: Rewrite mtk-quadspi spi-nor driver with spi-mem This patchset from Chuanhong Guo <gch981213@gmail.com> adds a spi-mem driver for Mediatek SPI-NOR controller, which already has limited support by mtk-quadspi. This new driver can make use of full quadspi capability of this controller.
-
Chuanhong Guo authored
This driver is superseded by the new spi-mtk-nor driver. Signed-off-by:
Chuanhong Guo <gch981213@gmail.com> Acked-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200306085052.28258-5-gch981213@gmail.comSigned-off-by:
-
Chuanhong Guo authored
spi-mtk-nor is a driver to replace mtk-quadspi and they have almost the same device-tree bindings. Reuse this binding documentation and convert it for new driver: 1. "Mediatek SoCs" -> "Mediatek ARM SoCs" because MTK MIPS SoCs use different controllers. 2. document "interrupts" as a required property because it's available on all SoCs with this controller and new driver takes advantages of it. It's implemented as optional only to maintain backward compatibility. 3. add a dummy interrupt binding in example. Signed-off-by:
-
Chuanhong Guo authored
This is a driver for mtk spi-nor controller using spi-mem interface. The same controller already has limited support provided by mtk-quadspi driver under spi-nor framework and this new driver is a replacement for the old one. Comparing to the old driver, this driver has following advantages: 1. It can handle any full-duplex spi transfer up to 6 bytes, and this is implemented using generic spi interface. 2. It take account into command opcode properly. The reading routine in this controller can only use 0x03 or 0x0b as opcode on 1-1-1 transfers, but old driver doesn't implement this properly. This driver checks supported opcode explicitly and use (1) to perform unmatched operations. 3. It properly handles SFDP reading. Old driver can't read SFDP due to the bug mentioned in (2). 4. It can do 1-2-2 and 1-4-4 fast reading on spi-nor. These two ops requires parsing SFDP, which isn't possible in old driver. And the old driver is only flagged to support 1-1-2 mode. 5. It takes advantage of the DMA feature in this controller for long reads and supports IRQ on DMA requests to free cpu cycles from polling status registers on long DMA reading. It achieves up to 17.5MB/s reading speed (1-4-4 mode) which is way faster than the old one. IRQ is implemented as optional to maintain backward compatibility. Signed-off-by:
-
Chuanhong Guo authored
We only need a spi-max-frequency when we specifically request a spi frequency lower than the max speed of spi host. This property is already documented as optional property and current host drivers are implemented to operate at highest speed possible when spi->max_speed_hz is 0. This patch makes spi-max-frequency an optional property so that we could just omit it to use max controller speed. Signed-off-by:
-
John Garry authored
By selecting MTD_SPI_NOR for SPI_HISI_SFC_V3XX, we may introduce unmet dependencies: WARNING: unmet direct dependencies detected for MTD_SPI_NOR Depends on [m]: MTD [=m] && SPI_MASTER [=y] Selected by [y]: - SPI_HISI_SFC_V3XX [=y] && SPI [=y] && SPI_MASTER [=y] && (ARM64 && ACPI [=y] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] Since MTD_SPI_NOR is only selected by SPI_HISI_SFC_V3XX for practical reasons - slave devices use the spi-nor driver, enabled by MTD_SPI_NOR - just drop it. Signed-off-by:
John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1583948115-239907-1-git-send-email-john.garry@huawei.comSigned-off-by:
-
- 10 Mar, 2020 7 commits
-
-
Michael Walle authored
Use the correct device to request the DMA mapping. Otherwise the IOMMU doesn't get the mapping and it will generate a page fault. The error messages look like: [ 3.008452] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 [ 3.020123] arm-smmu 5000000.iommu: Unhandled context fault: fsr=0x402, iova=0xf9800000, fsynr=0x3f0022, cbfrsynra=0x828, cb=8 This was tested on a custom board with a LS1028A SoC. Signed-off-by:
Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20200310073313.21277-1-michael@walle.ccSigned-off-by:
-
Mark Brown authored
Merge series "spi: Add FSI-attached SPI controller driver" from Eddie James <eajames@linux.ibm.com>: This series adds a dts binding and a driver for a new SPI controller that is accessed over FSI bus. Eddie James (2): dt-bindings: fsi: Add FSI2SPI bindings spi: Add FSI-attached SPI controller driver .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 36 ++ MAINTAINERS | 7 + drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/spi-fsi.c | 558 ++++++++++++++++++ 5 files changed, 609 insertions(+) create mode 100644 Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml create mode 100644 drivers/spi/spi-fsi.c -- 2.24.0
-
Qiujun Huang authored
some members were not described in documentation. Signed-off-by:
Qiujun Huang <hqjagain@gmail.com> Link: https://lore.kernel.org/r/1583774179-30736-1-git-send-email-hqjagain@gmail.comSigned-off-by:
-
Geert Uytterhoeven authored
All RSPI variants support setting the polarity of the SSL signal. Advertize support for active-high chip selects, and configure polarity according to the state of the flag. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200309171537.21551-1-geert+renesas@glider.beSigned-off-by:
-
Johan Jonker authored
The Rockchip spi binding is updated to yaml and new models were added. The spi on px30,rk3308 and rk3328 are the same as other Rockchip based SoCs, so add compatible string for it. Signed-off-by:
Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200309151004.7780-1-jbx6244@gmail.comSigned-off-by:
-
Eddie James authored
There exists a set of SPI controllers on some POWER processors that may be accessed through the FSI bus. Add a driver to traverse the FSI CFAM engine that can access and drive the SPI controllers. This driver would typically be used by a baseboard management controller (BMC). The SPI controllers operate by means of programming a sequencing engine which automatically manages the usual SPI protocol buses. The driver programs each transfer into the sequencer as various operations specifying the slave chip and shifting data in and out on the lines. Signed-off-by:
Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20200306194118.18581-3-eajames@linux.ibm.comSigned-off-by:
-
Eddie James authored
Add documentation for the FSI2SPI CFAM engine, which provides access to a number of SPI controllers. Signed-off-by:
-
- 06 Mar, 2020 1 commit
-
-
Joe Perches authored
commit a2ca53b5 ("spi: Add HiSilicon v3xx SPI NOR flash controller driver") likely inadvertently used a select statement with a CONFIG_ prefix, remove the prefix. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
-
- 05 Mar, 2020 21 commits
-
-
Mark Brown authored
Vladimir Oltean <vladimir.oltean@nxp.com>: From: Vladimir Oltean <vladimir.oltean@nxp.com> This series aims to remove the most inefficient transfer method from the NXP DSPI driver. TCFQ (Transfer Complete Flag) mode works by transferring one word, waiting for its TX confirmation interrupt (or polling on the equivalent status bit), sending the next word, etc, until the buffer is complete. The issue with this mode is that it's fundamentally incompatible with any sort of batching such as writing to a FIFO. But actually, due to previous patchset ("Compatible string consolidation for NXP DSPI driver"): https://patchwork.kernel.org/cover/11414593/ all existing users of TCFQ mode today already support a more advanced feature set, in the form of XSPI (extended SPI). XSPI brings 2 extra features: - Word sizes up to 32 bits. This is sub-utilized today, and acceleration of smaller-than-32 bpw values is provided. - "Command cycling", basically the ability to write multiple words in a row and receiving an interrupt only after the completion of the last one. This is what enables us to make use of the full FIFO depth of this controller. Series was tested on the NXP LS1021A-TSN and LS1043A-RDB boards, both functionally as well as from a performance standpoint. The command used to benchmark the increased throughput was: spidev_test --device /dev/spidev1.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 where spidev1.0 is a dummy spidev node, using a chip select that no peripheral responds to. On LS1021A, which has a 4-entry-deep FIFO and a less powerful CPU, the performance increase brought by this patchset is from 2700 kbps to 5800 kbps. On LS1043A, which has a 16-entry-deep FIFO and a more powerful CPU, the performance increases from 4100 kbps to 13700 kbps. On average, SPI software timestamping is not adversely affected by the extra batching, due to the extra patches. There is one extra patch which clarifies why the TCFQ users were not converted to the "other" mode in this driver that makes use of the FIFO, which would be EOQ mode. My request to the many people on CC (known users and/or contributors) is to give this series a test to ensure there are no regressions, and for the Coldfire maintainers to clarify whether the EOQ limitation is acceptable for them in the long run. Vladimir Oltean (12): spi: spi-fsl-dspi: Simplify bytes_per_word gymnastics spi: spi-fsl-dspi: Remove unused chip->void_write_data spi: spi-fsl-dspi: Don't mask off undefined bits spi: spi-fsl-dspi: Add comments around dspi_pop_tx and dspi_push_rx functions spi: spi-fsl-dspi: Rename fifo_{read,write} and {tx,cmd}_fifo_write spi: spi-fsl-dspi: Implement .max_message_size method for EOQ mode spi: Do spi_take_timestamp_pre for as many times as necessary spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt count spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI mode spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_write drivers/spi/spi-fsl-dspi.c | 421 ++++++++++++++++++++++++------------- drivers/spi/spi.c | 19 +- include/linux/spi/spi.h | 3 +- 3 files changed, 288 insertions(+), 155 deletions(-) -- 2.17.1 -
Johan Jonker authored
The description below is already in use for rk3328.dtsi, but was somehow never added to a document, so add "rockchip,rk3328-spi", "rockchip,rk3066-spi" for spi nodes on a rk3328 platform to spi-rockchip.yaml. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200304184203.9548-3-jbx6244@gmail.comSigned-off-by:
-
Johan Jonker authored
The description below is already in use for rk3308.dtsi, but was somehow never added to a document, so add "rockchip,rk3308-spi", "rockchip,rk3066-spi" for spi nodes on a rk3308 platform to spi-rockchip.yaml. Signed-off-by:
-
Johan Jonker authored
Current dts files with 'spi' nodes are manually verified. In order to automate this process spi-rockchip.txt has to be converted to yaml. In the new setup spi-rockchip.yaml will inherit properties from spi-controller.yaml. Add document to MAINTAINERS. Also rk3188.dtsi, rk3288.dtsi, rk3368.dtsi and rk3399.dtsi use an extra fallback string, so change this in the documentation. Changed: "rockchip,rk3188-spi", "rockchip,rk3066-spi" "rockchip,rk3288-spi", "rockchip,rk3066-spi" "rockchip,rk3368-spi", "rockchip,rk3066-spi" "rockchip,rk3399-spi", "rockchip,rk3066-spi" Signed-off-by:
-
Sascha Hauer authored
The SPI bus number is completely optional to Linux, so make the corresponding device tree property optional as well. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20200305115546.31814-1-s.hauer@pengutronix.deSigned-off-by:
-
Adam Ford authored
Add support for nxp,imx8qxp-fspi and nxp,imx8mm-fspi do the bindings document. Signed-off-by:
Adam Ford <aford173@gmail.com> Link: https://lore.kernel.org/r/20200126140913.2139260-4-aford173@gmail.comSigned-off-by:
-
Han Xu authored
Apply patch from NXP upstream repo to Enable the octal combination mode in MCR0 Signed-off-by:
Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-3-aford173@gmail.comSigned-off-by:
-
Han Xu authored
Apply patch from NXP upstream repo to dynamically allocate AHB memory as needed. Signed-off-by:
-
Han Xu authored
Pull in this patch from NXP's upstream repo to enable fspi on imx8qxp and imx8mm Signed-off-by:
-
Vladimir Oltean authored
Although the SPI system timestamps are supposed to reflect the moment that the peripheral has received a word rather than the moment when the CPU has enqueued that word to the FIFO, in practice it is easier to just record the latter time than the former (with a smaller error). With the recent migration of TCFQ users from poll back to interrupt mode (this time for XSPI FIFO), it's wiser to keep the interrupt latency outside of the measurement of the PTP system timestamp itself. If there proves to be any constant offset that requires static compensation, that can always be added later. So far that does not appear to be the case at least on the LS1021A-TSN board, where testing shows that the phc2sys offset is able to remain within +/- 200 ns even after 68 hours of testing. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-13-olteanv@gmail.comSigned-off-by:
-
Vladimir Oltean authored
The EOQ mode has a hardware limitation in that it stops the transmission (including the deassertion of the chip select signal) once the host CPU requests end-of-queue for a particular word in the TX FIFO. And XSPI mode has a limitation in that we need a separate CMD FIFO entry for the last byte in the buffer, where the chip select signal needs to be deasserted. It's not a functional limitation, but it's rather clunky and the fact that we need to halt the pipeline and write a single entry to the TX FIFO whenever a buffer ends brings the throughput down when transmitting small buffers. So the idea here is to use EOQ's limitation in our favor when using XSPI mode. Stop special-casing that final word in the buffer, and just kill the chip select signal by issuing an EOQ for that last word. Now it can be mixed in with all the other words in the current TX FIFO train. A small trick here is that we still keep using the XSPI-specific signaling via the CMDTCFQ interrupt in RSER, and not enabling the EOQ interrupt, in order to avoid hardware weirdness (potential races with separate interrupts being raised for CMDTCFQ and EOQ for what is in fact the end of the same transmission). That is just theoretical, but it's good to be cautious, and the EOQ interrupt isn't needed. Signed-off-by:
-
Vladimir Oltean authored
Currently, a SPI transfer that is not multiple of the highest supported word width (e.g. 4 bytes) will be transmitted as follows (assume a 30-byte buffer transmitted through a 32-bit wide FIFO that is 32 bytes deep): - First 28 bytes are sent as 7 words of 32 bits each - Last 2 bytes are sent as 1 word of 16 bits size But if the dspi_setup_accel function had decided to use a lower oper_bits_per_word value (16 instead of 32), there would have been enough space in the TX FIFO to fit the entire buffer in one go (15 words of 16 bits each). What we're actually trying to avoid is mixing word sizes within the same run with the TX FIFO, since there is an erratum surrounding this, and invalid data might get transmitted. So this patch adds special cases for when the remaining length of the buffer can be sent in one go as 8-bit or 16-bit words, otherwise it falls back to the standard logic of sending as many bytes as possible at the highest oper_bits_per_word value possible. The benefit is that there will be one less CMDFQ/EOQ interrupt to service when the entire buffer is transmitted during a single go, and that will improve the overall latency of the transfer. Signed-off-by:
-
Vladimir Oltean authored
This patch adds logic in the driver to transmit SPI buffers that use bits_per_word=8 with a higher bits_per_word count (multiple of 8). Currently the following (most common) modes are implemented: - 8 bits_per_word on 32-bit capable controllers - 8 bits_per_word on 16-bit capable controllers - 16 bits_per_word on 32-bit capable controllers Transfers which are not accelerated are transferred with a hardware bits_per_word value equal to the one of the SPI transfer. The difference from just extending bits_per_word=32 at the spi_device driver level is that endianness is different - the SPI core wants to treat bits_per_word=32 buffers as arrays of u32 (i.e. words in host CPU endianness). So to preserve endianness when clumping 8x4 bits into 32-bit words, one must perform conversion between CPU and standard (big) endianness. All appearances (both on the wire as well as in the buffers presented to the peripheral driver) are preserved, just that accesses to the PUSHR and POPR registers are now more efficient, since the same number of reads/writes can now carry more data (2x more data on TX, 4x more data on RX). Signed-off-by:
-
Vladimir Oltean authored
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 authored
When dealing with a SPI controller driver that is sending more than 1 byte at once (or the entire buffer at once), and the SPI peripheral driver has requested timestamping for a byte in the middle of the buffer, we find that spi_take_timestamp_pre never records a "pre" timestamp. This happens because the function currently expects to be called with the "progress" argument >= to what the peripheral has requested to be timestamped. But clearly there are cases when that isn't going to fly. And since we can't change the past when we realize that the opportunity to take a "pre" timestamp has just passed and there isn't going to be another one, the approach taken is to keep recording the "pre" timestamp on each call, overwriting the previously recorded one until the "post" timestamp is also taken. Signed-off-by:
-
Vladimir Oltean authored
When it gets set, End Of Queue Flag halts the DSPI controller and forces the chip select signal to deassert. This operating mode is not ideal, but it is used for the DSPI instantiations where there is no other notification from the controller that the data in the FIFO has finished transmission. So in practice, it means that transmitting buffers larger than the FIFO size will yield unpredictable results. The only controller that operates in EOQ mode is MCF5441X (Coldfire). I would say that the way EOQ is used (and documented in the reference manual, too) on this chip is incorrect, and I would personally migrate it to TCFQ, but that's notably worse in terms of performance (it can only use 1 entry of the 16-deep FIFO) and if this limitation didn't bother any Coldfire DSPI user so far, it's likely that we just need to throw an error for larger buffers to make sure that callers are aware their transfers are getting truncated/split. Signed-off-by:
-
Vladimir Oltean authored
These function names are very generic and it is easy to get confused. Rename them after the hardware register that they are accessing. Signed-off-by:
-
Vladimir Oltean authored
Their names are confusing, since dspi_pop_tx prepares a word to be written to the PUSHR register, and dspi_push_rx gets a word from the POPR register. Signed-off-by:
-
Vladimir Oltean authored
This is a useless operation, and if the driver needs to do that, there's something deeply wrong going on. Signed-off-by:
-
Vladimir Oltean authored
This variable has been present since the initial submission of the driver, and held, for some reason, the value of zero, to be sent on the wire in the case there wasn't any TX buffer for the current transfer. Since quite a while now, however, it isn't doing anything at all. Signed-off-by:
-
Vladimir Oltean authored
Reduce the if-then-else-if-then-else sequence to: - a simple division in the case of bytes_per_word calculation - a memcpy command with a variable size. The semantics of larger-than-8 xfer->bits_per_word is that those words are to be interpreted and transmitted in CPU native endianness. Signed-off-by:
-
