Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1242522 > unrolled thread

[PATCH 1/4] dt-bindings: Document the STM32 DMA bindings

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings M'boumba Cedric Madianga <cedric.madianga@gmail.com> - 2015-10-08 17:30 +0200
    Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings Arnd Bergmann <arnd@arndb.de> - 2015-10-08 17:50 +0200
      Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> - 2015-10-08 18:10 +0200
        Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings Arnd Bergmann <arnd@arndb.de> - 2015-10-08 21:30 +0200
          Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings "M'boumba Cedric Madianga" <cedric.madianga@gmail.com> - 2015-10-08 22:30 +0200
            Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings Arnd Bergmann <arnd@arndb.de> - 2015-10-08 22:50 +0200
    Re: [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings Maxime Coquelin <mcoquelin.stm32@gmail.com> - 2015-10-12 21:20 +0200

#1242522 — [PATCH 1/4] dt-bindings: Document the STM32 DMA bindings

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

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";
+	};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1242552

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242573

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242699

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242721

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1242726

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1245040

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web