1. 15 Oct, 2019 12 commits
  2. 09 Oct, 2019 2 commits
  3. 08 Oct, 2019 3 commits
    • Mark Brown's avatar
    • Frieder Schrempf's avatar
      spi: spi-fsl-qspi: Clear TDH bits in FLSHCR register · f6910679
      Frieder Schrempf authored
      Later versions of the QSPI controller (e.g. in i.MX6UL/ULL and i.MX7)
      seem to have an additional TDH setting in the FLSHCR register, that
      needs to be set in accordance with the access mode that is used (DDR
      or SDR).
      
      Previous bootstages such as BootROM or bootloader might have used the
      DDR mode to access the flash. As we currently only use SDR mode, we
      need to make sure the TDH bits are cleared upon initialization.
      
      Fixes: 84d04318 ("spi: Add a driver for the Freescale/NXP QuadSPI controller")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFrieder Schrempf <frieder.schrempf@kontron.de>
      Acked-by: default avatarHan Xu <han.xu@nxp.com>
      Link: https://lore.kernel.org/r/20191007071933.26786-1-frieder.schrempf@kontron.deSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      f6910679
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Always use the TCFQ devices in poll mode · 5d2af8bc
      Vladimir Oltean authored
      With this patch, the "interrupts" property from the device tree bindings
      is ignored, even if present, if the driver runs in TCFQ mode.
      
      Switching to using the DSPI in poll mode has several distinct
      benefits:
      
      - With interrupts, the DSPI driver in TCFQ mode raises an IRQ after each
        transmitted word. There is more time wasted for the "waitq" event than
        for actual I/O. And the DSPI IRQ count can easily get the largest in
        /proc/interrupts on Freescale boards with attached SPI devices.
      
      - The SPI I/O time is both lower, and more consistently so. Attached to
        some Freescale devices are either PTP switches, or SPI RTCs. For
        reading time off of a SPI slave device, it is important that all SPI
        transfers take a deterministic time to complete.
      
      - In poll mode there is much less time spent by the CPU in hardirq
        context, which helps with the response latency of the system, and at
        the same time there is more control over when interrupts must be
        disabled (to get a precise timestamp measurement): win-win.
      
      On the LS1021A-TSN board, where the SPI device is a SJA1105 PTP switch
      (with a bits_per_word=8 driver), I created a "benchmark" where I read
      its PTP time once per second, for 120 seconds. Each "read PTP time" is a
      12-byte SPI transfer. I then recorded the time before putting the first
      byte in the TX FIFO, and the time after reading the last byte from the
      RX FIFO. That is the transfer delay in nanoseconds.
      
      Interrupt mode:
      
        delay: min 125120 max 168320 mean 150286 std dev 17675.3
      
      Poll mode:
      
        delay: min 69440 max 119040 mean 70312.9 std dev 8065.34
      
      Both the mean latency and the standard deviation are more than 50% lower
      in poll mode than in interrupt mode. This is with an 'ondemand' governor
      on an otherwise idle system - therefore running mostly at 600 MHz out of
      a max of 1200 MHz.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20190905010114.26718-5-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5d2af8bc
  4. 07 Oct, 2019 3 commits
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Implement the PTP system timestamping for TCFQ mode · d6b71dfa
      Vladimir Oltean authored
      In this mode, the DSPI controller uses PIO to transfer word by word. In
      comparison, in EOQ mode the 4-word deep FIFO is being used, hence the
      current logic will need some adaptation for which I do not have the
      hardware (Coldfire) to test. It is not clear what is the timing of DMA
      transfers and whether timestamping in the driver brings any overall
      performance increase compared to regular timestamping done in the core.
      
      Short phc2sys summary after 58 minutes of running on LS1021A-TSN with
      interrupts disabled during the critical section:
      
        offset: min -26251 max 16416 mean -21.8672 std dev 863.416
        delay: min 4720 max 57280 mean 5182.49 std dev 1607.19
        lost servo lock 3 times
      
      Summary of the same phc2sys service running for 120 minutes with
      interrupts disabled:
      
        offset: min -378 max 381 mean -0.0083089 std dev 101.495
        delay: min 4720 max 5920 mean 5129.38 std dev 154.899
        lost servo lock 0 times
      
      The minimum delay (pre to post time) in nanoseconds is the same, but the
      maximum delay is quite a bit higher, due to interrupts getting sometimes
      executed and interfering with the measurement. Hence set disable_irqs
      whenever possible (aka when the driver runs in poll mode - otherwise it
      would be a contradiction in terms).
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20190905010114.26718-4-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      d6b71dfa
    • Vladimir Oltean's avatar
      spi: Add a PTP system timestamp to the transfer structure · b42faeee
      Vladimir Oltean authored
      SPI is one of the interfaces used to access devices which have a POSIX
      clock driver (real time clocks, 1588 timers etc). The fact that the SPI
      bus is slow is not what the main problem is, but rather the fact that
      drivers don't take a constant amount of time in transferring data over
      SPI. When there is a high delay in the readout of time, there will be
      uncertainty in the value that has been read out of the peripheral.
      When that delay is constant, the uncertainty can at least be
      approximated with a certain accuracy which is fine more often than not.
      
      Timing jitter occurs all over in the kernel code, and is mainly caused
      by having to let go of the CPU for various reasons such as preemption,
      servicing interrupts, going to sleep, etc. Another major reason is CPU
      dynamic frequency scaling.
      
      It turns out that the problem of retrieving time from a SPI peripheral
      with high accuracy can be solved by the use of "PTP system
      timestamping" - a mechanism to correlate the time when the device has
      snapshotted its internal time counter with the Linux system time at that
      same moment. This is sufficient for having a precise time measurement -
      it is not necessary for the whole SPI transfer to be transmitted "as
      fast as possible", or "as low-jitter as possible". The system has to be
      low-jitter for a very short amount of time to be effective.
      
      This patch introduces a PTP system timestamping mechanism in struct
      spi_transfer. This is to be used by SPI device drivers when they need to
      know the exact time at which the underlying device's time was
      snapshotted. More often than not, SPI peripherals have a very exact
      timing for when their SPI-to-interconnect bridge issues a transaction
      for snapshotting and reading the time register, and that will be
      dependent on when the SPI-to-interconnect bridge figures out that this
      is what it should do, aka as soon as it sees byte N of the SPI transfer.
      Since spi_device drivers are the ones who'd know best how the peripheral
      behaves in this regard, expose a mechanism in spi_transfer which allows
      them to specify which word (or word range) from the transfer should be
      timestamped.
      
      Add a default implementation of the PTP system timestamping in the SPI
      core. This is not going to be satisfactory performance-wise, but should
      at least increase the likelihood that SPI device drivers will use PTP
      system timestamping in the future.
      There are 3 entry points from the core towards the SPI controller
      drivers:
      
      - transfer_one: The driver is passed individual spi_transfers to
        execute. This is the easiest to timestamp.
      
      - transfer_one_message: The core passes the driver an entire spi_message
        (a potential batch of spi_transfers). The core puts the same pre and
        post timestamp to all transfers within a message. This is not ideal,
        but nothing better can be done by default anyway, since the core has
        no insight into how the driver batches the transfers.
      
      - transfer: Like transfer_one_message, but for unqueued drivers (i.e.
        the driver implements its own queue scheduling).
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20190905010114.26718-3-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      b42faeee
    • Stephen Boyd's avatar
      spi: gpio: Look for a device node instead of match · 62217f8b
      Stephen Boyd authored
      This driver doesn't do anything with the match for the device node. The
      logic is the same as looking to see if a device node exists or not
      because this driver wouldn't probe unless there is a device node match
      when the device is created from DT. Just test for the presence of the
      device node to simplify and avoid referencing a potentially undefined
      match table when CONFIG_OF=n.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: <linux-spi@vger.kernel.org>
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Link: https://lore.kernel.org/r/20191004214334.149976-9-swboyd@chromium.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      62217f8b
  5. 04 Oct, 2019 1 commit
    • Patrice Chotard's avatar
      spi: stm32-qspi: Fix kernel oops when unbinding driver · 3c0af1dd
      Patrice Chotard authored
      spi_master_put() must only be called in .probe() in case of error.
      
      As devm_spi_register_master() is used during probe, spi_master_put()
      mustn't be called in .remove() callback.
      
      It fixes the following kernel WARNING/Oops when executing
      echo "58003000.spi" > /sys/bus/platform/drivers/stm32-qspi/unbind :
      
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4
      kernfs: can not remove 'uevent', no directory
      Modules linked in:
      CPU: 1 PID: 496 Comm: sh Not tainted 5.3.0-rc1-00219-ga0e07bb51a37 #62
      Hardware name: STM32 (Device Tree Support)
      [<c0111570>] (unwind_backtrace) from [<c010d384>] (show_stack+0x10/0x14)
      [<c010d384>] (show_stack) from [<c08db558>] (dump_stack+0xb4/0xc8)
      [<c08db558>] (dump_stack) from [<c01209d8>] (__warn.part.3+0xbc/0xd8)
      [<c01209d8>] (__warn.part.3) from [<c0120a5c>] (warn_slowpath_fmt+0x68/0x8c)
      [<c0120a5c>] (warn_slowpath_fmt) from [<c02e5844>] (kernfs_remove_by_name_ns+0x9c/0xa4)
      [<c02e5844>] (kernfs_remove_by_name_ns) from [<c05833a4>] (device_del+0x128/0x358)
      [<c05833a4>] (device_del) from [<c05835f8>] (device_unregister+0x24/0x64)
      [<c05835f8>] (device_unregister) from [<c0638dac>] (spi_unregister_controller+0x88/0xe8)
      [<c0638dac>] (spi_unregister_controller) from [<c058c580>] (release_nodes+0x1bc/0x200)
      [<c058c580>] (release_nodes) from [<c0588a44>] (device_release_driver_internal+0xec/0x1ac)
      [<c0588a44>] (device_release_driver_internal) from [<c0586840>] (unbind_store+0x60/0xd4)
      [<c0586840>] (unbind_store) from [<c02e64e8>] (kernfs_fop_write+0xe8/0x1c4)
      [<c02e64e8>] (kernfs_fop_write) from [<c0266b44>] (__vfs_write+0x2c/0x1c0)
      [<c0266b44>] (__vfs_write) from [<c02694c0>] (vfs_write+0xa4/0x184)
      [<c02694c0>] (vfs_write) from [<c0269710>] (ksys_write+0x58/0xd0)
      [<c0269710>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
      Exception stack(0xdd289fa8 to 0xdd289ff0)
      9fa0:                   0000006c 000e20e8 00000001 000e20e8 0000000d 00000000
      9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000
      9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6
      ---[ end trace 1b15df8a02d76aef ]---
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4
      kernfs: can not remove 'online', no directory
      Modules linked in:
      CPU: 1 PID: 496 Comm: sh Tainted: G        W         5.3.0-rc1-00219-ga0e07bb51a37 #62
      Hardware name: STM32 (Device Tree Support)
      [<c0111570>] (unwind_backtrace) from [<c010d384>] (show_stack+0x10/0x14)
      [<c010d384>] (show_stack) from [<c08db558>] (dump_stack+0xb4/0xc8)
      [<c08db558>] (dump_stack) from [<c01209d8>] (__warn.part.3+0xbc/0xd8)
      [<c01209d8>] (__warn.part.3) from [<c0120a5c>] (warn_slowpath_fmt+0x68/0x8c)
      [<c0120a5c>] (warn_slowpath_fmt) from [<c02e5844>] (kernfs_remove_by_name_ns+0x9c/0xa4)
      [<c02e5844>] (kernfs_remove_by_name_ns) from [<c0582488>] (device_remove_attrs+0x20/0x5c)
      [<c0582488>] (device_remove_attrs) from [<c05833b0>] (device_del+0x134/0x358)
      [<c05833b0>] (device_del) from [<c05835f8>] (device_unregister+0x24/0x64)
      [<c05835f8>] (device_unregister) from [<c0638dac>] (spi_unregister_controller+0x88/0xe8)
      [<c0638dac>] (spi_unregister_controller) from [<c058c580>] (release_nodes+0x1bc/0x200)
      [<c058c580>] (release_nodes) from [<c0588a44>] (device_release_driver_internal+0xec/0x1ac)
      [<c0588a44>] (device_release_driver_internal) from [<c0586840>] (unbind_store+0x60/0xd4)
      [<c0586840>] (unbind_store) from [<c02e64e8>] (kernfs_fop_write+0xe8/0x1c4)
      [<c02e64e8>] (kernfs_fop_write) from [<c0266b44>] (__vfs_write+0x2c/0x1c0)
      [<c0266b44>] (__vfs_write) from [<c02694c0>] (vfs_write+0xa4/0x184)
      [<c02694c0>] (vfs_write) from [<c0269710>] (ksys_write+0x58/0xd0)
      [<c0269710>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54)
      Exception stack(0xdd289fa8 to 0xdd289ff0)
      9fa0:                   0000006c 000e20e8 00000001 000e20e8 0000000d 00000000
      9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000
      9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6
      ---[ end trace 1b15df8a02d76af0 ]---
      8<--- cut here ---
      Unable to handle kernel NULL pointer dereference at virtual address 00000050
      pgd = e612f14d
      [00000050] *pgd=ff1f5835
      Internal error: Oops: 17 [#1] SMP ARM
      Modules linked in:
      CPU: 1 PID: 496 Comm: sh Tainted: G        W         5.3.0-rc1-00219-ga0e07bb51a37 #62
      Hardware name: STM32 (Device Tree Support)
      PC is at kernfs_find_ns+0x8/0xfc
      LR is at kernfs_find_and_get_ns+0x30/0x48
      pc : [<c02e49a4>]    lr : [<c02e4ac8>]    psr: 40010013
      sp : dd289dac  ip : 00000000  fp : 00000000
      r10: 00000000  r9 : def6ec58  r8 : dd289e54
      r7 : 00000000  r6 : c0abb234  r5 : 00000000  r4 : c0d26a30
      r3 : ddab5080  r2 : 00000000  r1 : c0abb234  r0 : 00000000
      Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: dd11c06a  DAC: 00000051
      Process sh (pid: 496, stack limit = 0xe13a592d)
      Stack: (0xdd289dac to 0xdd28a000)
      9da0:                            c0d26a30 00000000 c0abb234 00000000 c02e4ac8
      9dc0: 00000000 c0976b44 def6ec00 dea53810 dd289e54 c02e864c c0a61a48 c0a4a5ec
      9de0: c0d630a8 def6ec00 c0d04c48 c02e86e0 def6ec00 de909338 c0d04c48 c05833b0
      9e00: 00000000 c0638144 dd289e54 def59900 00000000 475b3ee5 def6ec00 00000000
      9e20: def6ec00 def59b80 dd289e54 def59900 00000000 c05835f8 def6ec00 c0638dac
      9e40: 0000000a dea53810 c0d04c48 c058c580 dea53810 def59500 def59b80 475b3ee5
      9e60: ddc63e00 dea53810 dea3fe10 c0d63a0c dea53810 ddc63e00 dd289f78 dd240d10
      9e80: 00000000 c0588a44 c0d59a20 0000000d c0d63a0c c0586840 0000000d dd240d00
      9ea0: 00000000 00000000 ddc63e00 c02e64e8 00000000 00000000 c0d04c48 dd9bbcc0
      9ec0: c02e6400 dd289f78 00000000 000e20e8 0000000d c0266b44 00000055 00000cc0
      9ee0: 000000e3 000e3000 dd11c000 dd11c000 00000000 00000000 00000000 00000000
      9f00: ffeee38c dff99688 00000000 475b3ee5 00000001 dd289fb0 ddab5080 ddaa5800
      9f20: 00000817 000e30ec dd9e7720 475b3ee5 ddaa583c 0000000d dd9bbcc0 000e20e8
      9f40: dd289f78 00000000 000e20e8 0000000d 00000000 c02694c0 00000000 00000000
      9f60: c0d04c48 dd9bbcc0 00000000 00000000 dd9bbcc0 c0269710 00000000 00000000
      9f80: 000a91f4 475b3ee5 0000006c 000e20e8 b6f87da0 00000004 c0101204 dd288000
      9fa0: 00000004 c0101000 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000
      9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000
      9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 600e0030 00000001 00000000 00000000
      [<c02e49a4>] (kernfs_find_ns) from [<def6ec00>] (0xdef6ec00)
      Code: ebf8eeab c0dc50b8 e92d40f0 e292c000 (e1d035b0)
      ---[ end trace 1b15df8a02d76af1 ]---
      
      Fixes: a88eceb1 ("spi: stm32-qspi: add spi_master_put in release function")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPatrice Chotard <patrice.chotard@st.com>
      Link: https://lore.kernel.org/r/20191004123606.17241-1-patrice.chotard@st.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      3c0af1dd
  6. 02 Oct, 2019 1 commit
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Always use the TCFQ devices in poll mode · 3c0f9d8b
      Vladimir Oltean authored
      With this patch, the "interrupts" property from the device tree bindings
      is ignored, even if present, if the driver runs in TCFQ mode.
      
      Switching to using the DSPI in poll mode has several distinct
      benefits:
      
      - With interrupts, the DSPI driver in TCFQ mode raises an IRQ after each
        transmitted word. There is more time wasted for the "waitq" event than
        for actual I/O. And the DSPI IRQ count can easily get the largest in
        /proc/interrupts on Freescale boards with attached SPI devices.
      
      - The SPI I/O time is both lower, and more consistently so. Attached to
        some Freescale devices are either PTP switches, or SPI RTCs. For
        reading time off of a SPI slave device, it is important that all SPI
        transfers take a deterministic time to complete.
      
      - In poll mode there is much less time spent by the CPU in hardirq
        context, which helps with the response latency of the system, and at
        the same time there is more control over when interrupts must be
        disabled (to get a precise timestamp measurement, which will come in a
        future patch): win-win.
      
      On the LS1021A-TSN board, where the SPI device is a SJA1105 PTP switch
      (with a bits_per_word=8 driver), I created a "benchmark" where I
      periodically transferred a 12-byte message once per second, for 120
      seconds. I then recorded the time before putting the first byte in the
      TX FIFO, and the time after reading the last byte from the RX FIFO. That
      is the transfer delay in nanoseconds.
      
      Interrupt mode:
      
        delay: min 125120 max 168320 mean 150286 std dev 17675.3
      
      Poll mode:
      
        delay: min 69440 max 119040 mean 70312.9 std dev 8065.34
      
      Both the mean latency and the standard deviation are more than 50% lower
      in poll mode than in interrupt mode, and the 'max' in poll mode is lower
      than the 'min' in interrupt mode. This is with an 'ondemand' governor on
      an otherwise idle system - therefore running mostly at 600 MHz out of a
      max of 1200 MHz.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Link: https://lore.kernel.org/r/20191001205216.32115-1-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      3c0f9d8b
  7. 01 Oct, 2019 18 commits