linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: "M'boumba Cedric Madianga" <cedric.madianga@gmail.com>
Cc: vinod.koul@intel.com, mark.rutland@arm.com,
	mcoquelin.stm32@gmail.com, alexandre.torgue@st.com,
	dan.j.williams@intel.com, dmaengine@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings
Date: Mon, 20 Mar 2017 16:52:50 -0500	[thread overview]
Message-ID: <20170320215250.wwhq6lzwe45jmwks@rob-hp-laptop> (raw)
In-Reply-To: <1489417599-31308-2-git-send-email-cedric.madianga@gmail.com>

On Mon, Mar 13, 2017 at 04:06:38PM +0100, M'boumba Cedric Madianga wrote:
> This patch adds documentation of device tree bindings for the STM32 MDMA
> controller.
> 
> Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
> ---
>  .../devicetree/bindings/dma/stm32-mdma.txt         | 94 ++++++++++++++++++++++
>  1 file changed, 94 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/stm32-mdma.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/stm32-mdma.txt b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
> new file mode 100644
> index 0000000..26a930c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/stm32-mdma.txt
> @@ -0,0 +1,94 @@
> +* STMicroelectronics STM32 MDMA controller
> +
> +The STM32 MDMA is a general-purpose direct memory access controller capable of
> +supporting 64 independent DMA channels with 256 HW requests.
> +
> +Required properties:
> +- compatible: Should be "st,stm32-mdma"

Should be more specific.

> +- reg: Should contain MDMA registers location and length. This should include
> +  all of the per-channel registers.
> +- interrupts: Should contain the MDMA interrupt.
> +- clocks: Should contain the input clock of the DMA instance.
> +- resets: Reference to a reset controller asserting the DMA controller.
> +- #dma-cells : Must be <5>. See DMA client paragraph for more details.
> +
> +Optional properties:
> +- dma-channels: Number of DMA channels supported by the controller.
> +- dma-requests: Number of DMA request signals supported by the controller.
> +- st,ahb-addr-masks: Array of u32 mask to list memory devices addressed via
> +  AHB bus.

I don't understand what this is.

> +
> +Example:

Put the 2 examples together.

> +
> +	mdma1: dma@52000000 {
> +		compatible = "st,stm32-mdma";
> +		reg = <0x52000000 0x1000>;
> +		interrupts = <122>;
> +		clocks = <&clk_dummy>;
> +		resets = <&rcc 992>;
> +		#dma-cells = <5>;
> +		dma-channels = <16>;
> +		dma-requests = <32>;
> +		st,ahb-addr-masks = <0x20000000>, <0x00000000>;
> +	};
> +
> +* DMA client
> +
> +DMA clients connected to the STM32 MDMA controller must use the format
> +described in the dma.txt file, using a six-cell specifier for each channel:
> +a phandle to the MDMA controller plus the following five integer cells:
> +
> +1. The request line number
> +2. The priority level
> +	0x00: Low
> +	0x01: Medium
> +	0x10: High
> +	0x11: Very high
> +3. A 32bit mask specifying the DMA channel configuration
> + -bit 0-1: Source increment mode
> +	0x00: Source address pointer is fixed
> +	0x10: Source address pointer is incremented after each data transfer
> +	0x11: Source address pointer is decremented after each data transfer
> + -bit 2-3: Destination increment mode
> +	0x00: Destination address pointer is fixed
> +	0x10: Destination address pointer is incremented after each data
> +	transfer
> +	0x11: Destination address pointer is decremented after each data
> +	transfer
> + -bit 8-9: Source increment offset size
> +	0x00: byte (8bit)
> +	0x01: half-word (16bit)
> +	0x10: word (32bit)
> +	0x11: double-word (64bit)
> + -bit 10-11: Destination increment offset size
> +	0x00: byte (8bit)
> +	0x01: half-word (16bit)
> +	0x10: word (32bit)
> +	0x11: double-word (64bit)
> +-bit 25-18: The number of bytes to be transferred in a single transfer
> +	(min = 1 byte, max = 128 bytes)
> +-bit 29:28: Trigger Mode
> +	0x00: Each MDMA request triggers a buffer transfer (max 128 bytes)
> +	0x01: Each MDMA request triggers a block transfer (max 64K bytes)
> +	0x10: Each MDMA request triggers a repeated block transfer
> +	0x11: Each MDMA request triggers a linked list transfer
> +4. A 32bit value specifying the register to be used to acknowledge the request
> +   if no HW ack signal is used by the MDMA client
> +5. A 32bit mask specifying the value to be written to acknowledge the request
> +   if no HW ack signal is used by the MDMA client
> +
> +Example:
> +
> +	i2c4: i2c@5c002000 {
> +		compatible = "st,stm32f7-i2c";
> +		reg = <0x5c002000 0x400>;
> +		interrupts = <GIC_SPI 95 IRQ_TYPE_NONE>,
> +			     <GIC_SPI 96 IRQ_TYPE_NONE>;
> +		clocks = <&clk_hsi>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		dmas = <&mdma1 36 0x0 0x40008 0x0 0x0>,
> +		       <&mdma1 37 0x0 0x40002 0x0 0x0>;
> +		dma-names = "rx", "tx";
> +		status = "disabled";
> +	};
> -- 
> 1.9.1
> 

  reply	other threads:[~2017-03-20 21:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13 15:06 [PATCH 0/2] Add STM32 MDMA driver M'boumba Cedric Madianga
2017-03-13 15:06 ` [PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings M'boumba Cedric Madianga
2017-03-20 21:52   ` Rob Herring [this message]
2017-03-27 10:06     ` M'boumba Cedric Madianga
2017-03-28 16:26       ` Rob Herring
2017-03-29  8:07         ` M'boumba Cedric Madianga
2017-03-13 15:06 ` [PATCH 2/2] dmaengine: Add STM32 MDMA driver M'boumba Cedric Madianga
2017-04-06  7:08   ` Vinod Koul
2017-04-26 12:35     ` Pierre Yves MORDRET
2017-05-01  6:12       ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170320215250.wwhq6lzwe45jmwks@rob-hp-laptop \
    --to=robh@kernel.org \
    --cc=alexandre.torgue@st.com \
    --cc=cedric.madianga@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).