All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sricharan R <r.sricharan@ti.com>
To: Rob Herring <robherring2@gmail.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	dmaengine@vger.kernel.org, Nishanth Menon <nm@ti.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Tony Lindgren <tony@atomide.com>,
	rnayak@ti.com, Sekhar Nori <nsekhar@ti.com>,
	Vinod Koul <vinod.koul@intel.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [RFC PATCH 0/9] drivers: dma: Add support for dma-channel router
Date: Mon, 10 Mar 2014 19:28:55 +0530	[thread overview]
Message-ID: <531DC51F.50309@ti.com> (raw)
In-Reply-To: <CAL_JsqLF6Ey1t1BV4tnFcFK-KmOU9H2nQE+ZHoZRq2r_nRTxNw@mail.gmail.com>

Hi Rob,

On Sunday 09 March 2014 01:23 AM, Rob Herring wrote:
> On Fri, Mar 7, 2014 at 6:16 AM, Sricharan R <r.sricharan@ti.com> wrote:
>> In some SoCs the dma request lines from the peripherals are
>> routed to the dma-controller through a crossbar. With this the
>> dma controller's available request lines are shared between the
>> peripherals.
>>
>> This adds support to register the crossbar router associated with
>> a dma-channel and let the dma-controller driver map/unmap
>> the peripheral dma crossbar line to dma-controller's request
>> line.
> This is not a unique concept and should follow some existing pattern.
> Perhaps something like interrupt-map. For the dmas property, the
> parent should be the crossbar and then the crossbar block has to
> translate that into the DMA controller request. All the DMA ctrlr
> request connections should be described in the crossbar node. In
> theory, you could have chained crossbars. This should be documented as
> part of the generic DMA binding.
  The idea here was to do the map/unmap crossbar<->dma-request
 from the  dma-controller at runtime just like any other resource, unlike
  interrupt-map fixed in DTS. I did not think about the chained
  crossbars case. I will add this here. And as you have suggested will
  make it work like irq_parse_and_map.

Regards,
 Sricharan
> There are also other similar IP like CoreSight CTI which are just
> signal routers. So there is probably some possibility of common code
> here.
>
> Rob


WARNING: multiple messages have this Message-ID (diff)
From: r.sricharan@ti.com (Sricharan R)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/9] drivers: dma: Add support for dma-channel router
Date: Mon, 10 Mar 2014 19:28:55 +0530	[thread overview]
Message-ID: <531DC51F.50309@ti.com> (raw)
In-Reply-To: <CAL_JsqLF6Ey1t1BV4tnFcFK-KmOU9H2nQE+ZHoZRq2r_nRTxNw@mail.gmail.com>

Hi Rob,

On Sunday 09 March 2014 01:23 AM, Rob Herring wrote:
> On Fri, Mar 7, 2014 at 6:16 AM, Sricharan R <r.sricharan@ti.com> wrote:
>> In some SoCs the dma request lines from the peripherals are
>> routed to the dma-controller through a crossbar. With this the
>> dma controller's available request lines are shared between the
>> peripherals.
>>
>> This adds support to register the crossbar router associated with
>> a dma-channel and let the dma-controller driver map/unmap
>> the peripheral dma crossbar line to dma-controller's request
>> line.
> This is not a unique concept and should follow some existing pattern.
> Perhaps something like interrupt-map. For the dmas property, the
> parent should be the crossbar and then the crossbar block has to
> translate that into the DMA controller request. All the DMA ctrlr
> request connections should be described in the crossbar node. In
> theory, you could have chained crossbars. This should be documented as
> part of the generic DMA binding.
  The idea here was to do the map/unmap crossbar<->dma-request
 from the  dma-controller at runtime just like any other resource, unlike
  interrupt-map fixed in DTS. I did not think about the chained
  crossbars case. I will add this here. And as you have suggested will
  make it work like irq_parse_and_map.

Regards,
 Sricharan
> There are also other similar IP like CoreSight CTI which are just
> signal routers. So there is probably some possibility of common code
> here.
>
> Rob

WARNING: multiple messages have this Message-ID (diff)
From: Sricharan R <r.sricharan@ti.com>
To: Rob Herring <robherring2@gmail.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	<dmaengine@vger.kernel.org>, Nishanth Menon <nm@ti.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Tony Lindgren <tony@atomide.com>, <rnayak@ti.com>,
	Sekhar Nori <nsekhar@ti.com>, Vinod Koul <vinod.koul@intel.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Dan Williams <dan.j.williams@intel.com>
Subject: Re: [RFC PATCH 0/9] drivers: dma: Add support for dma-channel router
Date: Mon, 10 Mar 2014 19:28:55 +0530	[thread overview]
Message-ID: <531DC51F.50309@ti.com> (raw)
In-Reply-To: <CAL_JsqLF6Ey1t1BV4tnFcFK-KmOU9H2nQE+ZHoZRq2r_nRTxNw@mail.gmail.com>

Hi Rob,

On Sunday 09 March 2014 01:23 AM, Rob Herring wrote:
> On Fri, Mar 7, 2014 at 6:16 AM, Sricharan R <r.sricharan@ti.com> wrote:
>> In some SoCs the dma request lines from the peripherals are
>> routed to the dma-controller through a crossbar. With this the
>> dma controller's available request lines are shared between the
>> peripherals.
>>
>> This adds support to register the crossbar router associated with
>> a dma-channel and let the dma-controller driver map/unmap
>> the peripheral dma crossbar line to dma-controller's request
>> line.
> This is not a unique concept and should follow some existing pattern.
> Perhaps something like interrupt-map. For the dmas property, the
> parent should be the crossbar and then the crossbar block has to
> translate that into the DMA controller request. All the DMA ctrlr
> request connections should be described in the crossbar node. In
> theory, you could have chained crossbars. This should be documented as
> part of the generic DMA binding.
  The idea here was to do the map/unmap crossbar<->dma-request
 from the  dma-controller at runtime just like any other resource, unlike
  interrupt-map fixed in DTS. I did not think about the chained
  crossbars case. I will add this here. And as you have suggested will
  make it work like irq_parse_and_map.

Regards,
 Sricharan
> There are also other similar IP like CoreSight CTI which are just
> signal routers. So there is probably some possibility of common code
> here.
>
> Rob


  reply	other threads:[~2014-03-10 13:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-07 12:16 [RFC PATCH 0/9] drivers: dma: Add support for dma-channel router Sricharan R
2014-03-07 12:16 ` Sricharan R
2014-03-07 12:16 ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 1/9] drivers: dma: omap-dma: Avoid hard-coding of the dma-request channels Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 2/9] drivers: dma: of-dma: Add support for dma-request line routers Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 3/9] drivers: dma: omap-dma: Add a seperate xlate function to get router data Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 4/9] drivers: omap-dma: Add crossbar line as a resource to omap_chan structure Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 5/9] drivers: dma: Add dma crossbar driver Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 6/9] arm: dts: dra: Add dma crossbar node Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 7/9] arm: dts: dra: Add dma-request crossbar phandle to dma-specs Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 8/9] arm: dra: Enable dma crossbar support on dra7xx Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16 ` [RFC PATCH 9/9] arm: dts: dra7: Change the total dma-req numbers to crossbar channels Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-07 12:16   ` Sricharan R
2014-03-08 19:53 ` [RFC PATCH 0/9] drivers: dma: Add support for dma-channel router Rob Herring
2014-03-08 19:53   ` Rob Herring
2014-03-08 19:53   ` Rob Herring
2014-03-10 13:58   ` Sricharan R [this message]
2014-03-10 13:58     ` Sricharan R
2014-03-10 13:58     ` Sricharan R

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=531DC51F.50309@ti.com \
    --to=r.sricharan@ti.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=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=rnayak@ti.com \
    --cc=robherring2@gmail.com \
    --cc=santosh.shilimkar@ti.com \
    --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.