summaryrefslogtreecommitdiffstats
path: root/drivers/dma/dw-axi-dmac
diff options
context:
space:
mode:
authorStephan Gerhold <stephan@gerhold.net>2021-10-18 12:24:21 +0200
committerVinod Koul <vkoul@kernel.org>2021-10-28 22:42:30 +0530
commit9502ffcda0491c2079e2f6e3278b3c7377fd81fb (patch)
treec9e64f88f585211ad3867ed4477591e52a47cabf /drivers/dma/dw-axi-dmac
parent37aef53f5ccf789a87006e0dcbce187ce3427f63 (diff)
downloadlinux-9502ffcda0491c2079e2f6e3278b3c7377fd81fb.tar.bz2
dmaengine: qcom: bam_dma: Add "powered remotely" mode
In some configurations, the BAM DMA controller is set up by a remote processor and the local processor can simply start making use of it without setting up the BAM. This is already supported using the "qcom,controlled-remotely" property. However, for some reason another possible configuration is that the remote processor is responsible for powering up the BAM, but we are still responsible for initializing it (e.g. resetting it etc). This configuration is quite challenging to handle properly because the power control is handled through separate channels (e.g. device-specific SMSM interrupts / smem-states). Great care must be taken to ensure the BAM registers are not accessed while the BAM is powered off since this results in a bus stall. Attempt to support this configuration with minimal device-specific code in the bam_dma driver by tracking the number of requested channels. Consumers of DMA channels are responsible to only request DMA channels when the BAM was powered on by the remote processor, and to release them before the BAM is powered off. When the first channel is requested the BAM is initialized (reset) and it is also put into reset when the last channel was released. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20211018102421.19848-3-stephan@gerhold.net Signed-off-by: Vinod Koul <vkoul@kernel.org>
Diffstat (limited to 'drivers/dma/dw-axi-dmac')
0 files changed, 0 insertions, 0 deletions