All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <vinod.koul@intel.com>, <tony@atomide.com>,
	<linux@arm.linux.org.uk>, <grant.likely@linaro.org>,
	<dmaengine@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <robh+dt@kernel.org>,
	<nm@ti.com>
Subject: Re: [PATCH v3 1/7] dmaengine: of_dma: Support for DMA routers
Date: Tue, 31 Mar 2015 19:48:03 +0300	[thread overview]
Message-ID: <551ACFC3.5020003@ti.com> (raw)
In-Reply-To: <201503280244.46961.arnd@arndb.de>

On 03/28/2015 03:44 AM, Arnd Bergmann wrote:
> On Friday 27 March 2015, Peter Ujfalusi wrote:
>> +Required property:
>> +- dma-device:          phandle of the DMA controller. The router is modifying
>> +                       the DMA requests for this controller.
> 
> This property seems rather specific to the case at hand, I would expect that
> one might also see routers like this that are connected to more than one
> dma-device, so maybe make it a list?

Yeah, it is intentional from my part.
In dra7xx family we actually have two DMA controllers: sDMA and eDMA. They
both have identical crossbar up front but you can not choose the DMA request
to be routed to either eDMA or sDMA. They are always routed to both and in the
crossbar you select which signal goes to which DMA request of the given
controller.
At the moment I was not aware of different designs (current and future), but
it might be possible that a design you described might surface at some point.
For sure, the list will complicate things quite a bit it might require
different API and callbacks at the end. I need to think about this how it is
going to work best.

> It might also be better to name this as 'dma-controllers' or 'dma-masters',
> as it is not entirely obvious (without referencing the binding document)
> whether a dma device refers to the slave or the master.

I think the 'dma-masters' sounds much better.

PS: I'm out of office this week so do not expect v4 before mid next week.

-- 
Péter

WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: vinod.koul@intel.com, tony@atomide.com, linux@arm.linux.org.uk,
	grant.likely@linaro.org, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	robh+dt@kernel.org, nm@ti.com
Subject: Re: [PATCH v3 1/7] dmaengine: of_dma: Support for DMA routers
Date: Tue, 31 Mar 2015 19:48:03 +0300	[thread overview]
Message-ID: <551ACFC3.5020003@ti.com> (raw)
In-Reply-To: <201503280244.46961.arnd@arndb.de>

On 03/28/2015 03:44 AM, Arnd Bergmann wrote:
> On Friday 27 March 2015, Peter Ujfalusi wrote:
>> +Required property:
>> +- dma-device:          phandle of the DMA controller. The router is modifying
>> +                       the DMA requests for this controller.
> 
> This property seems rather specific to the case at hand, I would expect that
> one might also see routers like this that are connected to more than one
> dma-device, so maybe make it a list?

Yeah, it is intentional from my part.
In dra7xx family we actually have two DMA controllers: sDMA and eDMA. They
both have identical crossbar up front but you can not choose the DMA request
to be routed to either eDMA or sDMA. They are always routed to both and in the
crossbar you select which signal goes to which DMA request of the given
controller.
At the moment I was not aware of different designs (current and future), but
it might be possible that a design you described might surface at some point.
For sure, the list will complicate things quite a bit it might require
different API and callbacks at the end. I need to think about this how it is
going to work best.

> It might also be better to name this as 'dma-controllers' or 'dma-masters',
> as it is not entirely obvious (without referencing the binding document)
> whether a dma device refers to the slave or the master.

I think the 'dma-masters' sounds much better.

PS: I'm out of office this week so do not expect v4 before mid next week.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: peter.ujfalusi@ti.com (Peter Ujfalusi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/7] dmaengine: of_dma: Support for DMA routers
Date: Tue, 31 Mar 2015 19:48:03 +0300	[thread overview]
Message-ID: <551ACFC3.5020003@ti.com> (raw)
In-Reply-To: <201503280244.46961.arnd@arndb.de>

On 03/28/2015 03:44 AM, Arnd Bergmann wrote:
> On Friday 27 March 2015, Peter Ujfalusi wrote:
>> +Required property:
>> +- dma-device:          phandle of the DMA controller. The router is modifying
>> +                       the DMA requests for this controller.
> 
> This property seems rather specific to the case at hand, I would expect that
> one might also see routers like this that are connected to more than one
> dma-device, so maybe make it a list?

Yeah, it is intentional from my part.
In dra7xx family we actually have two DMA controllers: sDMA and eDMA. They
both have identical crossbar up front but you can not choose the DMA request
to be routed to either eDMA or sDMA. They are always routed to both and in the
crossbar you select which signal goes to which DMA request of the given
controller.
At the moment I was not aware of different designs (current and future), but
it might be possible that a design you described might surface at some point.
For sure, the list will complicate things quite a bit it might require
different API and callbacks at the end. I need to think about this how it is
going to work best.

> It might also be better to name this as 'dma-controllers' or 'dma-masters',
> as it is not entirely obvious (without referencing the binding document)
> whether a dma device refers to the slave or the master.

I think the 'dma-masters' sounds much better.

PS: I'm out of office this week so do not expect v4 before mid next week.

-- 
P?ter

  reply	other threads:[~2015-03-31 16:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-27 12:26 [PATCH v3 0/7] dmaengine/dra7x: DMA router (crossbar support) Peter Ujfalusi
2015-03-27 12:26 ` Peter Ujfalusi
2015-03-27 12:26 ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 1/7] dmaengine: of_dma: Support for DMA routers Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-28  1:44   ` Arnd Bergmann
2015-03-28  1:44     ` Arnd Bergmann
2015-03-31 16:48     ` Peter Ujfalusi [this message]
2015-03-31 16:48       ` Peter Ujfalusi
2015-03-31 16:48       ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 2/7] Documentation: devicetree: dma: Binding documentation for TI DMA crossbar Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 4/7] dmaengine: omap-dma: Use defines for dma channels and request count Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 5/7] dmaengine: omap-dma: Take DMA request number from DT if it is available Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 20:24   ` Russell King - ARM Linux
2015-03-27 20:24     ` Russell King - ARM Linux
2015-03-31 14:47     ` Peter Ujfalusi
2015-03-31 14:47       ` Peter Ujfalusi
2015-03-31 14:47       ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 6/7] dmaengine: omap-dma: Remove mapping between virtual channels and requests Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 20:22   ` Russell King - ARM Linux
2015-03-27 20:22     ` Russell King - ARM Linux
2015-03-31 15:44     ` Peter Ujfalusi
2015-03-31 15:44       ` Peter Ujfalusi
2015-03-31 15:44       ` Peter Ujfalusi
2015-03-27 12:26 ` [PATCH v3 7/7] ARM: DTS: dra7x: Integrate sDMA crossbar Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi
2015-03-27 12:26   ` Peter Ujfalusi

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=551ACFC3.5020003@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nm@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.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 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.