summaryrefslogtreecommitdiffstats
path: root/drivers/spi (follow)
Commit message (Collapse)AuthorAgeFilesLines
* spi: Add FSI-attached SPI controller driverEddie James2020-03-103-0/+566
| | | | | | | | | | | | | | | | 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.com Signed-off-by: Mark Brown <broonie@kernel.org>
* spi: Remove CONFIG_ prefix from Kconfig selectJoe Perches2020-03-061-1/+1
| | | | | | | | | | | | commit a2ca53b52e00 ("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: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/f8ac6b32a29b9a05b58a7e58ffe8b780642abbf1.camel@perches.com Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge series "TCFQ to XSPI migration for NXP DSPI driver" from Vladimir ↵Mark Brown2020-03-052-153/+287
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Oltean <olteanv@gmail.com> 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
| * spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_writeVladimir Oltean2020-03-051-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI modeVladimir Oltean2020-03-051-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-12-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt countVladimir Oltean2020-03-051-11/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-11-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Accelerate transfers using larger word size if possibleVladimir Oltean2020-03-051-25/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-10-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO modeVladimir Oltean2020-03-051-88/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * spi: Do spi_take_timestamp_pre for as many times as necessaryVladimir Oltean2020-03-051-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-8-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Implement .max_message_size method for EOQ modeVladimir Oltean2020-03-051-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-7-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Rename fifo_{read,write} and {tx,cmd}_fifo_writeVladimir Oltean2020-03-051-11/+11
| | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-6-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Add comments around dspi_pop_tx and dspi_push_rx functionsVladimir Oltean2020-03-051-0/+6
| | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-5-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Don't mask off undefined bitsVladimir Oltean2020-03-051-3/+0
| | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-4-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Remove unused chip->void_write_dataVladimir Oltean2020-03-051-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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 <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-3-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Simplify bytes_per_word gymnasticsVladimir Oltean2020-03-051-18/+3
| | | | | | | | | | | | | | | | | | | | | | | | 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: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: spi-fsl-dspi: Make bus-num property optionalSascha Hauer2020-03-051-6/+2
| | | | | | | | | | | | | | | | | | 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.de Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: spi-nxp-fspi: Enable the Octal Mode in MCR0Han Xu2020-03-051-2/+3
| | | | | | | | | | | | | | | | | | | | | | Apply patch from NXP upstream repo to Enable the octal combination mode in MCR0 Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-3-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: fspi: dynamically alloc AHB memoryHan Xu2020-03-051-6/+34
| | | | | | | | | | | | | | | | | | | | | | Apply patch from NXP upstream repo to dynamically allocate AHB memory as needed. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-2-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | spi: fspi: enable fspi on imx8qxp and imx8mmHan Xu2020-03-051-0/+18
|/ | | | | | | | | | | Pull in this patch from NXP's upstream repo to enable fspi on imx8qxp and imx8mm Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-1-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge series "Compatible string consolidation for NXP DSPI driver" from ↵Mark Brown2020-03-041-45/+117
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vladimir Oltean <olteanv@gmail.com>: This series makes room in the driver for differentiation between the controllers which currently operate in TCFQ mode. Most of these are actually capable of a lot more in terms of throughput. This is in preparation of a second series which will convert the remaining users of TCFQ mode altogether to XSPI mode with command cycling. Vladimir Oltean (6): doc: spi-fsl-dspi: Add specific compatibles for all Layerscape SoCs spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiations spi: spi-fsl-dspi: Parameterize the FIFO size and DMA buffer size spi: spi-fsl-dspi: LS2080A and LX2160A support XSPI mode spi: spi-fsl-dspi: Support SPI software timestamping in all non-DMA modes spi: spi-fsl-dspi: Convert the instantiations that support it to DMA .../devicetree/bindings/spi/spi-fsl-dspi.txt | 17 +- drivers/spi/spi-fsl-dspi.c | 162 +++++++++++++----- 2 files changed, 128 insertions(+), 51 deletions(-) -- 2.17.1
| * spi: spi-fsl-dspi: Convert the instantiations that support it to DMAVladimir Oltean2020-03-041-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | The A-011218 eDMA/DSPI erratum affects most of the older Layerscape SoCs with DSPI, and its workaround is a bit intrusive. After this patch, there are no users of TCFQ mode that don't also support XSPI (previously there was LS2085A). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20200302001958.11105-7-olteanv@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Support SPI software timestamping in all non-DMA modesVladimir Oltean2020-03-041-9/+2
| | | | | | | | | | | | | | | | | | There's no reason to keep this .ptp_sts_supported property explicitly in devtype_data, since it can be deduced from the operating mode alone. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20200302001958.11105-6-olteanv@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: LS2080A and LX2160A support XSPI modeVladimir Oltean2020-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | XSPI allows for 2 extra features: - Command cycling (use a single TX command with more than 1 word in the TX FIFO). - Increased word size (from 16 bits to 32 bits) Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20200302001958.11105-5-olteanv@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Parameterize the FIFO size and DMA buffer sizeVladimir Oltean2020-03-041-20/+28
| | | | | | | | | | | | | | | | | | Get rid of the ifdef for Coldfire and make these hardware characteristics part of dspi->devtype_data. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Message-Id: <20200302001958.11105-4-olteanv@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
| * spi: spi-fsl-dspi: Use specific compatible strings for all SoC instantiationsVladimir Oltean2020-03-041-23/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge series "trivial fixes for fsl-spi and spidev" from Oleksandr Suvorov ↵Mark Brown2020-03-031-5/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <oleksandr.suvorov@toradex.com>: - the memory optimization in fsl-spi - the fix of the max speed setting bug in spidev Oleksandr Suvorov (2): spi: fsl-lpspi: remove unneeded array spi: spidev: fix a max speed setting drivers/spi/spi-fsl-lpspi.c | 7 ++----- drivers/spi/spidev.c | 10 ++++++---- 2 files changed, 8 insertions(+), 9 deletions(-) -- 2.24.1
| * | spi: fsl-lpspi: remove unneeded arrayOleksandr Suvorov2020-03-031-5/+2
| |/ | | | | | | | | | | | | | | | | - replace the array with the shift operation - remove the extra comparing operation. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Link: https://lore.kernel.org/r/20200220141143.3902922-2-oleksandr.suvorov@toradex.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | Merge series "spi: spidev: Fix messages in spidev" from Oleksandr Suvorov ↵Mark Brown2020-03-027-58/+122
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <oleksandr.suvorov@toradex.com>: - fix the values source for the xfer debug message. - fix the "max speed setting" message showing. Oleksandr Suvorov (2): spi: spidev: fix a debug message value spi: spidev: fix speed setting message drivers/spi/spidev.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) -- 2.24.1
| * | spi: spidev: fix speed setting messageOleksandr Suvorov2020-03-021-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The message of max device speed setting is shown when an error in spi_setup() occurs. Instead, it should be shown when the setup call succeeds. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Link: https://lore.kernel.org/r/20200229161841.89144-3-oleksandr.suvorov@toradex.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spidev: fix a debug message valueOleksandr Suvorov2020-03-021-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The debug message in spidev_message() can show wrong xfer speed. It happens if the initial (came from DT) and set with ioctl call spidev speeds are different (spidev->speed_hz != spi->max_speed_hz) and one sends a message with ioctl call and the field of speed is uninitialized (u_tmp->speed_hz == 0). In this case the kernel shows the spi->max_speed_hz value instead of correct spidev->speed_hz. ... set the max speed with an ioctl call: [ 1227.702714] spidev spi0.0: setup mode 0, 32 bits/w, 20000000 Hz max --> 0 (real speed sets to 20000000Hz) send a message with an ioctl call: [ 1227.731801] spidev spi0.0: xfer len 4096 tx 32bits 0 usec 10000000Hz (debug message shows 10000000Hz that is the original max speed of this spidev came from DT) ... Fix the data source for the debug message. Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Link: https://lore.kernel.org/r/20200229161841.89144-2-oleksandr.suvorov@toradex.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: bcm63xx-hsspi: Really keep pll clk enabledChristophe JAILLET2020-03-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of commit 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled") was to keep the pll clk enabled through the lifetime of the device. In order to do that, some 'clk_prepare_enable()'/'clk_disable_unprepare()' calls have been added in the error handling path of the probe function, in the remove function and in the suspend and resume functions. However, a 'clk_disable_unprepare()' call has been unfortunately left in the probe function. So the commit seems to be more or less a no-op. Axe it now, so that the pll clk is left enabled through the lifetime of the device, as described in the commit. Fixes: 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Jonas Gorski <jonas.gorski@gmail.com> Link: https://lore.kernel.org/r/20200228213838.7124-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: atmel-quadspi: fix possible MMIO window size overrunTudor Ambarus2020-02-281-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The QSPI controller memory space is limited to 128MB: 0x9000_00000-0x9800_00000/0XD000_0000--0XD800_0000. There are nor flashes that are bigger in size than the memory size supported by the controller: Micron MT25QL02G (256 MB). Check if the address exceeds the MMIO window size. An improvement would be to add support for regular SPI mode and fall back to it when the flash memories overrun the controller's memory space. Fixes: 0e6aae08e9ae ("spi: Add QuadSPI driver for Atmel SAMA5D2") Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200228155437.1558219-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi/zynqmp: remove entry that causes a cs glitchThommy Jakobsson2020-02-271-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the public interface for chipselect, there is always an entry commented as "Dummy generic FIFO entry" pushed down to the fifo right after the activate/deactivate command. The dummy entry is 0x0, irregardless if the intention was to activate or deactive the cs. This causes the cs line to glitch rather than beeing activated in the case when there was an activate command. This has been observed on oscilloscope, and have caused problems for at least one specific flash device type connected to the qspi port. After the change the glitch is gone and cs goes active when intended. The reason why this worked before (except for the glitch) was because when sending the actual data, the CS bits are once again set. Since most flashes uses mode 0, there is always a half clk period anyway for cs to clk active setup time. If someone would rely on timing from a chip_select call to a transfer_one, it would fail though. It is unknown why the dummy entry was there in the first place, git log seems to be of no help in this case. The reference manual gives no indication of the necessity of this. In fact the lower 8 bits are a setup (or hold in case of deactivate) time expressed in cycles. So this should not be needed to fulfill any setup/hold timings. Signed-off-by: Thommy Jakobsson <thommyj@gmail.com> Reviewed-by: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> Link: https://lore.kernel.org/r/20200224162643.29102-1-thommyj@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: pxa2xx: Add CS control clock quirkEvan Green2020-02-261-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some circumstances on Intel LPSS controllers, toggling the LPSS CS control register doesn't actually cause the CS line to toggle. This seems to be failure of dynamic clock gating that occurs after going through a suspend/resume transition, where the controller is sent through a reset transition. This ruins SPI transactions that either rely on delay_usecs, or toggle the CS line without sending data. Whenever CS is toggled, momentarily set the clock gating register to "Force On" to poke the controller into acting on CS. Signed-off-by: Rajat Jain <rajatja@google.com> Signed-off-by: Evan Green <evgreen@chromium.org> Link: https://lore.kernel.org/r/20200211223700.110252-1-rajatja@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spidev: Fix CS polarity if GPIO descriptors are usedLukas Wunner2020-02-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") amended of_spi_parse_dt() to always set SPI_CS_HIGH for SPI slaves whose Chip Select is defined by a "cs-gpios" devicetree property. This change broke userspace applications which issue an SPI_IOC_WR_MODE ioctl() to an spidev: Chip Select polarity will be incorrect unless the application is changed to set SPI_CS_HIGH. And once changed, it will be incompatible with kernels not containing the commit. Fix by setting SPI_CS_HIGH in spidev_ioctl() (under the same conditions as in of_spi_parse_dt()). Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Reported-by: Simon Han <z.han@kunbus.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/fca3ba7cdc930cd36854666ceac4fbcf01b89028.1582027457.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org # v5.1+
| * | spi: qup: call spi_qup_pm_resume_runtime before suspendingYuji Sasaki2020-02-211-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | spi_qup_suspend() will cause synchronous external abort when runtime suspend is enabled and applied, as it tries to access SPI controller register while clock is already disabled in spi_qup_pm_suspend_runtime(). Signed-off-by: Yuji sasaki <sasakiy@chromium.org> Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20200214074340.2286170-1-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-omap2-mcspi: Support probe deferral for DMA channelsVignesh Raghavendra2020-02-061-39/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dma_request_channel() can return -EPROBE_DEFER, if DMA driver is not ready. Currently driver just falls back to PIO mode on probe deferral. Fix this by requesting all required channels during probe and propagating EPROBE_DEFER error code. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200204124816.16735-3-vigneshr@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | spi: spi-omap2-mcspi: Handle DMA size restriction on AM65xVignesh Raghavendra2020-02-061-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On AM654, McSPI can only support 4K - 1 bytes per transfer when DMA is enabled. Therefore populate master->max_transfer_size callback to inform client drivers of this restriction when DMA channels are available. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20200204124816.16735-2-vigneshr@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: pxa2xx: Introduce is_mmp2_ssp() helperAndy Shevchenko2020-02-281-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce is_mmp2_ssp() helper to be consistent with the rest helper function to distinguish SSP type. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200227162556.3152-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | Merge series "spi/HiSilicon v3xx: Support dual and quad mode through DMI ↵Mark Brown2020-02-282-2/+101
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | quirks" from John Garry <john.garry@huawei.com>: As discussed during the original HiSilicon v3xx SPI driver upstreaming, currently there is no method for the ACPI SPI Serial Bus Connection Resource Descriptor to define the data buswidth [0], [1]. So we can look to get the ACPI spec updated for this, and I have submitted a proposal for a new feature here: https://bugzilla.tianocore.org/show_bug.cgi?id=2557 However I am not sure how successful that will be. In the meantime, as an alternate approach, this RFC proposes to allow the SPI controller driver override the device buswidth. In this example, the driver uses DMI quirks to discover the host machine and set the buswidth override accordingly when the machine is known to support dual or quad mode of operation. I also have included a fix for dual and quad modes in the driver. Comments welcome. thanks. [0] https://lore.kernel.org/linux-mtd/20200109212842.GK3702@sirena.org.uk/ [1] https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf, 19.6.126 John Garry (3): spi: Allow SPI controller override device buswidth spi: HiSilicon v3xx: Properly set CMD_CONFIG for Dual/Quad modes spi: HiSilicon v3xx: Use DMI quirk to set controller buswidth override bits drivers/spi/spi-hisi-sfc-v3xx.c | 99 ++++++++++++++++++++++++++++++++- drivers/spi/spi.c | 4 +- include/linux/spi/spi.h | 3 + 3 files changed, 104 insertions(+), 2 deletions(-) -- 2.17.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
| * | | spi: HiSilicon v3xx: Use DMI quirk to set controller buswidth override bitsJohn Garry2020-02-281-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Huawei D06 board (and variants) can support Quad mode of operation. Since we have no current method in ACPI SPI bus device resource description to describe this information, use DMI to detect the board, and set the controller buswidth override bits. Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1582903131-160033-4-git-send-email-john.garry@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | spi: HiSilicon v3xx: Properly set CMD_CONFIG for Dual/Quad modesJohn Garry2020-02-281-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The CMD_CONFIG register memory interface type field is not set configured for Dual and Quad modes, so set appropriately. This was not detected previously as we only ever operated in standard SPI mode. Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1582903131-160033-3-git-send-email-john.garry@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
| * | | spi: Allow SPI controller override device buswidthJohn Garry2020-02-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently ACPI firmware description for a SPI device does not have any method to describe the data buswidth on the board. So even through the controller and device may support higher modes than standard SPI, it cannot be assumed that the board does - as such, that device is limited to standard SPI in such a circumstance. As a workaround, allow the controller driver supply buswidth override bits, which are used inform the core code that the controller driver knows the buswidth supported on that board for that device. A host controller driver might know this info from DMI tables, for example. Signed-off-by: John Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1582903131-160033-2-git-send-email-john.garry@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | | spi: spi-mem: Compute length only when neededTudor Ambarus2020-02-281-2/+3
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | When adjust_op_size is defined, len is never used. Move the len computation where it's actually used. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200228160735.1565047-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: pxa2xx: drv_data can't be NULL in ->remove()Andy Shevchenko2020-02-241-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need for drv_data check against NULL, since it won't happen. Remove useless check. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200224154556.11627-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: pxa2xx: Return error codes from pxa2xx_spi_init_pdata()Andy Shevchenko2020-02-241-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | For better understanding what's going on on error path, return distinguished error codes instead of NULL pointer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20200224154556.11627-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: rspi: Add support for LSB-first word orderGeert Uytterhoeven2020-02-191-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | All RSPI variants support selecting the word order. Advertize support for LSB-first order, and act upon the flag being set. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200218105810.902-3-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: rspi: Factor out handling of common mode bitsGeert Uytterhoeven2020-02-191-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Basic SPI features like clock phase/polarity and loopback mode are common to all RSPI variants. Factor them out to reduce duplication. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200218105810.902-2-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: spi-mem: Fix typo, s/fallback/falls backTudor Ambarus2020-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | "Fallback" in one word is a noun. "Fall back" is two separate words, a verb and an adverb. Use the latter. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200216214012.1106658-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | | spi: Add generic SPI multiplexerChris Packham2020-02-133-0/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a SPI device driver that sits in-band and provides a SPI controller which supports chip selects via a mux-control. This enables extra SPI devices to be connected with limited native chip selects. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200204032838.20739-3-chris.packham@alliedtelesis.co.nz Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-01 17:57:07 +0100