Skip to content
  1. Mar 27, 2019
    • Christoph Muellner's avatar
      arm64: dts: rockchip: Disable DCMDs on RK3399's eMMC controller. · a3eec13b
      Christoph Muellner authored
      
      
      When using direct commands (DCMDs) on an RK3399, we get spurious
      CQE completion interrupts for the DCMD transaction slot (#31):
      
      [  931.196520] ------------[ cut here ]------------
      [  931.201702] mmc1: cqhci: spurious TCN for tag 31
      [  931.206906] WARNING: CPU: 0 PID: 1433 at /usr/src/kernel/drivers/mmc/host/cqhci.c:725 cqhci_irq+0x2e4/0x490
      [  931.206909] Modules linked in:
      [  931.206918] CPU: 0 PID: 1433 Comm: irq/29-mmc1 Not tainted 4.19.8-rt6-funkadelic #1
      [  931.206920] Hardware name: Theobroma Systems RK3399-Q7 SoM (DT)
      [  931.206924] pstate: 40000005 (nZcv daif -PAN -UAO)
      [  931.206927] pc : cqhci_irq+0x2e4/0x490
      [  931.206931] lr : cqhci_irq+0x2e4/0x490
      [  931.206933] sp : ffff00000e54bc80
      [  931.206934] x29: ffff00000e54bc80 x28: 0000000000000000
      [  931.206939] x27: 0000000000000001 x26: ffff000008f217e8
      [  931.206944] x25: ffff8000f02ef030 x24: ffff0000091417b0
      [  931.206948] x23: ffff0000090aa000 x22: ffff8000f008b000
      [  931.206953] x21: 0000000000000002 x20: 000000000000001f
      [  931.206957] x19: ffff8000f02ef018 x18: ffffffffffffffff
      [  931.206961] x17: 0000000000000000 x16: 0000000000000000
      [  931.206966] x15: ffff0000090aa6c8 x14: 0720072007200720
      [  931.206970] x13: 0720072007200720 x12: 0720072007200720
      [  931.206975] x11: 0720072007200720 x10: 0720072007200720
      [  931.206980] x9 : 0720072007200720 x8 : 0720072007200720
      [  931.206984] x7 : 0720073107330720 x6 : 00000000000005a0
      [  931.206988] x5 : ffff00000860d4b0 x4 : 0000000000000000
      [  931.206993] x3 : 0000000000000001 x2 : 0000000000000001
      [  931.206997] x1 : 1bde3a91b0d4d900 x0 : 0000000000000000
      [  931.207001] Call trace:
      [  931.207005]  cqhci_irq+0x2e4/0x490
      [  931.207009]  sdhci_arasan_cqhci_irq+0x5c/0x90
      [  931.207013]  sdhci_irq+0x98/0x930
      [  931.207019]  irq_forced_thread_fn+0x2c/0xa0
      [  931.207023]  irq_thread+0x114/0x1c0
      [  931.207027]  kthread+0x128/0x130
      [  931.207032]  ret_from_fork+0x10/0x20
      [  931.207035] ---[ end trace 0000000000000002 ]---
      
      The driver shows this message only for the first spurious interrupt
      by using WARN_ONCE(). Changing this to WARN() shows, that this is
      happening quite frequently (up to once a second).
      
      Since the eMMC 5.1 specification, where CQE and CQHCI are specified,
      does not mention that spurious TCN interrupts for DCMDs can be simply
      ignored, we must assume that using this feature is not working reliably.
      
      The current implementation uses DCMD for REQ_OP_FLUSH only, and
      I could not see any performance/power impact when disabling
      this optional feature for RK3399.
      
      Therefore this patch disables DCMDs for RK3399.
      
      Signed-off-by: default avatarChristoph Muellner <christoph.muellner@theobroma-systems.com>
      Signed-off-by: default avatarPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
      Fixes: 84362d79
      
       ("mmc: sdhci-of-arasan: Add CQHCI support for arasan,sdhci-5.1")
      Cc: stable@vger.kernel.org
      [the corresponding code changes are queued for 5.2 so doing that as well]
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      a3eec13b
  2. Mar 18, 2019
  3. Feb 27, 2019
    • Brian Norris's avatar
      arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node · 5364a0b4
      Brian Norris authored
      
      
      Currently, we don't coordinate BT USB activity with our handling of the
      BT out-of-band wake pin, and instead just use gpio-keys. That causes
      problems because we have no way of distinguishing wake activity due to a
      BT device (e.g., mouse) vs. the BT controller (e.g., re-configuring wake
      mask before suspend). This can cause spurious wake events just because
      we, for instance, try to reconfigure the host controller's event mask
      before suspending.
      
      We can avoid these synchronization problems by handling the BT wake pin
      directly in the btusb driver -- for all activity up until BT controller
      suspend(), we simply listen to normal USB activity (e.g., to know the
      difference between device and host activity); once we're really ready to
      suspend the host controller, there should be no more host activity, and
      only *then* do we unmask the GPIO interrupt.
      
      This is already supported by btusb; we just need to describe the wake
      pin in the right node.
      
      We list 2 compatible properties, since both PID/VID pairs show up on
      Scarlet devices, and they're both essentially identical QCA6174A-based
      modules.
      
      Also note that the polarity was wrong before: Qualcomm implemented WAKE
      as active high, not active low. We only got away with this because
      gpio-keys always reconfigured us as bi-directional edge-triggered.
      
      Finally, we have an external pull-up and a level-shifter on this line
      (we didn't notice Qualcomm's polarity in the initial design), so we
      can't do pull-down. Switch to pull-none.
      
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      5364a0b4
  4. Feb 18, 2019
  5. Feb 15, 2019
  6. Feb 03, 2019
  7. Jan 31, 2019
  8. Jan 28, 2019
  9. Jan 17, 2019
    • Robin Murphy's avatar
      arm64: dts: rockchip: 'Fix' nanopi4 uSD card detect · 10f595ee
      Robin Murphy authored
      
      
      For whatever reason, the sdmmc_dectn function isn't working properly
      as-is, and microSD insertion and removal goes unnoticed. Using the pin
      as a GPIO interrupt instead is rather noisy without any debouncing, but
      is good enough to make it useful until someone feels inclined to figure
      out how the vendor kernel/firmware gets the dedicated function to work
      with no obvious difference in the pinmux/GRF configuration. Let's also
      take the opportunity to tweak the node name so that all related pins
      end up grouped together in the compiled DTB.
      
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      10f595ee
    • Robin Murphy's avatar
      arm64: dts: rockchip: Add NanoPC-T4 IR receiver · 95658e21
      Robin Murphy authored
      
      
      In common with most Rockchip reference designs, NanoPC-T4 has a passive
      IR receiver connected to PWM3. In lieu of a specialised driver for
      PWM-based IR pulse measurement, running the pin as a GPIO with the basic
      driver works perfectly well.
      
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      95658e21
    • Robin Murphy's avatar
      arm64: dts: rockchip: Refine nanopi4 differences · c62ffaf5
      Robin Murphy authored
      
      
      The nanopi4 boards differ primarily in their power trees, with the main
      5V and 3.3V rails having very different topologies on the smaller USB-C
      powered boards vs. the 12V-powered T4, as well as minor variation in
      other regulators related to various external connectors.
      
      Additionally, the recovery key is only present on the T4 - ADC_IN1 is
      simply pulled high and not exposed on the other boards - and the lowest
      common denominator for MMC speed is actually HS200 according to the
      vendor DTs.
      
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      c62ffaf5
    • Robin Murphy's avatar
      arm64: dts: rockchip: Add DT for NanoPi M4 · 1a6e7411
      Robin Murphy authored
      
      
      There are a number of subtle differences between the nanopi4 variants,
      and where they disagree, the common DTSI currently follows the details
      of NanoPi M4. In order to improve matters even more, let's add a
      separate DTS for the M4 to which we can start splitting things out
      appropriately. The third variant, NanoPi NEO4, is a lot closer to the M4
      than either is to the larger T4, so arguably could get away with just
      sharing the M4 DT for now (plus I have neither of the smaller boards to
      actually test with).
      
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      1a6e7411
  10. Jan 13, 2019