kernel/drivers/dma/sh, branch linux-5.1.y

dmaengine: sh: rcar-dmac: Fix glitch in dmaengine_tx_status

2019-04-23T05:15:34Z

The tx_status poll in the rcar_dmac driver reads the status register which indicates which chunk is busy (DMACHCRB). Afterwards the point inside the chunk is read from DMATCRB. It is possible that the chunk has changed between the two reads. The result is a non-monotonous increase of the residue. Fix this by introducing a 'safe read' logic. Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue") Signed-off-by: Achim Dahlhoff Signed-off-by: Dirk Behme Reviewed-by: Yoshihiro Shimoda Cc: # v4.16+ Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: With cyclic DMA residue 0 is valid

2019-04-23T05:15:26Z

Having a cyclic DMA, a residue 0 is not an indication of a completed DMA. In case of cyclic DMA make sure that dma_set_residue() is called and with this a residue of 0 is forwarded correctly to the caller. Fixes: 3544d2878817 ("dmaengine: rcar-dmac: use result of updated get_residue in tx_status") Signed-off-by: Dirk Behme Signed-off-by: Achim Dahlhoff Signed-off-by: Hiroyuki Yokoyama Signed-off-by: Yao Lihua Reviewed-by: Yoshihiro Shimoda Reviewed-by: Laurent Pinchart Cc: # v4.8+ Signed-off-by: Vinod Koul

dmaengine: usb-dmac: Make DMAC system sleep callbacks explicit

2019-01-20T10:59:52Z

This commit fixes the issue that USB-DMAC hangs silently after system resumes on R-Car Gen3 hence renesas_usbhs will not work correctly when using USB-DMAC for bulk transfer e.g. ethernet or serial gadgets. The issue can be reproduced by these steps: 1. modprobe g_serial 2. Suspend and resume system. 3. connect a usb cable to host side 4. Transfer data from Host to Target 5. cat /dev/ttyGS0 (Target side) 6. echo "test" > /dev/ttyACM0 (Host side) The 'cat' will not result anything. However, system still can work normally. Currently, USB-DMAC driver does not have system sleep callbacks hence this driver relies on the PM core to force runtime suspend/resume to suspend and reinitialize USB-DMAC during system resume. After the commit 17218e0092f8 ("PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume()"), PM core will not force runtime suspend/resume anymore so this issue happens. To solve this, make system suspend resume explicit by using pm_runtime_force_{suspend,resume}() as the system sleep callbacks. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is used to make sure USB-DMAC suspended after and initialized before renesas_usbhs." Signed-off-by: Phuong Nguyen Signed-off-by: Hiroyuki Yokoyama Cc: # v4.16+ [shimoda: revise the commit log and add Cc tag] Signed-off-by: Yoshihiro Shimoda Signed-off-by: Vinod Koul

Merge tag 'iommu-updates-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu

2019-01-01T23:55:29Z

Pull IOMMU updates from Joerg Roedel: - Page table code for AMD IOMMU now supports large pages where smaller page-sizes were mapped before. VFIO had to work around that in the past and I included a patch to remove it (acked by Alex Williamson) - Patches to unmodularize a couple of IOMMU drivers that would never work as modules anyway. - Work to unify the the iommu-related pointers in 'struct device' into one pointer. This work is not finished yet, but will probably be in the next cycle. - NUMA aware allocation in iommu-dma code - Support for r8a774a1 and r8a774c0 in the Renesas IOMMU driver - Scalable mode support for the Intel VT-d driver - PM runtime improvements for the ARM-SMMU driver - Support for the QCOM-SMMUv2 IOMMU hardware from Qualcom - Various smaller fixes and improvements * tag 'iommu-updates-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: (78 commits) iommu: Check for iommu_ops == NULL in iommu_probe_device() ACPI/IORT: Don't call iommu_ops->add_device directly iommu/of: Don't call iommu_ops->add_device directly iommu: Consolitate ->add/remove_device() calls iommu/sysfs: Rename iommu_release_device() dmaengine: sh: rcar-dmac: Use device_iommu_mapped() xhci: Use device_iommu_mapped() powerpc/iommu: Use device_iommu_mapped() ACPI/IORT: Use device_iommu_mapped() iommu/of: Use device_iommu_mapped() driver core: Introduce device_iommu_mapped() function iommu/tegra: Use helper functions to access dev->iommu_fwspec iommu/qcom: Use helper functions to access dev->iommu_fwspec iommu/of: Use helper functions to access dev->iommu_fwspec iommu/mediatek: Use helper functions to access dev->iommu_fwspec iommu/ipmmu-vmsa: Use helper functions to access dev->iommu_fwspec iommu/dma: Use helper functions to access dev->iommu_fwspec iommu/arm-smmu: Use helper functions to access dev->iommu_fwspec ACPI/IORT: Use helper functions to access dev->iommu_fwspec iommu: Introduce wrappers around dev->iommu_fwspec ...

dmaengine: sh: rcar-dmac: Use device_iommu_mapped()

2018-12-17T11:47:49Z

Use Use device_iommu_mapped() to check if the device is already mapped by an IOMMU. Acked-by: Vinod Koul Signed-off-by: Joerg Roedel

dmaengine: sh: Remove R-Mobile APE6 support

2018-12-05T07:31:54Z

Renesas R-Mobile APE6 support is currently unused: - DMA slaves were never enabled in r8a73a4.dtsi, - The driver relies on legacy filter matching and describing all slaves and MID/RIDs in a table, unlike modern DMA engine drivers for similar hardware like rcar-dmac, - The driver doesn't seem to work well. Remove the driver, it can be resurrected from git history when needed. As this was the last user of SH_DMAE_BASE on Renesas ARM SoCs, the sh-dma-engine driver core is now used on SuperH only. Note that the DT bindings are still present, as r8a73a4.dtsi uses them. Signed-off-by: Geert Uytterhoeven Reviewed-by: Ulrich Hecht Reviewed-by: Simon Horman Signed-off-by: Vinod Koul

dmaengine: sh: convert to SPDX identifiers

2018-11-11T09:14:53Z

This patch updates license to use SPDX-License-Identifier instead of verbose license text. Signed-off-by: Kuninori Morimoto Signed-off-by: Vinod Koul

dmaengine: rcar-dmac: set scatter/gather max segment size

2018-10-07T14:34:14Z

Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a device_dma_parameters structure and filling in the max segment size. Signed-off-by: Wolfram Sang Signed-off-by: Vinod Koul

dmaengine: use SPDX identifier for Renesas drivers

2018-08-29T16:28:49Z

Signed-off-by: Wolfram Sang Reviewed-by: Simon Horman Signed-off-by: Vinod Koul

dmaengine: sh: rcar-dmac: Should not stop the DMAC by rcar_dmac_sync_tcr()

2018-07-31T04:27:27Z

rcar_dmac_chan_get_residue() should not stop the DMAC, because the commit 538603c6026c ("dmaengine: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0") had fixed unexpected re-transferring issue. But it had caused the next issue which might stop the cyclic mode transferring. Thus, for example R-Car sound might be stopped suddenly. According to the commit 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue"), the purpose of clearing CHCR.DE bit is flushing buffered data to calculate the exact residue. Such the "exact" residue had been required by sh-sci driver. sh-sci driver is calling dmaengine_pause() to stop transferring, and get "exact" residue. Otherwise, it might receive extra data during getting residue without pausing. In rx_timer_fn() of sh-sci driver: dmaengine_tx_status(); /* For checking roughly */ dmaengine_pause(); dmaengine_tx_status(); /* For getting residue */ dmaengine_terminate_all(); But, unfortunately the rcar-dmac driver didn't support dmaengine_pause() at that time. So, the sh-sci driver cannot get the "exact" residue without stopping the transferring, because rcar-dmac is buffering data inside. Because of these backgrounds, rcar-dmac had been cleared/set CHCR.DE bit in rcar_dmac_chan_get_residue() to synchronizing data and getting "exact" residue. However, rcar-dmac driver has rcar_dmac_chan_pause() now, and clearing CHCR.DE bit in rcar_dmac_chan_get_residue() doesn't need anymore. So, this patch removes the rcar_dmac_sync_tcr(). Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for residue") Signed-off-by: Yoshihiro Shimoda Tested-by: Hiroyuki Yokoyama Reviewed-by: Geert Uytterhoeven Signed-off-by: Vinod Koul