All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Vinod Koul <vinod.koul@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Russell King <linux@armlinux.org.uk>,
	Dan Williams <dan.j.williams@intel.com>,
	"M'boumba Cedric Madianga" <cedric.madianga@gmail.com>,
	Fabrice GASNIER <fabrice.gasnier@st.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Fabien DESSENNE <fabien.dessenne@st.com>,
	Amelie DELAUNAY <amelie.delaunay@st.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver
Date: Wed, 2 Aug 2017 16:28:40 +0200	[thread overview]
Message-ID: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> (raw)
In-Reply-To: <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com>



On 08/02/2017 04:09 PM, Peter Ujfalusi wrote:
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 2017-08-02 16:11, Pierre Yves MORDRET wrote:
>> Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a
>> ChannelId and request line is part of the binding.
> 
> In our case the am335x's eDMA can work with or without the router, we 
> only use the router node if we need none default event for a given DMA 
> request line.
> 
>> Using DMAMUx now the request
>> line is coming from dma_spec forwards to dma-master as well explained by Peter.
>> However ChannelID is now given by dma_get_any_slave_channel instead of bindings.
>> DMAMUX driver has to be aware of this ID to route request line to out DMA
>> channel. This channel id information is carried on until DMAMUX through
>> dmaengine_slave_config with a custom API.
>> Hope it clarifies the need.
> 
> I see, this is not much different then what we face with our dra7 
> devices. In theory we could use direct DMA binding to the DMA controller 
> itself, but some requests would not be reachable, so we always use the 
> router's node for DMA on dra7 family.
> 
> Basically the router would manage the ChannelID and create 
> 'st,stm32-dma' compatible dma_spec (the four parameters).
> Afaik you could have 3 parameters for the router and create a four 
> parameter dma_spec, where the ChannelID is dynamically allocated.

Correct router needs 3 parameters and among those 2 are forwarded though out
dma_spec. But when you say "ChannelID is dynamically allocated" you mean
dma_get_any_slave_channel ? If yes I can use the already existing bindings to
carry the channelID to DMA. No changes need to peripheral...

> But you need to convert all peripherals to use the router's node for the 
> DMA.
> 
> - Péter
> 

Py

WARNING: multiple messages have this Message-ID (diff)
From: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Vinod Koul <vinod.koul@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Amelie DELAUNAY <amelie.delaunay@st.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Russell King <linux@armlinux.org.uk>,
	Fabien DESSENNE <fabien.dessenne@st.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	M'boumba Cedric Madianga <cedric.madianga@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Fabrice GASNIER <fabrice.gasnier@st.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver
Date: Wed, 2 Aug 2017 16:28:40 +0200	[thread overview]
Message-ID: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> (raw)
In-Reply-To: <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com>



On 08/02/2017 04:09 PM, Peter Ujfalusi wrote:
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 2017-08-02 16:11, Pierre Yves MORDRET wrote:
>> Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a
>> ChannelId and request line is part of the binding.
> 
> In our case the am335x's eDMA can work with or without the router, we 
> only use the router node if we need none default event for a given DMA 
> request line.
> 
>> Using DMAMUx now the request
>> line is coming from dma_spec forwards to dma-master as well explained by Peter.
>> However ChannelID is now given by dma_get_any_slave_channel instead of bindings.
>> DMAMUX driver has to be aware of this ID to route request line to out DMA
>> channel. This channel id information is carried on until DMAMUX through
>> dmaengine_slave_config with a custom API.
>> Hope it clarifies the need.
> 
> I see, this is not much different then what we face with our dra7 
> devices. In theory we could use direct DMA binding to the DMA controller 
> itself, but some requests would not be reachable, so we always use the 
> router's node for DMA on dra7 family.
> 
> Basically the router would manage the ChannelID and create 
> 'st,stm32-dma' compatible dma_spec (the four parameters).
> Afaik you could have 3 parameters for the router and create a four 
> parameter dma_spec, where the ChannelID is dynamically allocated.

Correct router needs 3 parameters and among those 2 are forwarded though out
dma_spec. But when you say "ChannelID is dynamically allocated" you mean
dma_get_any_slave_channel ? If yes I can use the already existing bindings to
carry the channelID to DMA. No changes need to peripheral...

> But you need to convert all peripherals to use the router's node for the 
> DMA.
> 
> - Péter
> 

Py

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: pierre-yves.mordret@st.com (Pierre Yves MORDRET)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver
Date: Wed, 2 Aug 2017 16:28:40 +0200	[thread overview]
Message-ID: <0e16a519-3d60-f683-5517-12a520e0e521@st.com> (raw)
In-Reply-To: <47ceba83-1097-072e-bed6-d1964bce7a25@ti.com>



On 08/02/2017 04:09 PM, Peter Ujfalusi wrote:
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 
> On 2017-08-02 16:11, Pierre Yves MORDRET wrote:
>> Our SoC works with or without DMAMUX. Both binding is allowed. Using only DMA a
>> ChannelId and request line is part of the binding.
> 
> In our case the am335x's eDMA can work with or without the router, we 
> only use the router node if we need none default event for a given DMA 
> request line.
> 
>> Using DMAMUx now the request
>> line is coming from dma_spec forwards to dma-master as well explained by Peter.
>> However ChannelID is now given by dma_get_any_slave_channel instead of bindings.
>> DMAMUX driver has to be aware of this ID to route request line to out DMA
>> channel. This channel id information is carried on until DMAMUX through
>> dmaengine_slave_config with a custom API.
>> Hope it clarifies the need.
> 
> I see, this is not much different then what we face with our dra7 
> devices. In theory we could use direct DMA binding to the DMA controller 
> itself, but some requests would not be reachable, so we always use the 
> router's node for DMA on dra7 family.
> 
> Basically the router would manage the ChannelID and create 
> 'st,stm32-dma' compatible dma_spec (the four parameters).
> Afaik you could have 3 parameters for the router and create a four 
> parameter dma_spec, where the ChannelID is dynamically allocated.

Correct router needs 3 parameters and among those 2 are forwarded though out
dma_spec. But when you say "ChannelID is dynamically allocated" you mean
dma_get_any_slave_channel ? If yes I can use the already existing bindings to
carry the channelID to DMA. No changes need to peripheral...

> But you need to convert all peripherals to use the router's node for the 
> DMA.
> 
> - P?ter
> 

Py

  reply	other threads:[~2017-08-02 14:29 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 12:20 [PATCH v3 0/5] Add STM32 DMAMUX support Pierre-Yves MORDRET
2017-07-06 12:20 ` Pierre-Yves MORDRET
2017-07-06 12:20 ` Pierre-Yves MORDRET
2017-07-06 12:20 ` [PATCH v3 1/5] dt-bindings: Document the STM32 DMAMUX bindings Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-10  3:56   ` Rob Herring
2017-07-10  3:56     ` Rob Herring
2017-07-10  3:56     ` Rob Herring
2017-07-06 12:20 ` [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-22  6:51   ` Vinod Koul
2017-07-22  6:51     ` Vinod Koul
2017-07-22  6:51     ` Vinod Koul
2017-07-24 13:55     ` Pierre Yves MORDRET
2017-07-24 13:55       ` Pierre Yves MORDRET
2017-07-24 13:55       ` Pierre Yves MORDRET
2017-07-26  5:29       ` Vinod Koul
2017-07-26  5:29         ` Vinod Koul
2017-07-26  5:29         ` Vinod Koul
2017-07-26  7:38         ` Pierre Yves MORDRET
2017-07-26  7:38           ` Pierre Yves MORDRET
2017-07-26  7:38           ` Pierre Yves MORDRET
2017-07-31 12:31           ` Vinod Koul
2017-07-31 12:31             ` Vinod Koul
2017-07-31 12:31             ` Vinod Koul
2017-08-01  9:32             ` Pierre Yves MORDRET
2017-08-01  9:32               ` Pierre Yves MORDRET
2017-08-01  9:32               ` Pierre Yves MORDRET
2017-08-02  4:55               ` Vinod Koul
2017-08-02  4:55                 ` Vinod Koul
2017-08-02  4:55                 ` Vinod Koul
2017-08-02  9:19                 ` Peter Ujfalusi
2017-08-02  9:19                   ` Peter Ujfalusi
2017-08-02  9:19                   ` Peter Ujfalusi
2017-08-02 13:11                   ` Pierre Yves MORDRET
2017-08-02 13:11                     ` Pierre Yves MORDRET
2017-08-02 13:11                     ` Pierre Yves MORDRET
2017-08-02 14:09                     ` Peter Ujfalusi
2017-08-02 14:09                       ` Peter Ujfalusi
2017-08-02 14:09                       ` Peter Ujfalusi
2017-08-02 14:28                       ` Pierre Yves MORDRET [this message]
2017-08-02 14:28                         ` Pierre Yves MORDRET
2017-08-02 14:28                         ` Pierre Yves MORDRET
2017-08-03  6:42                         ` Peter Ujfalusi
2017-08-03  6:42                           ` Peter Ujfalusi
2017-08-03  6:42                           ` Peter Ujfalusi
2017-08-03  9:00                           ` Pierre Yves MORDRET
2017-08-03  9:00                             ` Pierre Yves MORDRET
2017-08-03  9:00                             ` Pierre Yves MORDRET
2017-08-03  9:48                             ` Peter Ujfalusi
2017-08-03  9:48                               ` Peter Ujfalusi
2017-08-03  9:48                               ` Peter Ujfalusi
2017-08-04 12:50                               ` Pierre Yves MORDRET
2017-08-04 12:50                                 ` Pierre Yves MORDRET
2017-08-04 12:50                                 ` Pierre Yves MORDRET
2017-08-04 14:21                                 ` Peter Ujfalusi
2017-08-04 14:21                                   ` Peter Ujfalusi
2017-08-04 14:21                                   ` Peter Ujfalusi
2017-08-21  9:34                                   ` Pierre Yves MORDRET
2017-08-21  9:34                                     ` Pierre Yves MORDRET
2017-08-21  9:34                                     ` Pierre Yves MORDRET
2017-08-24  5:47                                     ` Peter Ujfalusi
2017-08-24  5:47                                       ` Peter Ujfalusi
2017-08-24  5:47                                       ` Peter Ujfalusi
2017-08-24 13:03                                       ` Pierre Yves MORDRET
2017-08-24 13:03                                         ` Pierre Yves MORDRET
2017-08-24 13:03                                         ` Pierre Yves MORDRET
2017-08-28 11:48                                         ` Peter Ujfalusi
2017-08-28 11:48                                           ` Peter Ujfalusi
2017-08-28 11:48                                           ` Peter Ujfalusi
2017-08-30  8:02                                           ` Pierre Yves MORDRET
2017-08-30  8:02                                             ` Pierre Yves MORDRET
2017-08-30  8:02                                             ` Pierre Yves MORDRET
2017-07-06 12:20 ` [PATCH v3 3/5] dt-bindings: stm32-dma: Add property to handle STM32 DMAMUX Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-10  3:57   ` Rob Herring
2017-07-10  3:57     ` Rob Herring
2017-07-06 12:20 ` [PATCH v3 4/5] dmaengine: stm32-dma: Add support for " Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-06 12:20 ` [PATCH v3 5/5] ARM: configs: stm32: Add DMAMUX support in STM32 defconfig Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-06 12:20   ` Pierre-Yves MORDRET
2017-07-20  9:42 ` [PATCH v3 0/5] Add STM32 DMAMUX support Pierre Yves MORDRET
2017-07-20  9:42   ` Pierre Yves MORDRET
2017-07-20  9:42   ` Pierre Yves MORDRET

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=0e16a519-3d60-f683-5517-12a520e0e521@st.com \
    --to=pierre-yves.mordret@st.com \
    --cc=alexandre.torgue@st.com \
    --cc=amelie.delaunay@st.com \
    --cc=cedric.madianga@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=fabien.dessenne@st.com \
    --cc=fabrice.gasnier@st.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.