linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Vinod Koul <vinod.koul@intel.com>, Gerhard Sittig <gsi@denx.de>,
	Alexander Popov <a13xp0p0v88@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Anatolij Gustschin <agust@denx.de>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup
Date: Mon, 18 Nov 2013 15:23:57 +0000	[thread overview]
Message-ID: <20131118152357.GB3759@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <201311181531.54818.arnd@arndb.de>

On Mon, Nov 18, 2013 at 02:31:54PM +0000, Arnd Bergmann wrote:
> On Monday 18 November 2013, Mark Rutland wrote:
> > > +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> > > @@ -0,0 +1,55 @@
> > > +* Freescale MPC512x DMA Controller
> > > +
> > > +The DMA controller in the Freescale MPC512x SoC can move blocks of
> > > +memory contents between memory and peripherals or memory to memory.
> > > +
> > > +Refer to the "Generic DMA Controller and DMA request bindings" description
> > > +in the dma.txt file for a more detailled discussion of the binding.  The
> > > +MPC512x DMA engine binding follows the common scheme, but doesn't provide
> > > +support for the optional channels and requests counters (those values are
> > > +derived from the detected hardware features) and has a fixed client
> > > +specifier length of 1 integer cell (the value is the DMA channel, since
> > > +the DMA controller uses a fixed assignment of request lines per channel).
> > 
> > The fact that #dma-cells must be <1> isn't a difference from the
> > standard binding, and needs not be described here. The meaning of the
> > value should be in your description of #dma-cells below.
> 
> I think the value it has to be in there, and I have in the past asked other
> people to add this. Note that in the generic binding, it says that it must
> be "at least 1". You can have controllers that require a larger number, or
> that can use 1 or 2 alternatively, depending on how the device is wired
> up, e.g. when a dma controller has two master ports you would need a
> second cell to specify the port number, but only if more than one port
> is actually connected to a slave.

The number of cells required should be described. My points were that it
should be described at the property description rather than in the introduction,
and that the fact that a specific value was required was not a
difference from the bindings as the paragraph implied.

> 
> > I'm not sure it's worth mentioning optional channels / request counters.
> > If anything, it would be better to update dma.txt to move the "Optional
> > properties" to something like "Suggested properties"...
> 
> These are less clearly defined. In the generic binding, it's mostly a matter
> of "if you need to pass this information, use these properties". The individual
> binding can then make them mandatory if needed.

Agreed. I'd prefer that bindings described the suggested properties they
used, rather than those they don't.

Thanks,
Mark.

  reply	other threads:[~2013-11-18 15:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01  7:19 [PATCH RFC v5 0/5] MPC512x DMA slave s/g support, OF DMA lookup Alexander Popov
2013-11-01  7:19 ` [PATCH RFC v5 1/5] dma: mpc512x: reorder mpc8308 specific instructions Alexander Popov
2013-11-01 10:04   ` Anatolij Gustschin
2013-11-11 20:01     ` Gerhard Sittig
2013-11-01  7:19 ` [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers Alexander Popov
2013-11-11 20:10   ` Gerhard Sittig
2013-11-12 12:23     ` Alexander Popov
2013-11-14 20:58       ` Gerhard Sittig
2013-11-20  6:49         ` Alexander Popov
2013-11-01  7:19 ` [PATCH RFC v5 3/5] dma: of: Add common xlate function for matching by channel id Alexander Popov
2013-11-01  7:52   ` Arnd Bergmann
2013-11-07 11:33     ` Alexander Popov
2013-11-01  7:19 ` [PATCH RFC v5 4/5] dma: mpc512x: register for device tree channel lookup Alexander Popov
2013-11-18 12:09   ` Mark Rutland
2013-11-18 14:31     ` Arnd Bergmann
2013-11-18 15:23       ` Mark Rutland [this message]
2013-11-01  7:19 ` [PATCH RFC v5 5/5] HACK mmc: mxcmmc: enable clocks for the MPC512x Alexander Popov

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=20131118152357.GB3759@e106331-lin.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=a13xp0p0v88@gmail.com \
    --cc=agust@denx.de \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gsi@denx.de \
    --cc=lars@metafoo.de \
    --cc=linuxppc-dev@lists.ozlabs.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 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).