In case if at least one of the requested DMA engine channels doesn't
support the hardware accelerated SG list entries traverse, the DMA driver
will most likely work that around by performing the IRQ-based SG list
entries resubmission. That might and will cause a problem if the DMA Tx
channel is recharged and re-executed before the Rx DMA channel. Due to
non-deterministic IRQ-handler execution latency the DMA Tx channel will
start pushing data to the SPI bus before the Rx DMA channel is even
reinitialized with the next inbound SG list entry. By doing so the DMA
Tx channel will implicitly start filling the DW APB SSI Rx FIFO up, which
while the DMA Rx channel being recharged and re-executed will eventually
be overflown.

In order to solve the problem we have to feed the DMA engine with SG
list entries one-by-one. It shall keep the DW APB SSI Tx and Rx FIFOs
synchronized and prevent the Rx FIFO overflow. Since in general the SPI
tx_sg and rx_sg lists may have different number of entries of different
lengths (though total length should match) we virtually split the
SG-lists to the set of DMA transfers, which length is a minimum of the
ordered SG-entries lengths.

The solution described above is only executed if a full-duplex SPI
transfer is requested and the DMA engine hasn't provided channels with
hardware accelerated SG list traverse capability to handle both SG
lists at once.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200920112322.24585-12-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

In order to use the DMA submission and waiting methods in both generic
DMA-based SPI transfer and one-by-one DMA SG entries transmission
functions, we need to modify the dw_spi_dma_wait() and
dw_spi_dma_submit_tx()/dw_spi_dma_submit_rx() prototypes. So instead of
getting the SPI transfer object as the second argument they must accept
the exact data structure instances they imply to use. Those are the
current transfer length and the SPI bus frequency in case of
dw_spi_dma_wait(), and SG list together with number of list entries in
case of the DMA Tx/Rx submission methods.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-11-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

DW APB SSI DMA driver doesn't use the native SPI core wait API since
commit bdbdf0f0 ("spi: dw: Locally wait for the DMA transfers
completion"). Due to that the driver can now clear the DMAC register
in a single place synchronously with the DMA transactions completion
or failure. After that all the possible code paths are still covered:
1) DMA completion callbacks are executed in case if the corresponding DMA
transactions are finished. When they are, one of them will eventually wake
the SPI messages pump kernel thread and dw_spi_dma_transfer_all() method
will clean the DMAC register as implied by this patch.
2) dma_stop is called when the SPI core detects an error either returned
from the transfer_one() callback or set in the SPI message status field.
Both types of errors will be noticed by the dw_spi_dma_transfer_all()
method.
3) dma_exit is called when either SPI controller driver or the
corresponding device is removed. In any case the SPI core will first
flush the SPI messages pump kernel thread, so any pending or in-fly
SPI transfers will be finished before that.

Due to all of that let's simplify the DW APB SSI DMA driver a bit and
move the DMAC register cleanup to a single place in the
dw_spi_dma_transfer_all() method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-10-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

In order to add an alternative method of DMA-based SPI transfer first we
need to detach the currently available one from the common code. Here we
move the normal DMA-based SPI transfer execution functionality into a
dedicated method. It will be utilized if either the DMA engine supports
an unlimited number SG entries or Tx-only SPI transfer is requested. But
currently just use it for any SPI transfer.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-9-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

It's pointless to pass the Rx and Tx transfers DMA Tx-descriptors, since
they are used in the Tx/Rx submit method only. Instead just return the
submission status from these methods. This alteration will make the code
less complex.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-8-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

We suggest to add the dmaengine_submit() return value test for errors.  It
has been unnecessary while the driver was expected to be utilized in pair
with DW DMAC. But since now the driver can be used with any DMA engine, it
might be useful to track the errors on DMA submissions so not miss them
and get into an unpredictable driver behaviour.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-7-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

Indeed we can freely move the dmaengine_submit() method invocation and the
Tx and Rx busy flag setting into the DMA Tx/Rx prepare methods. Since the
Tx/Rx preparation method is now mainly used for the DMA transfers
submission, here we suggest to rename it to have the _submit_{r,t}x suffix
instead.

By having this alteration applied first we implement another code
preparation before adding the one-by-one DMA SG entries transmission,
second we now have the dma_async_tx_descriptor descriptor used locally
only in the new DMA transfers submission methods (this will be cleaned up
a bit later), third we make the generic transfer method more readable,
where now the functionality of submission, execution and wait procedures
is transparently split up instead of having a preparation, intermixed
submission/execution and wait procedures.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-6-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

Checking rx_buf for being NULL and returning NULL from the Rx-channel
preparation method doesn't let us to distinguish that situation from
errors happening during the Rx SG-list preparation. So it's better to make
sure that the rx_buf not-NULL and full-duplex communication is requested
prior calling the Rx preparation method.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-5-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

Mainly this is a preparation patch before adding one-by-one DMA SG entries
transmission. But logically the Tx and Rx DMA channels setup should be
performed in the dma_setup() callback anyway. So we'll move the DMA slave
channels src/dst burst lengths, address and address width configuration
from the Tx/Rx channels preparation methods to the dedicated functions and
then make sure it's called at the DMA setup stage.

Note we now make sure the return value of the dmaengine_slave_config()
method doesn't indicate an error. It has been unnecessary in case if Dw
DMAC is utilized as a DMA engine, since its device_config() callback
always returns zero (though it might change in future). But since DW APB
SSI driver now supports any DMA back-end we must make sure the DMA device
configuration has been successful before proceeding with further setups.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-4-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

Since commit 46164fde ("spi: dw: Fix Rx-only DMA transfers") if DMA
interface is enabled, then Tx-buffer must be available in each SPI
transfer. It's required since in order to activate the incoming data
reception either DMA or CPU must be pushing data out to the SPI bus.
But the DW APB SSI DMA driver code is still left in state as if Tx-buffer
might be optional, which is no longer true. Let's fix it so an error would
be returned if no Tx-buffer detected and DMA Tx would be always
enabled.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-3-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

Indeed the registers content doesn't get cleared when the SPI controller
is disabled and enabled. Max burst lengths aren't changed since the Rx and
Tx DMA channels are requested on init stage and are kept acquired until
the device is removed. Obviously SPI controller FIFO depth can't be
changed. Due to all of that we can safely move the DMA Transmit and
Receive data level registers initialization to the SPI controller DMA init
stage (when the SPI controller is being probed) instead of doing it for
each SPI transfer when dma_setup is called. This shall speed the DMA-based
SPI transfer initialization up a bit, particularly if the APB bus is
relatively slow.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20200920112322.24585-2-Sergey.Semin@baikalelectronics.ruSigned-off-by: Mark Brown <broonie@kernel.org>

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>

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/

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>