- 29 Sep, 2020 9 commits
-
-
Serge Semin authored
There is no point in having the commit 19b61392 ("spi: spi-dw: Add lock protect dw_spi rx/tx to prevent concurrent calls") applied. The commit author made an assumption that the problem with the rx data mismatch was due to the lack of the data protection. While most likely it was caused by the lack of the memory barrier. So having the commit bfda0445 ("spi: dw: use "smp_mb()" to avoid sending spi data error") applied would be enough to fix the problem. Indeed the spin unlock operation makes sure each memory operation issued before the release will be completed before it's completed. In other words it works as an implicit one way memory barrier. So having both smp_mb() and the spin_unlock_irqrestore() here is just redundant. One of them would be enough. It's better to leave the smp_mb() since the Tx/Rx buffers consistency is provided by the data transfer algorithm implementation: first we initialize the buffers pointers, then make sure the assignments are visible by the other CPUs by calling the smp_mb(), only after that enable the interrupt, which handler uses the buffers. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-5-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
In a further commit we'll have to get rid of the update_cr0() callback and define a DW SSI capability instead. Since Keem Bay master/slave functionality is controller by the CTRL0 register bitfield, we need to first move the master mode selection into the internal corresponding update_cr0 method, which would be activated by means of the dedicated DW_SPI_CAP_KEEMBAY_MST capability setup. Note this will be also useful if the driver will be ever altered to support the DW SPI slave interface. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-11-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
There are several vendor-specific versions of the DW SPI controllers, each of which may have some peculiarities with respect to the original IP-core. Seeing it has already caused adding flags and a callback into the DW SPI private data, let's introduce a generic capabilities interface to tune the generic DW SPI controller driver up in accordance with the particular controller specifics. It's done by converting a simple Alpine-specific CS-override capability into the DW SPI controller capability activated by setting the DW_SPI_CAP_CS_OVERRIDE flag. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-10-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
Keeping SPI peripheral devices type is pointless since first it hasn't been functionally utilized by any of the client drivers/code and second it won't work for Microwire type at the very least. Moreover there is no point in setting up the type by means of the chip-data in the modern kernel. The peripheral devices with specific interface type need to be detected in order to activate the corresponding frame format. It most likely will require some peripheral device specific DT property or whatever to find out the interface protocol. So let's remove the serial interface type fields from the DW APB SSI controller and the SPI peripheral device private data. Note we'll preserve the explicit SSI_MOTO_SPI interface type setting up to signify the only currently supported interface protocol. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-9-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
In accordance with [1] the relaxed methods are guaranteed to be ordered with respect to other accesses from the same CPU thread to the same peripheral. This is what we need during the data read/write from/to the controller FIFOs being executed within a single IRQ handler or a kernel task. Such optimization shall significantly speed the data reader and writer up. For instance, the relaxed IO-accessors utilization on Baikal-T1 lets the driver to support the SPI memory operations with bus frequency three-fold faster than if normal IO-accessors would be used. [1] "LINUX KERNEL MEMORY BARRIERS", Documentation/memory-barriers.txt, Section "KERNEL I/O BARRIER EFFECTS" Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-8-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
It's a good practice to disable all IRQs if a device is fully unused. In our case it is supposed to be done before requesting the IRQ and after the last byte of an SPI transfer is received. In the former case it's required to prevent the IRQ handler invocation before the driver data is fully initialized (which may happen if the IRQs status has been left uncleared before the device is probed). So we just moved the spi_hw_init() method invocation to the earlier stage before requesting the IRQ. In the later case there is just no point in having any of the IRQs enabled between SPI transfers and when there is no SPI message currently being processed. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-7-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
It turns out the IRQ status isn't cleared after switching the controller off and getting it back on, which may cause raising false error interrupts if controller has been unsuccessfully used by, for instance, a bootloader before the driver is loaded. Let's explicitly clear the interrupts status in the dedicated controller reset method. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-6-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
Since n_bytes field of the DW SPI private data is also utilized by the IRQ handler, we need to make sure it' initialization is done before the memory barrier. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-4-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
Serge Semin authored
The macro has been unused since a half of FIFO length was defined to be a marker of the IRQ. Let's remove it definition. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20200920112914.26501-2-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 28 Sep, 2020 1 commit
-
-
Colin Ian King authored
There is a spelling mistake in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200928123042.125359-1-colin.king@canonical.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 25 Sep, 2020 6 commits
-
-
Mark Brown authored
Merge series "Add IRQ mode support for hisi-sfc-v3xx driver and some cleanups" from Yicong Yang <yangyicong@hisilicon.com>: This series mainly add the IRQ mode support for hisi-sfc-v3xx driver, and some cleanups for the preparation of the IRQ mode. After this patch, the device can work in IRQ mode, or if firmware doesn't declare irq support it will fall back to Poll mode. Patch 1-2 refactor the .exec_op() path to make it simpler and clearer. Patch 3 factor the definition of the interrupt bits. Patch 4 add the IRQ support of the driver. Yicong Yang (4): spi: hisi-sfc-v3xx: factor out IO modes configuration spi: hisi-sfc-v3xx: factor out bus config and transfer functions spi: hisi-sfc-v3xx: factor out the bit definition of interrupt register spi: hisi-sfc-v3xx: add support for IRQ mode drivers/spi/spi-hisi-sfc-v3xx.c | 261 +++++++++++++++++++++++++++++----------- 1 file changed, 190 insertions(+), 71 deletions(-) -- 2.8.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
-
Chuanhong Guo authored
CLK_TO_US macro is used to calculate potential transfer time for various timeout handling. However it overflows on transfer bigger than 512 bytes because it first did (len * 8 * 1000000). This controller typically operates at 45MHz. This patch did 2 things: 1. calculate clock / 1000000 first 2. add a 4M transfer size cap so that the final timeout in DMA reading doesn't overflow Fixes: 881d1ee9 ("spi: add support for mediatek spi-nor controller") Cc: <stable@vger.kernel.org> Signed-off-by: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/20200922114905.2942859-1-gch981213@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Yicong Yang authored
The controller can work with interrupts, so add support for it. Then we can work under IRQ mode or Poll mode now, if firmware doesn't declare the IRQ support, it will fall back to Poll mode. Acked-by: John Garry <john.garry@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/1600950270-52536-5-git-send-email-yangyicong@hisilicon.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Yicong Yang authored
The definition of the register field in the interrupt corresponding registers are the same. So factor them out to public place. Acked-by: John Garry <john.garry@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/1600950270-52536-4-git-send-email-yangyicong@hisilicon.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Yicong Yang authored
In hisi_sfc_v3xx_generic_exec_op(), we will write the data to the buffer, configure and start the transfer, read the data to the buffer and check whether occurs an error. Factor out the config and transfer start codes as individual functions, to make the process a bit clearer. Acked-by: John Garry <john.garry@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/1600950270-52536-3-git-send-email-yangyicong@hisilicon.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Yicong Yang authored
Factor IO modes configuration out of hisi_sfc_v3xx_generic_exec_op() using an IO modes lookup table. This will make the process a bit clearer and reduce the cyclomatic complexity. Simplify the IO mode definition macros a little bit as well. Also add the .supports_op() method for the controller mem ops, in order to avoid OOB access. Acked-by: John Garry <john.garry@huawei.com> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/1600950270-52536-2-git-send-email-yangyicong@hisilicon.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 24 Sep, 2020 3 commits
-
-
Amit Kumar Mahapatra authored
Fixed incorrect indentation in ZynqMP qspi controller driver. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/2b246b6f0925c8a2a767a4240e8738ffeefd62be.1600931476.git.michal.simek@xilinx.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Amit Kumar Mahapatra authored
Updated Zynqmp qspi controller driver to use spi-mem framework. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/490a7642a975f4d3dd9618304e9e45f7e2414661.1600931476.git.michal.simek@xilinx.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Amit Kumar Mahapatra authored
Fix kernel-doc warnings in ZynqMP qspi driver file. Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/ba5920c57eee06fafa6f9d1df9859e69819ac301.1600931476.git.michal.simek@xilinx.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 23 Sep, 2020 1 commit
-
-
Marc Kleine-Budde authored
This patch implementes the reporting of the effectivly used speed_hz for the transfer by setting tfr->effective_speed_hz. See the following patch, which adds this feature to the SPI core for more information: 5d7e2b5e spi: core: allow reporting the effectivly used speed_hz for a transfer Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20200917202420.1914104-1-mkl@pengutronix.deSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 22 Sep, 2020 2 commits
-
-
Aswath Govindraju authored
This reverts commit 13d515c7 (spi: omap2-mcspi: Switch to readl_poll_timeout()). The amount of time spent polling for the MCSPI_CHSTAT bits to be set on AM335x-icev2 platform is less than 1us (about 0.6us) in most cases, with or without using DMA. So, in most cases the function need not sleep. Also, setting the sleep_usecs to zero would not be optimal here because ktime_add_us() used in readl_poll_timeout() is slower compared to the direct addition used after the revert. So, it is sub-optimal to use readl_poll_timeout in this case. When DMA is not enabled, this revert results in an increase of about 27% in throughput and decrease of about 20% in CPU usage. However, the CPU usage and throughput are almost the same when used with DMA. Therefore, fix this by reverting the commit which switched to using readl_poll_timeout(). Fixes: 13d515c7 ("spi: omap2-mcspi: Switch to readl_poll_timeout()") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20200910122624.8769-1-a-govindraju@ti.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/20200921131106.93228-1-miaoqinglang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 21 Sep, 2020 1 commit
-
-
Julia Lawall authored
sg_init_table zeroes its first argument, so the allocation of that argument doesn't have to. the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,n,flags; @@ x = - kcalloc + kmalloc_array (n,sizeof(*x),flags) ... sg_init_table(x,n) // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/1600601186-7420-12-git-send-email-Julia.Lawall@inria.frSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 17 Sep, 2020 11 commits
-
-
Mark Brown authored
This series implements a number of fixes for the FSI-attached SPI controller driver. Changes since v1: - Switch to a new compatible string for the restricted version of the SPI controller, rather than a new boolean parameter. Brad Bishop (3): spi: fsi: Handle 9 to 15 byte transfers lengths spi: fsi: Fix clock running too fast spi: fsi: Fix use of the bneq+ sequencer instruction Eddie James (3): dt-bindings: fsi: fsi2spi: Add compatible string for restricted version spi: fsi: Implement restricted size for certain controllers spi: fsi: Check mux status before transfers .../devicetree/bindings/fsi/ibm,fsi2spi.yaml | 1 + drivers/spi/spi-fsi.c | 139 ++++++++++++++---- 2 files changed, 109 insertions(+), 31 deletions(-) -- 2.26.2
-
Jay Fang authored
Free previously allocated IRQs when return an error code of desc->setup() which is not always successful. And simplify the code by adding a goto label. Fixes: 8f5c285f ("SPI: designware: pci: Switch over to MSI interrupts") CC: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Jay Fang <f.fangjian@huawei.com> Link: https://lore.kernel.org/r/1600132969-53037-1-git-send-email-f.fangjian@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
kuldip dwivedi authored
Currently NXP fspi driver has support of DT only. Adding ACPI support to the driver so that it can be used by UEFI firmware booting in ACPI mode. This driver will be probed if any firmware will expose HID "NXP0009" in DSDT table. Signed-off-by: kuldip dwivedi <kuldip.dwivedi@puresoftware.com> Reviewed-by: Ashish Kumar <Ashish.Kumar@nxp.com> Link: https://lore.kernel.org/r/20200911130331.6313-1-kuldip.dwivedi@puresoftware.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Barry Song authored
Running in hardIRQ, disabling irq is redundant. Signed-off-by: Barry Song <song.bao.hua@hisilicon.com> Link: https://lore.kernel.org/r/20200916101042.21860-1-song.bao.hua@hisilicon.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Ricardo Ribalda authored
The info message was showing the mapped address of the device. To avoid security problems, all virtual addresses are converted to __ptrval__, so the message was useless/ugly: [ 2.304949] xilinx_spi b0010000.spi-flash: at 0xB0010000 mapped to 0x(____ptrval____), irq=37 Use %pR instead: [ 15.021354] xilinx_spi b0010000.spi-flash: at [mem 0xb0010000-0xb001ffff], irq=37 Signed-off-by: Ricardo Ribalda <ribalda@kernel.org> Acked-by: Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/20200915112936.320647-1-ribalda@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Eddie James authored
Add a compatible string for the restricted version of the SPI controller. The restricted version cannot process sequence loop operations and therefore has a smaller transfer size. Signed-off-by: Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/20200909222857.28653-5-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Eddie James authored
The SPI controllers are not accessible if the mux isn't set. Therefore, check the mux status before starting a transfer and fail out if it isn't set. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-7-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Eddie James authored
Some of the FSI-attached SPI controllers cannot use the loop command in programming the sequencer due to security requirements. Check the devicetree compatibility that indicates this condition and restrict the size for these controllers. Also, add more transfers directly in the sequence up to the length of the sequence register. Fixes: bbb6b2f9 ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-6-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Brad Bishop authored
All of the switches in N2_count_control in the counter configuration are required to make the branch if not equal and increment command work. Set them when using bneq+. A side effect of this mode requires a dummy write to TDR when both transmitting and receiving otherwise the controller won't start shifting receive data. It is likely not possible to avoid TDR underrun errors in this mode and they are harmless, so do not check for them. Fixes: bbb6b2f9 ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-4-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Brad Bishop authored
Use a clock divider tuned to a 200MHz FSI bus frequency (the maximum). Use of the previous divider at 200MHz results in corrupt data from endpoint devices. Ideally the clock divider would be calculated from the FSI clock, but that would require some significant work on the FSI driver. With FSI frequencies slower than 200MHz, the SPI clock will simply run slower, but safely. Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-3-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Brad Bishop authored
The trailing <len> - 8 bytes of transfer data in this size range is no longer ignored. Fixes: bbb6b2f9 ("spi: Add FSI-attached SPI controller driver") Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200909222857.28653-2-eajames@linux.ibm.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
- 14 Sep, 2020 6 commits
-
-
Krzysztof Kozlowski authored
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Chunyan Zhang <zhang.lyra@gmail.com> Link: https://lore.kernel.org/r/20200910160706.5883-1-krzk@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>
-
Douglas Anderson authored
If we're sending bytes over SPI, we know the FIFO is empty at the start of the transfer. There's no reason to wait for the interrupt telling us to start--we can just start right away. Then if we transmit everything in one swell foop we don't even need to bother listening for TX interrupts. In a test of "flashrom -p ec -r /tmp/foo.bin" interrupts were reduced from ~30560 to ~29730, about a 3% savings. This patch looks bigger than it is because I moved a few functions rather than adding a forward declaration. The only actual change to geni_spi_handle_tx() was to make it return a bool indicating if there is more to tx. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Akash Asthana <akashast@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200912111716.1.Ied5e843fad0d6b733a1fb8bcfb364dd2fa889eb3@changeidSigned-off-by: Mark Brown <broonie@kernel.org>
-
Jason Yan authored
This eliminates the following sparse warning: drivers/spi/spi-bcm2835.c:78:14: warning: symbol 'polling_limit_us' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200912072211.602735-1-yanaijie@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Vladimir Oltean authored
The arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi device tree lacks DMA channels for DSPI, so naturally, the driver fails to probe: [ 2.945302] fsl-dspi 2100000.spi: rx dma channel not available [ 2.951134] fsl-dspi 2100000.spi: can't get dma channels In retrospect, this should have been obvious, because LS2080A, LS2085A LS2088A and LX2160A don't appear to have an eDMA module at all. Looking again at their datasheets, the CTARE register (which is specific to XSPI functionality) seems to be documented, so switch them to XSPI mode instead. Fixes: 0feaf8f5 ("spi: spi-fsl-dspi: Convert the instantiations that support it to DMA") Reported-by: Qiang Zhao <qiang.zhao@nxp.com> Tested-by: Qiang Zhao <qiang.zhao@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200910121532.1138596-1-olteanv@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>
-
Douglas Anderson authored
We always toggle the chip select manually in spi-geni-qcom so that we can properly implement the Linux API. There's no reason to program this to the hardware on every transfer. Program it once at init and be done with it. This saves some part of a microsecond of overhead on each transfer. While not really noticeable on any real world benchmarks, we might as well save the time. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200912140730.2.I33e571179986850b4ec17042e813d0b08fb1b9c1@changeidSigned-off-by: Mark Brown <broonie@kernel.org>
-
Douglas Anderson authored
In commit 902481a7 ("spi: spi-geni-qcom: Actually use our FIFO") I explained that the maximum size we could program the FIFO was "mas->tx_fifo_depth - 3" but that I chose "mas->tx_fifo_depth()" because I was worried about decreased bandwidth. Since that time: * All the interconnect patches have landed, making things run at the proper speed. * I've done more measurements. This lets me confirm that there's really no downside of using the FIFO more. Specifically I did "flashrom -p ec -r /tmp/foo.bin" on a Chromebook and averaged over several runs. Before: It took 6.66 seconds and 59669 interrupts fired. After: It took 6.66 seconds and 47992 interrupts fired. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200912140730.1.Ie67fa32009b94702d56232c064f1d89065ee8836@changeidSigned-off-by: Mark Brown <broonie@kernel.org>
-