All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Yves MORDRET <pierre-yves.mordret-qxv4g6HH51o@public.gmane.org>
To: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>,
	Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Amelie DELAUNAY <amelie.delaunay-qxv4g6HH51o@public.gmane.org>,
	Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>,
	Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
	Fabien DESSENNE <fabien.dessenne-qxv4g6HH51o@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Maxime Coquelin
	<mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	M'boumba Cedric Madianga
	<cedric.madianga-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Dan Williams
	<dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Fabrice GASNIER <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Herbert Xu
	<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver
Date: Thu, 24 Aug 2017 15:03:30 +0200	[thread overview]
Message-ID: <ea66ba14-fe18-cb83-5989-8ae7b3ab50c6@st.com> (raw)
In-Reply-To: <d1cc3cbb-c4aa-2acc-91ff-1d6713cb8867-l0cyMroinI0@public.gmane.org>



On 08/24/2017 07:47 AM, Peter Ujfalusi wrote:
> 
> 
> On 2017-08-21 12:34, Pierre Yves MORDRET wrote:
>> OK. I will redesign my driver to take into account this idea.
>>
>> I believe I should get rid of my custom API in DMA for channelID as well. Please
>> confirm. Not very clear for me whether I can keep it or not.
> 
> Yes, you should be able to get rid of any custom API.
> The DMA event router should be 'invisible' to both the DMA driver itself
> and for the DMA users as well. If you end up still needing custom API
> (which I doubt) then it is better to extend the core support to cover
> that in a generic way since it is likely that other might have similar
> needs.
> 

Will see that later on :)

> You need to identify what you need to manage with the DMA router, again
> in my cases:
> am335x/am437x: The DMA channel is fixed, but the DMA event to be handled
> by the channel (DMA event muxer) is selected by the router.
> dra7x: The DMA event is the fixed part and I needed to translate that to
> local eDMA/sDMA events and in eDMA I needed to pick a channel based on
> the translated event.
> 
> The same router code works for eDMA and sDMA in dra7, while the two DMA
> engines are different in their internal works.
> 
> At the end of the day I only needed to plug the DMA event routers and
> there is no change in the DMA drivers at all.
> 

Please tell me whether I'm wrong but for am335x/am437x both DMA Channels and
events are given by DT. I believe IP Spec provides the mapping for the channel
(this is what you call fixed channel) and DMA router event is selected randomly
within the DT.
As for dra7 events comes from DT but channel is selected though out local
algorithm. IP Spec defines DMA event muxer mapping.

At my opinion my router is more closed to dra7. IP Spec defines event mapping.
Nonetheless the DMA has a fixed allocated mapping. Using DMA alone DT has to
provide channel number. In router mode this number doesn't matter since router
makes the routing from fixed event to channel. However router needs to know
which channel will be assign to event: any random channel is allowed.

I'm pretty sure I can mimic what has been for DRA7 related to DMA Channel
allocation however it seems to be this is aside DMA engine. This kind of
implementation forbid the use of DMA and DMA router at the same time : I
remember you already raise the point. If a DMA channel is requested DMA router
is not aware of this allocation. This is the idea of my custom API which relies
on get_any_slave_channel().
Using DT to assign channel seems not a good idea either as I lost router's benefice.

BTW I need the channel ID within router.
Looking at core or of_dma_router_xlate() I don't really know how to do it a
generic manner.

Ideas are welcomed

> I'm happy to answer any questions you might have, if I can.
> 

You will be happy then.

> - Péter
> 

Thanks
Py
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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: Thu, 24 Aug 2017 15:03:30 +0200	[thread overview]
Message-ID: <ea66ba14-fe18-cb83-5989-8ae7b3ab50c6@st.com> (raw)
In-Reply-To: <d1cc3cbb-c4aa-2acc-91ff-1d6713cb8867@ti.com>



On 08/24/2017 07:47 AM, Peter Ujfalusi wrote:
> 
> 
> On 2017-08-21 12:34, Pierre Yves MORDRET wrote:
>> OK. I will redesign my driver to take into account this idea.
>>
>> I believe I should get rid of my custom API in DMA for channelID as well. Please
>> confirm. Not very clear for me whether I can keep it or not.
> 
> Yes, you should be able to get rid of any custom API.
> The DMA event router should be 'invisible' to both the DMA driver itself
> and for the DMA users as well. If you end up still needing custom API
> (which I doubt) then it is better to extend the core support to cover
> that in a generic way since it is likely that other might have similar
> needs.
> 

Will see that later on :)

> You need to identify what you need to manage with the DMA router, again
> in my cases:
> am335x/am437x: The DMA channel is fixed, but the DMA event to be handled
> by the channel (DMA event muxer) is selected by the router.
> dra7x: The DMA event is the fixed part and I needed to translate that to
> local eDMA/sDMA events and in eDMA I needed to pick a channel based on
> the translated event.
> 
> The same router code works for eDMA and sDMA in dra7, while the two DMA
> engines are different in their internal works.
> 
> At the end of the day I only needed to plug the DMA event routers and
> there is no change in the DMA drivers at all.
> 

Please tell me whether I'm wrong but for am335x/am437x both DMA Channels and
events are given by DT. I believe IP Spec provides the mapping for the channel
(this is what you call fixed channel) and DMA router event is selected randomly
within the DT.
As for dra7 events comes from DT but channel is selected though out local
algorithm. IP Spec defines DMA event muxer mapping.

At my opinion my router is more closed to dra7. IP Spec defines event mapping.
Nonetheless the DMA has a fixed allocated mapping. Using DMA alone DT has to
provide channel number. In router mode this number doesn't matter since router
makes the routing from fixed event to channel. However router needs to know
which channel will be assign to event: any random channel is allowed.

I'm pretty sure I can mimic what has been for DRA7 related to DMA Channel
allocation however it seems to be this is aside DMA engine. This kind of
implementation forbid the use of DMA and DMA router at the same time : I
remember you already raise the point. If a DMA channel is requested DMA router
is not aware of this allocation. This is the idea of my custom API which relies
on get_any_slave_channel().
Using DT to assign channel seems not a good idea either as I lost router's benefice.

BTW I need the channel ID within router.
Looking at core or of_dma_router_xlate() I don't really know how to do it a
generic manner.

Ideas are welcomed

> I'm happy to answer any questions you might have, if I can.
> 

You will be happy then.

> - Péter
> 

Thanks
Py

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: Thu, 24 Aug 2017 15:03:30 +0200	[thread overview]
Message-ID: <ea66ba14-fe18-cb83-5989-8ae7b3ab50c6@st.com> (raw)
In-Reply-To: <d1cc3cbb-c4aa-2acc-91ff-1d6713cb8867@ti.com>



On 08/24/2017 07:47 AM, Peter Ujfalusi wrote:
> 
> 
> On 2017-08-21 12:34, Pierre Yves MORDRET wrote:
>> OK. I will redesign my driver to take into account this idea.
>>
>> I believe I should get rid of my custom API in DMA for channelID as well. Please
>> confirm. Not very clear for me whether I can keep it or not.
> 
> Yes, you should be able to get rid of any custom API.
> The DMA event router should be 'invisible' to both the DMA driver itself
> and for the DMA users as well. If you end up still needing custom API
> (which I doubt) then it is better to extend the core support to cover
> that in a generic way since it is likely that other might have similar
> needs.
> 

Will see that later on :)

> You need to identify what you need to manage with the DMA router, again
> in my cases:
> am335x/am437x: The DMA channel is fixed, but the DMA event to be handled
> by the channel (DMA event muxer) is selected by the router.
> dra7x: The DMA event is the fixed part and I needed to translate that to
> local eDMA/sDMA events and in eDMA I needed to pick a channel based on
> the translated event.
> 
> The same router code works for eDMA and sDMA in dra7, while the two DMA
> engines are different in their internal works.
> 
> At the end of the day I only needed to plug the DMA event routers and
> there is no change in the DMA drivers at all.
> 

Please tell me whether I'm wrong but for am335x/am437x both DMA Channels and
events are given by DT. I believe IP Spec provides the mapping for the channel
(this is what you call fixed channel) and DMA router event is selected randomly
within the DT.
As for dra7 events comes from DT but channel is selected though out local
algorithm. IP Spec defines DMA event muxer mapping.

At my opinion my router is more closed to dra7. IP Spec defines event mapping.
Nonetheless the DMA has a fixed allocated mapping. Using DMA alone DT has to
provide channel number. In router mode this number doesn't matter since router
makes the routing from fixed event to channel. However router needs to know
which channel will be assign to event: any random channel is allowed.

I'm pretty sure I can mimic what has been for DRA7 related to DMA Channel
allocation however it seems to be this is aside DMA engine. This kind of
implementation forbid the use of DMA and DMA router at the same time : I
remember you already raise the point. If a DMA channel is requested DMA router
is not aware of this allocation. This is the idea of my custom API which relies
on get_any_slave_channel().
Using DT to assign channel seems not a good idea either as I lost router's benefice.

BTW I need the channel ID within router.
Looking at core or of_dma_router_xlate() I don't really know how to do it a
generic manner.

Ideas are welcomed

> I'm happy to answer any questions you might have, if I can.
> 

You will be happy then.

> - P?ter
> 

Thanks
Py

  parent reply	other threads:[~2017-08-24 13:03 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 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
     [not found]   ` <1499343623-5964-3-git-send-email-pierre-yves.mordret-qxv4g6HH51o@public.gmane.org>
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
     [not found]         ` <2b916330-9b65-f4d5-817f-79b66cc236b3-qxv4g6HH51o@public.gmane.org>
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
     [not found]               ` <f2908e38-dc4d-3886-4058-52a7ad845415-qxv4g6HH51o@public.gmane.org>
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
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
     [not found]                                         ` <6e8e19f1-8d0f-183b-e02f-1ec8c4dd57b3-l0cyMroinI0@public.gmane.org>
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
     [not found]                                               ` <d1cc3cbb-c4aa-2acc-91ff-1d6713cb8867-l0cyMroinI0@public.gmane.org>
2017-08-24 13:03                                                 ` Pierre Yves MORDRET [this message]
2017-08-24 13:03                                                   ` Pierre Yves MORDRET
2017-08-24 13:03                                                   ` Pierre Yves MORDRET
     [not found]                                                   ` <ea66ba14-fe18-cb83-5989-8ae7b3ab50c6-qxv4g6HH51o@public.gmane.org>
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
     [not found] ` <1499343623-5964-1-git-send-email-pierre-yves.mordret-qxv4g6HH51o@public.gmane.org>
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
     [not found]     ` <1499343623-5964-2-git-send-email-pierre-yves.mordret-qxv4g6HH51o@public.gmane.org>
2017-07-10  3:56       ` Rob Herring
2017-07-10  3:56         ` Rob Herring
2017-07-10  3:56         ` Rob Herring
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=ea66ba14-fe18-cb83-5989-8ae7b3ab50c6@st.com \
    --to=pierre-yves.mordret-qxv4g6hh51o@public.gmane.org \
    --cc=alexandre.torgue-qxv4g6HH51o@public.gmane.org \
    --cc=amelie.delaunay-qxv4g6HH51o@public.gmane.org \
    --cc=cedric.madianga-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=fabien.dessenne-qxv4g6HH51o@public.gmane.org \
    --cc=fabrice.gasnier-qxv4g6HH51o@public.gmane.org \
    --cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
    --cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=peter.ujfalusi-l0cyMroinI0@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /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.