Add Qualcomm BAM dmaengine driver
Subsystems (3)
v3 cover Add Qualcomm BAM dmaengine driver
This patch set introduces the dmaengine driver for the Qualcomm Bus Access Manager (BAM) DMA controller present on MSM 8x74 devices. A number of the on-chip devices have their own BAM DMA controller and use it to move data between system memory and peripherals or between two peripherals.
The initial version of this driver will only support slave DMA operations between system memory and peripherals.
Changes from v2:
- Corrected Kconfig dependencies
- Moved execution environment ID to controller DT binding. The EE is a global setting across all of the channels on the controller.
- Combined header into source file.
- Corrected copyright date.
- Moved channel hardware initialization to occur when channel is used for the first time.
- Converted dma_alloc_coherent to dma_alloc_writecombine
- Removed unecessary reset of channel from the dma terminate_all
- Corrected usage of EE in irq handler and channel configuration functions.
- Changed resource functions inside probe to use correct APIs.
- Removed dma filter function and modified dma_xlate to use dma_get_slave_channel API
- Fixed various nit comments
Changes from v1:
- Converted driver to use virt-dma
- Reworked probe function per review comments
- tx_status function now computes and returns residuals
- Removed proprietary slave config. Removed associated include file.
- Renamed files to reflect vendor name instead of specific device
- Converted to use (readl|writel)_relaxed w/ appropriate barriers
- Removed unions in favor of standard types.
Andy Gross (2):
dmaengine: add Qualcomm BAM dma driver
dmaengine: qcom_bam_dma: Add device tree binding
.../devicetree/bindings/dma/qcom_bam_dma.txt | 52 + drivers/dma/Kconfig | 9 + drivers/dma/Makefile | 1 + drivers/dma/qcom_bam_dma.c | 1083 ++++++++++++++++++++ 4 files changed, 1145 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt create mode 100644 drivers/dma/qcom_bam_dma.c
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
PATCH v3 1/2 dmaengine: add Qualcomm BAM dma driver
Add the DMA engine driver for the QCOM Bus Access Manager (BAM) DMA controller found in the MSM 8x74 platforms.
Each BAM DMA device is associated with a specific on-chip peripheral. Each channel provides a uni-directional data transfer engine that is capable of transferring data between the peripheral and system memory (System mode), or between two peripherals (BAM2BAM).
The initial release of this driver only supports slave transfers between peripherals and system memory.
--- drivers/dma/Kconfig | 9 + drivers/dma/Makefile | 1 + drivers/dma/qcom_bam_dma.c | 1083 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1093 insertions(+) create mode 100644 drivers/dma/qcom_bam_dma.c
drivers/dma/Kconfig +9 -0
@@ -386,4 +386,13 @@ config DMATEST config DMA_ENGINE_RAID bool +config QCOM_BAM_DMA + tristate "QCOM BAM DMA support" + depends on ARCH_MSM_DT || (COMPILE_TEST && OF && ARM) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for the QCOM BAM DMA controller. This controller + provides DMA capabilities for a variety of on-chip devices. + endif
drivers/dma/Makefile +1 -0
@@ -42,3 +42,4 @@ obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o obj-$(CONFIG_TI_CPPI41) += cppi41.o obj-$(CONFIG_K3_DMA) += k3dma.o +obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
drivers/dma/qcom_bam_dma.c new file +1083 -0
1,083 lines not on this page · raw message
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
PATCH v3 2/2 dmaengine: qcom_bam_dma: Add device tree binding
In reply to Andy GrossAdd device tree binding support for the QCOM BAM DMA driver.
--- .../devicetree/bindings/dma/qcom_bam_dma.txt | 52 ++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +52 -0
@@ -0,0 +1,52 @@ +QCOM BAM DMA controller + +Required properties: +- compatible: Must be "qcom,bam-v1.4.0" for MSM8974 V1 + Must be "qcom,bam-v1.4.1" for MSM8974 V2 +- reg: Address range for DMA registers +- interrupts: single interrupt for this controller +- #dma-cells: must be <2> +- clocks: required clock +- clock-names: name of clock +- qcom,ee : indicates the active Execution Environment identifier (0-7) + +Example: + + uart-bam: dma at f9984000 = { + compatible = "qcom,bam-v1.4.1"; + reg = <0xf9984000 0x15000>; + interrupts = <0 94 0>; + clocks = <&gcc GCC_BAM_DMA_AHB_CLK>; + clock-names = "bam_clk"; + #dma-cells = <2>; + qcom,ee = <0>; + }; + +Client: +Required properties: +- dmas: List of dma channel requests +- dma-names: Names of aforementioned requested channels + +Clients must use the format described in the dma.txt file, using a three cell +specifier for each channel. + +The three cells in order are: + 1. A phandle pointing to the DMA controller + 2. The channel number + 3. Direction of the fixed unidirectional channel + 0 - Memory to Device + 1 - Device to Memory + 2 - Device to Device + +Example: + serial at f991e000 { + compatible = "qcom,msm-uart"; + reg = <0xf991e000 0x1000> + <0xf9944000 0x19000>; + interrupts = <0 108 0>; + clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + + dmas = <&uart-bam 0 1>, <&uart-bam 1 0>; + dma-names = "rx", "tx"; + };
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 44 lines · Andy Gross
Add device tree binding support for the QCOM BAM DMA driver.
Signed-off-by Andy Gross <[email protected]>--- .../devicetree/bindings/dma/qcom_bam_dma.txt | 52 ++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txtDocumentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +30
-0@@ -0,0 +1,52 @@ +QCOM BAM DMA controller + +Required properties: +- compatible: Must be "qcom,bam-v1.4.0" for MSM8974 V1 + Must be "qcom,bam-v1.4.1" for MSM8974 V2 +- reg: Address range for DMA registers +- interrupts: single interrupt for this controller +- #dma-cells: must be <2> +- clocks: required clock +- clock-names: name of clock +- qcom,ee : indicates the active Execution Environment identifier (0-7) + +Example: + + uart-bam: dma at f9984000 = { + compatible = "qcom,bam-v1.4.1"; + reg = <0xf9984000 0x15000>; + interrupts = <0 94 0>; + clocks = <&gcc GCC_BAM_DMA_AHB_CLK>; + clock-names = "bam_clk"; + #dma-cells = <2>; + qcom,ee = <0>; + }; + +Client: +Required properties: +- dmas: List of dma channel requests +- dma-names: Names of aforementioned requested channels + +Clients must use the format described in the dma.txt file, using a three cell
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt line 40
Quoted 10 lines
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +10
-0+specifier for each channel. + +The three cells in order are: + 1. A phandle pointing to the DMA controller + 2. The channel number + 3. Direction of the fixed unidirectional channel + 0 - Memory to Device + 1 - Device to Memory + 2 - Device to Device +
Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
- Lars
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 10 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Quoted 10 lines
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +10
-0+ +Clients must use the format described in the dma.txt file, using a three cell +specifier for each channel. + +The three cells in order are: + 1. A phandle pointing to the DMA controller + 2. The channel number + 3. Direction of the fixed unidirectional channel + 0 - Memory to Device + 1 - Device to Memory
Quoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ 2 - Device to Device +Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Normally the direction is implied by dmaengine_slave_config(). Note that neither the dma slave API nor the generic DT binding can actually support device-to-device transfers, since this normally implies using two dma-request lines rather than one.
There might be a case where the direction is required in order to allocate a channel, because the engine has specialized channels per direction, and might connect any of them to any dma request line. This does not seem to be the case for "bam", because the DMA specifier already contains a specific channel number, not a request line or slave ID number.
Arnd
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 8 lines · Arnd Bergmann
Quoted 5 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Normally the direction is implied by
dmaengine_slave_config().
No. The direction argument in there is deprecated - we've been talking about removing it for some time.
DMA engine drivers should store all parameters of the configuration, and then select the appropriate ones when preparing a transfer (which itself involves a direction.)
Not doing this implies that if you have a half-duplex device, you have to repeatedly issue a dmaengine_slave_config() call, a prepare call, and a submit call to the DMA engine code for every segment you want to transfer. We don't need that kind of DMA engine specific behaviour in DMA engine users.
Signature · 3 lines
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 8 lines · Russell King - ARM Linux
Quoted 7 lines · Arnd Bergmann
Quoted 5 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Quoted 8 lines
Quoted 1 line
Normally the direction is implied by
dmaengine_slave_config().No. The direction argument in there is deprecated - we've been talking about removing it for some time.
DMA engine drivers should store all parameters of the configuration, and then select the appropriate ones when preparing a transfer (which itself involves a direction.)
Right all the prep_ calls for slave cases have explcit direction argument so sending it using slave config makes no sense. So will remove it after the merge window closes and fix :)
--
~Vinod
Quoted 15 lines
Not doing this implies that if you have a half-duplex device, you have to repeatedly issue a
dmaengine_slave_config()call, a prepare call, and a submit call to the DMA engine code for every segment you want to transfer. We don't need that kind of DMA engine specific behaviour in DMA engine users.Signature · 7 lines
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 14 lines · On Tuesday 28 January 2014 17:02:42 Vinod Koul wrote:
Quoted 13 lines · Russell King - ARM Linux
Quoted 8 lines · Arnd Bergmann
Quoted 5 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Normally the direction is implied by
dmaengine_slave_config().No. The direction argument in there is deprecated - we've been talking about removing it for some time.
Quoted 7 lines
Quoted 3 lines
DMA engine drivers should store all parameters of the configuration, and then select the appropriate ones when preparing a transfer (which itself involves a direction.)
Right all the
prep_calls for slave cases have explcit direction argument so sending it using slave config makes no sense. So will remove it after the merge window closes and fix
Ok, thanks for clearing up my mistake. However, the argument remains:
the direction doesn't need to be in the DT DMA descriptor since it gets set by software anyway.
Arnd
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 19 lines · On Tuesday 28 January 2014 13:05:10 Arnd Bergmann wrote:
Quoted 18 lines · On Tuesday 28 January 2014 17:02:42 Vinod Koul wrote:
Quoted 16 lines · Russell King - ARM Linux
Quoted 8 lines · Arnd Bergmann
Quoted 5 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Normally the direction is implied by
dmaengine_slave_config().No. The direction argument in there is deprecated - we've been talking about removing it for some time.
DMA engine drivers should store all parameters of the configuration, and then select the appropriate ones when preparing a transfer (which itself involves a direction.)
Quoted 7 lines
Quoted 3 lines
Right all the
prep_calls for slave cases have explcit direction argument so sending it using slave config makes no sense. So will remove it after the merge window closes and fixOk, thanks for clearing up my mistake. However, the argument remains:
the direction doesn't need to be in the DT DMA descriptor since it gets set by software anyway.
On a related note, should we try to remove the slave_id field from the slave config structure as well? I believe it is still used by the shmobile dma engine in non-DT mode, but that is inconsistent with how all the others work, and with what the same driver does for DT.
Arnd
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 4 lines · Arnd Bergmann
On a related note, should we try to remove the
slave_idfield from the slave config structure as well? I believe it is still used by the shmobile dma engine in non-DT mode, but that is inconsistent with how all the others work, and with what the same driver does for DT.
I didn't see that appear, but now that it is there, I'm in two minds about it.
The first is that the virtual channel approach is more flexible (one virtual channel per DMA request line) since it allows users to hold on to a DMA engine virtual channel and don't have the overhead of getting that. It also means that they have access to the DMA engine struct device, which should be used with the DMA API for mapping/unmapping etc.
Another advantage is that it is possible (though we don't really do this at present) to schedule a number of virtual channels onto the underlying physical channels according to whatever algorithm(s) we decide.
The second point is that requesting a physical channel and then configuring it seems more elegant from the DMA engine point of view - but has the down-side that clients have to release the DMA engine channel (and thus forget the struct device) as soon as possible to avoid starving the system of physical DMA channels.
On balance, I think the virtual channel approach makes client drivers more elegant and simpler, and makes the DMA engine API easier to use, and gives greater flexibility for future improvements. So, I wouldn't miss the slave_id being removed.
Signature · 3 lines
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
Quoted 6 lines · On Tuesday 28 January 2014 12:16:56 Russell King - ARM Linux wrote:
On Tue, Jan 28, 2014 at 01:08:47PM +0100, Arnd Bergmann wrote:
On balance, I think the virtual channel approach makes client drivers more elegant and simpler, and makes the DMA engine API easier to use, and gives greater flexibility for future improvements. So, I wouldn't miss the
slave_idbeing removed.
Ok, good. There are some dmaengine drivers that actually behave in hardware like the virtual-channel extension, i.e. they have one physical channel per request line (qcom_bam_dma seems to be one of them in fact), so they don't really have a choice.
The way that both the DT and ACPI bindings are structured, the request ID is always known by the time the channel is allocated to allow this model, and that means supporting both approaches in the same master or slave driver is a mess.
Arnd
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
In reply to Arnd BergmannQuoted 3 lines · Arnd Bergmann
Ok, thanks for clearing up my mistake. However, the argument remains:
the direction doesn't need to be in the DT DMA descriptor since it gets set by software anyway.
Yes - for full-duplex, it's implied, since you have one DMA request (and therefore virtual channel) for memory-to-device and another for device-to-memory.
Signature · 3 lines
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
In reply to Arnd BergmannQuoted 25 lines · Arnd Bergmann
Quoted 10 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Quoted 10 lines
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +10
-0+ +Clients must use the format described in the dma.txt file, using a three cell +specifier for each channel. + +The three cells in order are: + 1. A phandle pointing to the DMA controller + 2. The channel number + 3. Direction of the fixed unidirectional channel + 0 - Memory to Device + 1 - Device to MemoryQuoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ 2 - Device to Device +Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Normally the direction is implied by
dmaengine_slave_config(). Note that neither the dma slave API nor the generic DT binding can actually support device-to-device transfers, since this normally implies using two dma-request lines rather than one.
Quoted 7 lines
There might be a case where the direction is required in order to allocate a channel, because the engine has specialized channels per direction, and might connect any of them to any dma request line. This does not seem to be the case for "bam", because the DMA specifier already contains a specific channel number, not a request line or slave ID number.
In the case of BAM, the channels are hardcoded based on the attached peripheral. For instance, if the BAM is attached to the BLSP UART, channel 0 is uart0-RX, channel 1 is uart0-TX, channel 2 is uart1-RX... etc, etc. So not only is the direction hardcoded, but also the function.
Signature · 3 lines
sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
In reply to Arnd BergmannQuoted 25 lines · Arnd Bergmann
Quoted 10 lines · On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
Quoted 10 lines
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +10
-0+ +Clients must use the format described in the dma.txt file, using a three cell +specifier for each channel. + +The three cells in order are: + 1. A phandle pointing to the DMA controller + 2. The channel number + 3. Direction of the fixed unidirectional channel + 0 - Memory to Device + 1 - Device to MemoryQuoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ 2 - Device to Device +Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
Normally the direction is implied by
dmaengine_slave_config(). Note that neither the dma slave API nor the generic DT binding can actually support device-to-device transfers, since this normally implies using two dma-request lines rather than one.
Quoted 6 lines
There might be a case where the direction is required in order to allocate a channel, because the engine has specialized channels per direction, and might connect any of them to any dma request line. This does not seem to be the case for "bam", because the DMA specifier already contains a specific channel number, not a request line or slave ID number.
After some deliberation, I think the best solution is removing the direction from the DT for now. It doesn't add anything except some verification of direction.
As for the device to device:
As I mentioned before, each bam dma node is attached to a specific peripheral (with one exception, but lets skip over that). The peripherals allow for more than one execution environment to access the peripheral and attached bam. 2 bam channels can be connected to form a unidirectional pipe from one execution environment to another. Once the pipe is configured, the actually transfer resembles a cyclical dma transfer and continues until you explicitly stop it.
That functionality will come later.
Signature · 3 lines
sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
In reply to Lars-Peter ClausenQuoted 53 lines · Lars-Peter Clausen
Quoted 52 lines · Andy Gross
Add device tree binding support for the QCOM BAM DMA driver.
Signed-off-by Andy Gross <[email protected]>--- .../devicetree/bindings/dma/qcom_bam_dma.txt | 52 ++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_bam_dma.txtDocumentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +38
-0@@ -0,0 +1,52 @@ +QCOM BAM DMA controller + +Required properties: +- compatible: Must be "qcom,bam-v1.4.0" for MSM8974 V1 + Must be "qcom,bam-v1.4.1" for MSM8974 V2 +- reg: Address range for DMA registers +- interrupts: single interrupt for this controller +- #dma-cells: must be <2> +- clocks: required clock +- clock-names: name of clock +- qcom,ee : indicates the active Execution Environment identifier (0-7) + +Example: + + uart-bam: dma at f9984000 = { + compatible = "qcom,bam-v1.4.1"; + reg = <0xf9984000 0x15000>; + interrupts = <0 94 0>; + clocks = <&gcc GCC_BAM_DMA_AHB_CLK>; + clock-names = "bam_clk"; + #dma-cells = <2>; + qcom,ee = <0>; + }; + +Client: +Required properties: +- dmas: List of dma channel requests +- dma-names: Names of aforementioned requested channels + +Clients must use the format described in the dma.txt file, using a three cell +specifier for each channel. + +The three cells in order are: + 1. A phandle pointing to the DMA controller + 2. The channel number + 3. Direction of the fixed unidirectional channel + 0 - Memory to Device + 1 - Device to Memory
Quoted 9 lines
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt line 40
Quoted 2 lines
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file +2
-0+ 2 - Device to Device +Why does the direction needs to be specified in specifier? I see two options, either the direction per is fixed in hardware. In that case the DMA controller node should describe which channel is which direction. Or the direction is not fixed in hardware and can be changed at runtime in which case it should be set on a per descriptor basis.
It is specified because the direction is physically set by the hardware. And this can change depending on the attached peripheral. It probably does make more sense to set the direction in the controller.
Signature · 3 lines
sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation