1. 04 May, 2019 10 commits
    • Sameer Pujar's avatar
      dmaengine: tegra210-adma: restore channel status · f33e7bb3
      Sameer Pujar authored
      Status of ADMA channel registers is not saved and restored during system
      suspend. During active playback if system enters suspend, this results in
      wrong state of channel registers during system resume and playback fails
      to resume properly. Fix this by saving following channel registers in
      runtime suspend and restore during runtime resume.
       * ADMA_CH_LOWER_SRC_ADDR
       * ADMA_CH_LOWER_TRG_ADDR
       * ADMA_CH_FIFO_CTRL
       * ADMA_CH_CONFIG
       * ADMA_CH_CTRL
       * ADMA_CH_CMD
       * ADMA_CH_TC
      Runtime PM calls will be inovked during system resume path if a playback
      or capture needs to be resumed. Hence above changes work fine for system
      suspend case.
      
      Fixes: f46b1957 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      f33e7bb3
    • Sameer Pujar's avatar
      dmaengine: tegra210-dma: free dma controller in remove() · f030e419
      Sameer Pujar authored
      Following kernel panic is seen during DMA driver unload->load sequence
      ==========================================================================
      Unable to handle kernel paging request at virtual address ffffff8001198880
      Internal error: Oops: 86000007 [#1] PREEMPT SMP
      CPU: 0 PID: 5907 Comm: HwBinder:4123_1 Tainted: G C 4.9.128-tegra-g065839f
      Hardware name: galen (DT)
      task: ffffffc3590d1a80 task.stack: ffffffc3d0678000
      PC is at 0xffffff8001198880
      LR is at of_dma_request_slave_channel+0xd8/0x1f8
      pc : [<ffffff8001198880>] lr : [<ffffff8008746f30>] pstate: 60400045
      sp : ffffffc3d067b710
      x29: ffffffc3d067b710 x28: 000000000000002f
      x27: ffffff800949e000 x26: ffffff800949e750
      x25: ffffff800949e000 x24: ffffffbefe817d84
      x23: ffffff8009f77cb0 x22: 0000000000000028
      x21: ffffffc3ffda49c8 x20: 0000000000000029
      x19: 0000000000000001 x18: ffffffffffffffff
      x17: 0000000000000000 x16: ffffff80082b66a0
      x15: ffffff8009e78250 x14: 000000000000000a
      x13: 0000000000000038 x12: 0101010101010101
      x11: 0000000000000030 x10: 0101010101010101
      x9 : fffffffffffffffc x8 : 7f7f7f7f7f7f7f7f
      x7 : 62ff726b6b64622c x6 : 0000000000008064
      x5 : 6400000000000000 x4 : ffffffbefe817c44
      x3 : ffffffc3ffda3e08 x2 : ffffff8001198880
      x1 : ffffffc3d48323c0 x0 : ffffffc3d067b788
      
      Process HwBinder:4123_1 (pid: 5907, stack limit = 0xffffffc3d0678028)
      Call trace:
      [<ffffff8001198880>] 0xffffff8001198880
      [<ffffff80087459f8>] dma_request_chan+0x50/0x1f0
      [<ffffff8008745bc0>] dma_request_slave_channel+0x28/0x40
      [<ffffff8001552c44>] tegra_alt_pcm_open+0x114/0x170
      [<ffffff8008d65fa4>] soc_pcm_open+0x10c/0x878
      [<ffffff8008d18618>] snd_pcm_open_substream+0xc0/0x170
      [<ffffff8008d1878c>] snd_pcm_open+0xc4/0x240
      [<ffffff8008d189e0>] snd_pcm_playback_open+0x58/0x80
      [<ffffff8008cfc6d4>] snd_open+0xb4/0x178
      [<ffffff8008250628>] chrdev_open+0xb8/0x1d0
      [<ffffff8008246fdc>] do_dentry_open+0x214/0x318
      [<ffffff80082485d0>] vfs_open+0x58/0x88
      [<ffffff800825bce0>] do_last+0x450/0xde0
      [<ffffff800825c718>] path_openat+0xa8/0x368
      [<ffffff800825dd84>] do_filp_open+0x8c/0x110
      [<ffffff8008248a74>] do_sys_open+0x164/0x220
      [<ffffff80082b66dc>] compat_SyS_openat+0x3c/0x50
      [<ffffff8008083040>] el0_svc_naked+0x34/0x38
      ---[ end trace 67e6d544e65b5145 ]---
      Kernel panic - not syncing: Fatal exception
      ==========================================================================
      
      In device probe(), of_dma_controller_register() registers DMA controller.
      But when driver is removed, this is not freed. During driver reload this
      results in data abort and kernel panic. Add of_dma_controller_free() in
      driver remove path to fix the issue.
      
      Fixes: f46b1957 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      f030e419
    • Sameer Pujar's avatar
      dmaengine: tegra210-adma: add pause/resume support · 94dc8f4e
      Sameer Pujar authored
      During an audio playback session it is observed that, audio goes off after
      few seconds of continuous pause and play. No audio is heard even when the
      playback is resumed.
      
      The reason for above is, currently ADMA driver does not handle DMA_PAUSE/
      DMA_RESUME and relevant callbacks for dma_device are not implemented. This
      patch implements device_pause and device_resume callbacks for the device.
      During pause TRANSFER_PAUSE bit of dma channel control register is set and
      the same is cleared during resume.
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      94dc8f4e
    • Sameer Pujar's avatar
      dmaengine: tegra210-adma: add support for Tegra186/Tegra194 · 433de642
      Sameer Pujar authored
      Add Tegra186 specific macro defines and chip_data structure for chip
      specific information. New compatibility is added to select relevant
      chip details. There is no major change for Tegra194 and hence it can
      use the same chip data.
      
      The bits in the BURST_SIZE field of the ADMA CH_CONFIG register are
      encoded differently on Tegra186 and Tegra194 compared with Tegra210.
      On Tegra210 the bits are encoded as follows ...
      
       1 = WORD_1
       2 = WORDS_2
       3 = WORDS_4
       4 = WORDS_8
       5 = WORDS_16
      
      Where as on Tegra186 and Tegra194 the bits are encoded as ...
      
       0 = WORD_1
       1 = WORDS_2
       2 = WORDS_3
       3 = WORDS_4
       4 = WORDS_5
       ...
       15 = WORDS_16
      
      Add helper functions for generating the correct burst size.
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      433de642
    • Sameer Pujar's avatar
      Documentation: DT: Add compatibility binding for Tegra186 · c0e74dd2
      Sameer Pujar authored
      Tegra186 Audio DMA controller has new updates from Tegra210 version.
      Thus add new compatibility binding string and the same can be used
      by Tegra194 as well.
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      c0e74dd2
    • Sameer Pujar's avatar
      dmaengine: tegra210-adma: prepare for supporting newer Tegra chips · ded1f3db
      Sameer Pujar authored
      This is a preparatory patch to add support for Tegra186 and Tegra194 chips.
      Following changes are necessary to make driver code generic.
       * chip_data structure is enhanced to have chip specific details and
         following are the additions to the structure
         * Offset addresses for ADMA global and channel registers
         * Offset values for Tx and Rx channel selection
         * Maximum supported Tx and Rx channels
         * Tx and Rx channel request mask
         * ADMA channel register space size
       * Make use of above chip_data to generalise the driver code
      
      Support for Tegra186 and Tegra194 will be added in subsequent patches of
      the series.
      Signed-off-by: default avatarSameer Pujar <spujar@nvidia.com>
      Reviewed-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      ded1f3db
    • Dan Carpenter's avatar
      dmaengine: at_xdmac: remove a stray bottom half unlock · 0b515abb
      Dan Carpenter authored
      We switched this code from spin_lock_bh() to vanilla spin_lock() but
      there was one stray spin_unlock_bh() that was overlooked.  This
      patch converts it to spin_unlock() as well.
      
      Fixes: d8570d01 ("dmaengine: at_xdmac: move spin_lock_bh to spin_lock in tasklet")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      0b515abb
    • Krzysztof Kozlowski's avatar
      dmaengine: fsl-edma: Adjust indentation · e095189a
      Krzysztof Kozlowski authored
      Fix indentation and remove unneeded space after 'return' keyword.  This
      fixes checkpatch warning:
          WARNING: Statements should start on a tabstop
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      e095189a
    • Krzysztof Kozlowski's avatar
      dmaengine: fsl-edma: Fix typo in Vybrid name · 32685552
      Krzysztof Kozlowski authored
      Fix typo in comment for Vybrid SoC family.
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      32685552
    • Arnaud Pouliquen's avatar
      dmaengine: stm32-dma: fix residue calculation in stm32-dma · 2a4885ab
      Arnaud Pouliquen authored
      In double buffer mode, during residue calculation, the DMA can
      automatically switch to the next transfer. Indeed the CT bit that
      gives position in the double buffer can has been updated by the
      hardware, during calculation.
      In this case the SxNDTR register value can not be trusted.
      If a transition is detected we consider that the DMA has switched to
      the beginning of next sg.
      Signed-off-by: default avatarArnaud Pouliquen <arnaud.pouliquen@st.com>
      Signed-off-by: default avatarPierre-Yves MORDRET <pierre-yves.mordret@st.com>
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      2a4885ab
  2. 29 Apr, 2019 3 commits
  3. 26 Apr, 2019 7 commits
  4. 24 Apr, 2019 3 commits
  5. 23 Apr, 2019 3 commits
  6. 25 Mar, 2019 7 commits
  7. 21 Mar, 2019 1 commit
    • Andy Shevchenko's avatar
      dmaengine: idma64: Use actual device for DMA transfers · 5ba846b1
      Andy Shevchenko authored
      Intel IOMMU, when enabled, tries to find the domain of the device,
      assuming it's a PCI one, during DMA operations, such as mapping or
      unmapping. Since we are splitting the actual PCI device to couple of
      children via MFD framework (see drivers/mfd/intel-lpss.c for details),
      the DMA device appears to be a platform one, and thus not an actual one
      that performs DMA. In a such situation IOMMU can't find or allocate
      a proper domain for its operations. As a result, all DMA operations are
      failed.
      
      In order to fix this, supply parent of the platform device
      to the DMA engine framework and fix filter functions accordingly.
      
      We may rely on the fact that parent is a real PCI device, because no
      other configuration is present in the wild.
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
      Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
      5ba846b1
  8. 17 Mar, 2019 6 commits