linux.git/include/linux/spi/spi.h, branch v6.1

Merge tag 'spi-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi

2022-10-05T02:36:53+00:00

Pull spi updates from Mark Brown:
 "With the exception of some refactoring to fix long standing issues
  where we weren't handling cache syncs properly for messages which had
  PIO and DMA transfers going to the same page correctly there has been
  no work on the core this time around, and it's also been quite a quiet
  release for the drivers too:

   - Fix cache syncs for cases where we have DMA and PIO transfers in
     the same message going to the same page

   - Update the fsl_spi driver to use transfer_one() rather than a
     custom transfer function

   - Support for configuring transfer speeds with the AMD SPI controller

   - Support for a second chip select and 64K erase on Intel SPI

   - Support for Microchip coreQSPI, Nuvoton NPCM845, NXP i.MX93, and
     Rockchip RK3128 and RK3588"

* tag 'spi-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (73 commits)
  spi: Ensure that sg_table won't be used after being freed
  spi: spi-gxp: Use devm_platform_ioremap_resource()
  spi: s3c64xx: Fix large transfers with DMA
  spi: Split transfers larger than max size
  spi: Fix cache corruption due to DMA/PIO overlap
  spi: Save current RX and TX DMA devices
  spi: mt65xx: Add dma max segment size declaration
  spi: migrate mt7621 text bindings to YAML
  spi: renesas,sh-msiof: Add r8a779g0 support
  spi: spi-fsl-qspi: Use devm_platform_ioremap_resource_byname()
  spi: spi-fsl-lpspi: Use devm_platform_get_and_ioremap_resource()
  spi: spi-fsl-dspi: Use devm_platform_get_and_ioremap_resource()
  spi/omap100k:Fix PM disable depth imbalance in omap1_spi100k_probe
  spi: dw: Fix PM disable depth imbalance in dw_spi_bt1_probe
  spi: cadence-quadspi: Fix PM disable depth imbalance in cqspi_probe
  spi: s3c24xx: Switch to use devm_spi_alloc_master()
  spi: xilinx: Switch to use devm_spi_alloc_master()
  spi: img-spfi: using pm_runtime_resume_and_get instead of pm_runtime_get_sync
  spi: aspeed: Remove redundant dev_err call
  spi: spi-mpc52xx: switch to using gpiod API
  ...

spi: Save current RX and TX DMA devices

2022-09-28T11:54:04+00:00

Save the current RX and TX DMA devices to avoid having to duplicate the
logic to pick them, since we'll need access to them in some more
functions to fix a bug in the cache handling.

Signed-off-by: Vincent Whitchurch 
Link: https://lore.kernel.org/r/20220927112117.77599-2-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown

spi: Group cs_change and cs_off flags together in struct spi_transfer

2022-09-08T14:25:23+00:00

The commit 5e0531f6b90a ("spi: Add capability to perform some transfer
with chipselect off") added a new flag but squeezed it into a wrong
group of struct spi_transfer members (note that SPI_NBITS_* are macros
for easier interpretation of the tx_nbits and rx_nbits bitfields).

Group cs_change and cs_off flags together and their doc strings.

Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20220908130518.32186-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown

spi: Add capability to perform some transfer with chipselect off

2022-09-07T14:18:48+00:00

Some components require a few clock cycles with chipselect off before
or/and after the data transfer done with CS on.

Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK
should have one cycle before CS goes low, and two cycles after
CS goes high".

The cycles "before" are implicitely provided by all previous activity
on the SPI bus. But the cycles "after" must be provided in order to
terminate the SPI transfer.

In order to use that kind of component, add a cs_off flag to
spi_transfer struct. When this flag is set, the transfer is performed
with chipselect off. This allows consummer to add a dummy transfer
at the end of the transfer list which is performed with chipselect
OFF, providing the required additional clock cycles.

Signed-off-by: Christophe Leroy 
Link: https://lore.kernel.org/r/434165c46f06d802690208a11e7ea2500e8da4c7.1662558898.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown

spi: mux: Fix mux interaction with fast path optimisations

2022-09-02T12:27:13+00:00

The spi-mux driver is rather too clever and attempts to resubmit any
message that is submitted to it to the parent controller with some
adjusted callbacks.  This does not play at all nicely with the fast
path which now sets flags on the message indicating that it's being
handled through the fast path, we see async messages flagged as being on
the fast path.  Ideally the spi-mux code would duplicate the message but
that's rather invasive and a bit fragile in that it relies on the mux
knowing which fields in the message to copy.  Instead teach the core
that there are controllers which can't cope with the fast path and have
the mux flag itself as being such a controller, ensuring that messages
going via the mux don't get partially handled via the fast path.

This will reduce the performance of any spi-mux connected device since
we'll now always use the thread for both the actual controller and the
mux controller instead of just the actual controller but given that we
were always hitting the slow path anyway it's hopefully not too much of
an additional cost and it allows us to keep the fast path.

Fixes: ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync")
Reported-by: Casper Andersson 
Tested-by: Casper Andersson 
Signed-off-by: Mark Brown 
Link: https://lore.kernel.org/r/20220901120732.49245-1-broonie@kernel.org
Signed-off-by: Mark Brown

spi: spi.c: Fix comment style

2022-06-30T12:40:35+00:00

Capitalize first word in comment where appropriate and add
parentheses to function names.

Reported-by: Andy Shevchenko 
Signed-off-by: David Jander 
Link: https://lore.kernel.org/r/20220629142519.3985486-3-david@protonic.nl
Signed-off-by: Mark Brown

spi: opportunistically skip ctlr->cur_msg_completion

2022-06-27T12:27:26+00:00

There are only a few drivers that do not call
spi_finalize_current_message() in the context of transfer_one_message(),
and even for those cases the completion ctlr->cur_msg_completion is not
needed always. The calls to complete() and wait_for_completion() each
take a spin-lock, which is costly. This patch makes it possible to avoid
those calls in the big majority of cases, by introducing two flags that
with the help of ordering via barriers can avoid using the completion
safely. In case of a race with the context calling
spi_finalize_current_message(), the scheme errs on the safe side and takes
the completion.
The impact of this patch is worth the effort: On a i.MX8MM SoC, the time
the SPI bus is idle between two consecutive calls to spi_sync(), is
reduced from 19.6us to 16.8us... roughly 15%.

Signed-off-by: David Jander 
Link: https://lore.kernel.org/r/20220621061234.3626638-12-david@protonic.nl
Signed-off-by: Mark Brown

spi: Ensure the io_mutex is held until spi_finalize_current_message()

2022-06-27T12:27:25+00:00

This patch introduces a completion that is completed in
spi_finalize_current_message() and waited for in
__spi_pump_transfer_message(). This way all manipulation of ctlr->cur_msg
is done with the io_mutex held and strictly ordered:
__spi_pump_transfer_message() will not return until
spi_finalize_current_message() is done using ctlr->cur_msg, and its
calling context is only touching ctlr->cur_msg after returning.
Due to this, we can safely drop the spin-locks around ctlr->cur_msg.

Signed-off-by: David Jander 
Link: https://lore.kernel.org/r/20220621061234.3626638-11-david@protonic.nl
Signed-off-by: Mark Brown

spi: Remove the now unused ctlr->idling flag

2022-06-27T12:27:22+00:00

The ctlr->idling flag is never checked now, so we don't need to set it
either.

Signed-off-by: David Jander 
Link: https://lore.kernel.org/r/20220621061234.3626638-8-david@protonic.nl
Signed-off-by: Mark Brown

spi: Don't use the message queue if possible in spi_sync

2022-06-27T12:27:17+00:00

The interaction with the controller message queue and its corresponding
auxiliary flags and variables requires the use of the queue_lock which is
costly. Since spi_sync will transfer the complete message anyway, and not
return until it is finished, there is no need to put the message into the
queue if the queue is empty. This can save a lot of overhead.

As an example of how significant this is, when using the MCP2518FD SPI CAN
controller on a i.MX8MM SoC, the time during which the interrupt line
stays active (during 3 relatively short spi_sync messages), is reduced
from 98us to 72us by this patch.

Signed-off-by: David Jander 
Link: https://lore.kernel.org/r/20220621061234.3626638-3-david@protonic.nl
Signed-off-by: Mark Brown