| Message ID | 1444317612-818-2-git-send-email-cedric.madianga@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote: > +Each dmas request consists of 5 cells: > +1. A phandle pointing to the STM32 DMA controller > +2. The channel id > +3. The request line number > +4. A 32bit mask specifying the DMA channel configuration > It's fairly unusual to encode the channel id here, rather than letting the driver pick one. Is that actually required here? Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, 2015-10-08 17:43 GMT+02:00 Arnd Bergmann <arnd@arndb.de>: > On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote: >> +Each dmas request consists of 5 cells: >> +1. A phandle pointing to the STM32 DMA controller >> +2. The channel id >> +3. The request line number >> +4. A 32bit mask specifying the DMA channel configuration >> > > It's fairly unusual to encode the channel id here, rather than > letting the driver pick one. Is that actually required here? Yes it is required as in STM32 platform the channel/request DMA mapping is done by hardware lines. So, if one client wants to use DMA, he has to choose the correct channel/request values according to the DMA mapping of his STM32 platform. > > Arnd BR, Cedric -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 08 October 2015 18:01:23 M'boumba Cedric Madianga wrote: > Hi Arnd, > > 2015-10-08 17:43 GMT+02:00 Arnd Bergmann <arnd@arndb.de>: > > On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote: > >> +Each dmas request consists of 5 cells: > >> +1. A phandle pointing to the STM32 DMA controller > >> +2. The channel id > >> +3. The request line number > >> +4. A 32bit mask specifying the DMA channel configuration > >> > > > > It's fairly unusual to encode the channel id here, rather than > > letting the driver pick one. Is that actually required here? > > Yes it is required as in STM32 platform the channel/request DMA > mapping is done by hardware lines. > So, if one client wants to use DMA, he has to choose the correct > channel/request values according to the DMA mapping of his STM32 > platform. Interesting. So you have seven channels ans seven request lines, with a random but fixed mapping between them? How do you know which channels are available for memory-to-memory transfers? Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-10-08 21:26 GMT+02:00 Arnd Bergmann <arnd@arndb.de>: > On Thursday 08 October 2015 18:01:23 M'boumba Cedric Madianga wrote: >> Hi Arnd, >> >> 2015-10-08 17:43 GMT+02:00 Arnd Bergmann <arnd@arndb.de>: >> > On Thursday 08 October 2015 17:20:09 M'boumba Cedric Madianga wrote: >> >> +Each dmas request consists of 5 cells: >> >> +1. A phandle pointing to the STM32 DMA controller >> >> +2. The channel id >> >> +3. The request line number >> >> +4. A 32bit mask specifying the DMA channel configuration >> >> >> > >> > It's fairly unusual to encode the channel id here, rather than >> > letting the driver pick one. Is that actually required here? >> >> Yes it is required as in STM32 platform the channel/request DMA >> mapping is done by hardware lines. >> So, if one client wants to use DMA, he has to choose the correct >> channel/request values according to the DMA mapping of his STM32 >> platform. > > Interesting. So you have seven channels ans seven request lines, > with a random but fixed mapping between them? We have eight channels and eight request lines with fixed mapping between them Each peripheral has his channel/request combination to access to the DMA controller. > > How do you know which channels are available for memory-to-memory > transfers? For memory-to-memory transfer we don't need any channel/request combination. We look for any available channel in the channel list to execute our transfer. So, as often as possible, we expect that a peripheral release his channel after transfering data. In that way, we always should have at least one channel available for that kind of transfer. > > Arnd BR, Cedric -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 08 October 2015 22:25:50 M'boumba Cedric Madianga wrote: > > > > How do you know which channels are available for memory-to-memory > > transfers? > For memory-to-memory transfer we don't need any channel/request combination. > We look for any available channel in the channel list to execute our transfer. > So, as often as possible, we expect that a peripheral release his > channel after transfering data. > In that way, we always should have at least one channel available for > that kind of transfer. > Ah, got it. So the use of virtual channels in this driver makes MEM2MEM transfers work, but is otherwise not required. Thanks for the clarification. Arnd -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Cedric, On 10/08/2015 05:20 PM, M'boumba Cedric Madianga wrote: > This patch adds documentation of device tree bindings for the STM32 dma > controller. > > Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> > --- > .../devicetree/bindings/dma/stm32-dma.txt | 98 ++++++++++++++++++++++ > 1 file changed, 98 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt > Acked-by: Maxime Coquelin <maxime.coquelin@st.com> Thanks! Maxime -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/dma/stm32-dma.txt b/Documentation/devicetree/bindings/dma/stm32-dma.txt new file mode 100644 index 0000000..9ce0d49 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/stm32-dma.txt @@ -0,0 +1,98 @@ +* STMicroelectronics STM32 DMA controller + +The STM32 DMA is a general-purpose direct memory access controller capable of +supporting 8 independent DMA channels. Each channel can have up to 8 requests. + +Required properties: +- compatible: Should be "st,stm32-dma" +- reg: Should contain DMA registers location and length. This should include + all of the per-channel registers. +- interrupts: Should contain all of the per-channel DMA interrupts. +- clocks: Should contain the input clock of the DMA instance. +- #dma-cells : Must be <4>. See DMA client paragraph for more details. + +Optional properties: +- resets: Reference to a reset controller asserting the DMA controller +- st,mem2mem: boolean; if defined, it indicates that the controller supports + memory-to-memory transfer + +Example: + + dma2: dma-controller@40026400 { + compatible = "st,stm32-dma"; + reg = <0x40026400 0x400>; + interrupts = <56>, + <57>, + <58>, + <59>, + <60>, + <68>, + <69>, + <70>; + clocks = <&clk_hclk>; + #dma-cells = <4>; + st,mem2mem; + resets = <&rcc 150>; + }; + +* DMA client + +Required properties: +- dmas: Comma separated list of dma channel requests +- dma-names: Names of the aforementioned requested channels + +Each dmas request consists of 5 cells: +1. A phandle pointing to the STM32 DMA controller +2. The channel id +3. The request line number +4. A 32bit mask specifying the DMA channel configuration + -bit 1: Direct Mode Error Interrupt + 0x0: disabled + 0x1: enabled + -bit 2: Transfer Error Interrupt + 0x0: disabled + 0x1: enabled + -bit 3: Half Transfer Mode Error Interrupt + 0x0: disabled + 0x1: enabled + -bit 4: Transfer Complete Interrupt + 0x0: disabled + 0x1: enabled + -bit 9: Peripheral Increment Address + 0x0: no address increment between transfers + 0x1: increment address between transfers + -bit 10: Memory Increment Address + 0x0: no address increment between transfers + 0x1: increment address between transfers + -bit 15: Peripheral Increment Offset Size + 0x0: offset size is linked to the peripheral bus width + 0x1: offset size is fixed to 4 (32-bit alignment) + -bit 16-17: Priority level + 0x0: low + 0x1: medium + 0x2: high + 0x3: very high +5. A 32bit mask specifying the DMA FIFO configuration + -bit 0-1: Fifo threshold + 0x0: 1/4 full FIFO + 0x1: 1/2 full FIFO + 0x2: 3/4 full FIFO + 0x3:full FIFO + -bit 2: Direct mode + 0x0: enabled + 0x1: disabled + -bit 7: FIFO Error Interrupt + 0x0: disabled + 0x1: enabled + +Example: + + usart1: serial@40011000 { + compatible = "st,stm32-usart", "st,stm32-uart"; + reg = <0x40011000 0x400>; + interrupts = <37>; + clocks = <&clk_pclk2>; + dmas = <&dma2 2 4 0x20610 0x3>, + <&dma2 7 5 0x20610 0x3>; + dma-names = "rx", "tx"; + };
This patch adds documentation of device tree bindings for the STM32 dma controller. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> --- .../devicetree/bindings/dma/stm32-dma.txt | 98 ++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/stm32-dma.txt