Skip to content

L
linux
Switch branch/tag
  1. 10 Feb, 2023 5 commits
    • William Zhang's avatar
      spi: bcm63xx-hsspi: Add prepend mode support · b7a82103
      William Zhang authored 
      Due to the controller limitation to keep the chip select low during the
bus idle time between the transfer, a dummy cs workaround was used when
this driver was first upstreamed to the kernel.  It basically picks the
dummy cs as !actual_cs so typically dummy cs is 1 when most of the case
only cs 0 is used in the board design. Then invert the polarity of both
cs and tell the controller to start the transfers using dummy cs.
Assuming both cs are active low before the inversion, effectively this
keeps dummy cs high and actual cs low during the transfer and workaround
the issue.

This workaround implies that dummy cs 1 pin has to be set to chip
selection function in the pinmux when the transfer clock is above
25MHz. The old chips likely have default pinmux set to chip select on
the dummy cs pin so it works but this is not case for the new Broadband
BCA chips and this workaround stop working. This is specifically an
issue to support SPI NAND and SPI NOR flash because these flash devices
can typically run at or above 100MHz.

This patch utilizes the prepend feature of the controller to combine the
multiple transfers in the same message to a single transfer when
possible. This way there is no need to keep clock low between transfers
and solve the issue without any hardware requirement.

Multiple transfers within a SPI message may be combined into one
transfer if the following are all true:
  * One or more half duplex write transfer in single bit mode
  * Optional full duplex read/write at the end
  * No delay and cs_change between transfers

Most of the SPI device meets this requirements such as SPI NOR,
SPI NAND flash, Broadcom SPI voice card and etc. For any SPI message
that does not meet the above requirement to combine the transfers, we
switch to original dummy cs mode but limit the clock rate to the safe
25MHz. This is the default auto transfer mode and it makes sure all the
SPI message can be supported automatically under the hood.

This patch also adds the driver sysfs node xfer_mode to provide
the option for overriding the default auto mode and force it to dummy cs
or prepend mode.
Signed-off-by: default avatarWilliam Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20230209200246.141520-12-william.zhang@broadcom.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      b7a82103
    • William Zhang's avatar
      spi: bcm63xx-hsspi: Fix multi-bit mode setting · 811ff802
      William Zhang authored 
      Currently the driver always sets the controller to dual data bit mode
for both tx and rx data in the profile mode control register even for
single data bit transfer. Luckily the opcode is set correctly according
to SPI transfer data bit width so it does not actually cause issues.

This change fixes the problem by setting tx and rx data bit mode field
correctly according to the actual SPI transfer tx and rx data bit width.

Fixes: 142168eb ("spi: bcm63xx-hsspi: add bcm63xx HSSPI driver")
Signed-off-by: default avatarWilliam Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20230209200246.141520-11-william.zhang@broadcom.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      811ff802
    • William Zhang's avatar
      spi: bcm63xx-hsspi: Handle cs_change correctly · c00d5e93
      William Zhang authored 
      The kernel SPI interface includes the cs_change flag that alters how
the CS behaves.

If we're in the middle of transfers, it tells us to unselect the
CS momentarily since the target device requires that.

If we're at the end of a transfer, it tells us to keep the CS
selected, perhaps because the next transfer is likely targeted
to the same device.

We implement this scheme in the HSSPI driver in this change.

Prior to this change, the CS would toggle momentarily if cs_change
was set for the last transfer. This can be ignored by some or
most devices, but the Microchip TPM2 device does not ignore it.

With the change, the behavior is corrected and the 'glitch' is
eliminated.
Signed-off-by: default avatarKursad Oney <kursad.oney@broadcom.com>
Signed-off-by: default avatarWilliam Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20230209200246.141520-10-william.zhang@broadcom.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c00d5e93
    • William Zhang's avatar
      spi: export spi_transfer_cs_change_delay_exec function · 6e80133a
      William Zhang authored 
      For SPI controller that implements transfer_one_message, it needs to
insert the delay that required by cs change event between the transfers.
Add a wrapper for the local function _spi_transfer_cs_change_delay_exec
and export it for SPI controller driver to use.
Signed-off-by: default avatarWilliam Zhang <william.zhang@broadcom.com>
Link: https://lore.kernel.org/r/20230209200246.141520-9-william.zhang@broadcom.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      6e80133a
    • Mauro Lima's avatar
      spi: intel: Update help text of PCI and Platform drivers · 2ea9b08a
      Mauro Lima authored 
      Modern intel hardware uses controllers that work in hardware
sequencing mode. In this mode, the controller exposes a subset
of operations, like read, write and erase, making it easier
and less error-prone for use.
On the other hand, most of the controllers handled by the
platform driver use software sequencing that exposes the
entire set of operations i.e. exposes the low level SPI-NOR
opcodes to the software for use.
Update PCI and Platform help text with this information.
Signed-off-by: default avatarMauro Lima <mauro.lima@eclypsium.com>
Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20230210164158.211065-1-mauro.lima@eclypsium.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      2ea9b08a
  3. 09 Feb, 2023 11 commits
  5. 07 Feb, 2023 1 commit
  7. 06 Feb, 2023 2 commits
  9. 02 Feb, 2023 2 commits
  11. 01 Feb, 2023 2 commits
  13. 30 Jan, 2023 2 commits
  15. 27 Jan, 2023 3 commits
    • Bartosz Golaszewski's avatar
      spi: spidev: fix a recursive locking error · eede42c9
      Bartosz Golaszewski authored 
      When calling spidev_message() from the one of the ioctl() callbacks, the
spi_lock is already taken. When we then end up calling spidev_sync(), we
get the following splat:

[  214.047619]
[  214.049198] ============================================
[  214.054533] WARNING: possible recursive locking detected
[  214.059858] 6.2.0-rc3-0.0.0-devel+git.97ec4d55 #1 Not tainted
[  214.065969] --------------------------------------------
[  214.071290] spidev_test/1454 is trying to acquire lock:
[  214.076530] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x8e0/0xab8
[  214.084164]
[  214.084164] but task is already holding lock:
[  214.090007] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8
[  214.097537]
[  214.097537] other info that might help us debug this:
[  214.104075]  Possible unsafe locking scenario:
[  214.104075]
[  214.110004]        CPU0
[  214.112461]        ----
[  214.114916]   lock(&spidev->spi_lock);
[  214.118687]   lock(&spidev->spi_lock);
[  214.122457]
[  214.122457]  *** DEADLOCK ***
[  214.122457]
[  214.128386]  May be due to missing lock nesting notation
[  214.128386]
[  214.135183] 2 locks held by spidev_test/1454:
[  214.139553]  #0: c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8
[  214.147524]  #1: c4925e14 (&spidev->buf_lock){+.+.}-{3:3}, at: spidev_ioctl+0x70/0xab8
[  214.155493]
[  214.155493] stack backtrace:
[  214.159861] CPU: 0 PID: 1454 Comm: spidev_test Not tainted 6.2.0-rc3-0.0.0-devel+git.97ec4d55 #1
[  214.169012] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  214.175555]  unwind_backtrace from show_stack+0x10/0x14
[  214.180819]  show_stack from dump_stack_lvl+0x60/0x90
[  214.185900]  dump_stack_lvl from __lock_acquire+0x874/0x2858
[  214.191584]  __lock_acquire from lock_acquire+0xfc/0x378
[  214.196918]  lock_acquire from __mutex_lock+0x9c/0x8a8
[  214.202083]  __mutex_lock from mutex_lock_nested+0x1c/0x24
[  214.207597]  mutex_lock_nested from spidev_ioctl+0x8e0/0xab8
[  214.213284]  spidev_ioctl from sys_ioctl+0x4d0/0xe2c
[  214.218277]  sys_ioctl from ret_fast_syscall+0x0/0x1c
[  214.223351] Exception stack(0xe75cdfa8 to 0xe75cdff0)
[  214.228422] dfa0:                   00000000 00001000 00000003 40206b00 bee266e8 bee266e0
[  214.236617] dfc0: 00000000 00001000 006a71a0 00000036 004c0040 004bfd18 00000000 00000003
[  214.244809] dfe0: 00000036 bee266c8 b6f16dc5 b6e8e5f6

Fix it by introducing an unlocked variant of spidev_sync() and calling it
from spidev_message() while other users who don't check the spidev->spi's
existence keep on using the locking flavor.
Reported-by: default avatarFrancesco Dolcini <francesco@dolcini.it>
Fixes: 1f4d2dd4 ("spi: spidev: fix a race condition when accessing spidev->spi")
Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
Tested-by: default avatarMax Krummenacher <max.krummenacher@toradex.com>
Link: https://lore.kernel.org/r/20230116144149.305560-1-brgl@bgdev.plSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      eede42c9
    • Serge Semin's avatar
      spi: dw: Fix wrong FIFO level setting for long xfers · c63b8fd1
      Serge Semin authored 
      Due to using the u16 type in the min_t() macros the SPI transfer length
will be cast to word before participating in the conditional statement
implied by the macro. Thus if the transfer length is greater than 64KB the
Tx/Rx FIFO threshold level value will be determined by the leftover of the
truncated after the type-case length. In the worst case it will cause the
dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full"
interrupts triggered on each xfer word sent/received to/from the bus.

The problem can be easily fixed by specifying the unsigned int type in the
min_t() macros thus preventing the possible data loss.

Fixes: ea11370f ("spi: dw: get TX level without an additional variable")
Reported-by: default avatarSergey Nazarov <Sergey.Nazarov@baikalelectronics.ru>
Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230113185942.2516-1-Sergey.Semin@baikalelectronics.ruSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c63b8fd1
    • Randy Dunlap's avatar
      spi: correct spelling · 0f6d2cee
      Randy Dunlap authored 
      Correct spelling problems for Documentation/spi/ as reported
by codespell.
Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20230127064005.1558-28-rdunlap@infradead.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      0f6d2cee
  17. 25 Jan, 2023 3 commits
  19. 23 Jan, 2023 5 commits
  21. 20 Jan, 2023 1 commit
  23. 13 Jan, 2023 3 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7