devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Benoit Cousson <b-cousson@ti.com>
Cc: Rob Herring <rob.herring@calxeda.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Tony Lindgren <tony@atomide.com>,
	Vinod Koul <vinod.koul@intel.com>,
	Russell King <linux@arm.linux.org.uk>,
	device-tree <devicetree-discuss@lists.ozlabs.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Sebastien Guiriec <s-guiriec@ti.com>
Subject: Re: [PATCH V3 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Date: Tue, 12 Mar 2013 16:43:56 -0500	[thread overview]
Message-ID: <513FA19C.60904@ti.com> (raw)
In-Reply-To: <513F0AE3.6030408@ti.com>

Salut Benoit!

On 03/12/2013 06:00 AM, Benoit Cousson wrote:
> + Seb G.
> 
> Hi Jon,
> 
> How to you plan to merge that series?

Good question ... my thinking was that you or Tony would take 1/2 and
once that is queued then I would ask Tony to ack 2/2 and Vinod take that
patch.

By the way, I have accumulated several DT patches which I sent out
altogether [1] (at least for my own sanity if no one elses ;-) and I
have included the below patch with it. I was hoping that may be I could
create a branch for you to pull. If you would rather cherry-pick the
various patches and merge yourself then I can separate them too.

> Seb's just posted a McBSP adaptation to SDMA binding, so I'll have to
> take this one before being able to merge any other SDMA driver
> adaptation patches.
> 
> I'm fine to take that one, if you are OK, to avoid merge conflict in DTS
> later.

Fine with me and that would be preferred. I don't see any downside in
taking this one and then having Vinod take the other later.

> On 02/26/2013 07:27 PM, Jon Hunter wrote:
>> Add SDMA controller binding for OMAP2+ devices and populate DMA client
>> information for SPI and MMC periperhal on OMAP3+ devices. Please note
> 
> typo-------------------------------^

Thanks! Will fix.

>> that OMAP24xx devices do not have SPI and MMC bindings available yet and
>> so DMA client information is not populated.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> Reviewed-by: Felipe Balbi <balbi@ti.com>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>>  .../devicetree/bindings/dma/omap-sdma.txt          |   51 ++++++++++++++++++++
> 
> That's a detail, but the bindings should be introduced along with the
> driver DT adaptation since it does represent its "interface".

Ok, I can add that to patch 2/2 instead.

>>  arch/arm/boot/dts/omap2.dtsi                       |   12 +++++
>>  arch/arm/boot/dts/omap3.dtsi                       |   40 +++++++++++++++
>>  arch/arm/boot/dts/omap4.dtsi                       |   41 ++++++++++++++++
>>  arch/arm/boot/dts/omap5.dtsi                       |   41 ++++++++++++++++
>>  5 files changed, 185 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt b/Documentation/devicetree/bindings/dma/omap-sdma.txt
>> new file mode 100644
>> index 0000000..22aab28
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
>> @@ -0,0 +1,51 @@
>> +* TI OMAP SDMA controller
>> +
>> +Required properties:
>> +- compatible:		Should be set to one of the following:
>> +
>> +			ti,omap2420-sdma (omap2420)
>> +			ti,omap2430-sdma (omap2430)
>> +			ti,omap3430-sdma (omap3430)
>> +			ti,omap3630-sdma (omap3630)
>> +			ti,omap4430-sdma (omap4430 & omap4460 & omap543x)
>> +
>> +- reg: 			Contains DMA registers location and length.
>> +- interrupts: 		Contains DMA interrupt information.
>> +- #dma-cells: 		Must be 1.
>> +- #dma-channels:	Contains total number of programmable DMA channels.
>> +- #dma-requests:	Contains total number of DMA requests.
>> +
>> +Example:
>> +
>> +	sdma: dma-controller@4A056000 {
>> +		compatible = "ti,omap-sdma";
>> +		reg = <0x4A056000 0x1000>;
> 
> 
> Nit: you do have several hexa values in upper case, here and in some dts
> as well.

Yes will fix that too.

Cheers
Jon

[1]
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg28050.html


  reply	other threads:[~2013-03-12 21:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26 18:27 [PATCH V3 0/2] ARM: dts: Add DT bindings for OMAP SDMA Jon Hunter
2013-02-26 18:27 ` [PATCH V3 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes Jon Hunter
2013-03-12 11:00   ` Benoit Cousson
2013-03-12 21:43     ` Jon Hunter [this message]
2013-03-13 15:35       ` Benoit Cousson
2013-03-13 15:50         ` Jon Hunter
2013-03-13 16:11           ` Benoit Cousson
2013-02-26 18:27 ` [PATCH V3 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver Jon Hunter
2013-03-19 16:04   ` Jon Hunter
2013-03-20 16:36     ` Tony Lindgren
2013-04-01 17:48       ` Jon Hunter
2013-04-01 18:26         ` 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=513FA19C.60904@ti.com \
    --to=jon-hunter@ti.com \
    --cc=b-cousson@ti.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=rob.herring@calxeda.com \
    --cc=s-guiriec@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 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).