All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Serge Semin <fancer.lancer@gmail.com>,
	Viresh Kumar <vireshk@kernel.org>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>, Vinod Koul <vkoul@kernel.org>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	linux-kernel@vger.kernel.org,
	Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Subject: Re: [PATCH v2 1/5] dt-bindings: dma: dw: Add optional DMA-channels mask cell support
Date: Mon, 17 Aug 2020 13:00:14 +0300	[thread overview]
Message-ID: <20200817100014.GG1891694@smile.fi.intel.com> (raw)
In-Reply-To: <20200803215147.GA3201744@bogus>

On Mon, Aug 03, 2020 at 03:51:47PM -0600, Rob Herring wrote:
> On Fri, 31 Jul 2020 23:08:22 +0300, Serge Semin wrote:
> > Each DW DMA controller channel can be synthesized with different
> > parameters like maximum burst-length, multi-block support, maximum data
> > width, etc. Most of these parameters determine the DW DMAC channels
> > performance in its own aspect. On the other hand these parameters can
> > be implicitly responsible for the channels performance degradation
> > (for instance multi-block support is a very useful feature, but having
> > it disabled during the DW DMAC synthesize will provide a more optimized
> > core). Since DMA slave devices may have critical dependency on the DMA
> > engine performance, let's provide a way for the slave devices to have
> > the DMA-channels allocated from a pool of the channels, which according
> > to the system engineer fulfill their performance requirements.
> > 
> > The pool is determined by a mask optionally specified in the fifth
> > DMA-cell of the DMA DT-property. If the fifth cell is omitted from the
> > phandle arguments or the mask is zero, then the allocation will be
> > performed from a set of all channels provided by the DMA controller.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>

Rob, I have a question to clarify (it's not directly related to the series,
but to this schema and property names).

We have two drivers for DMA controllers from Synopsys (they are different)
where properties with the same semantics (like block_size or data-width) have
different pattern of naming (okay, block_size for older driver even has _
instead of -), i.e. block_size vs. snps,block-size and data-width vs.
snps,data-width.

I would like to unify them (*) in both drivers and would like to know which
naming pattern is preferred in such case?

*) Yes, we have to leave support for deprecated properties in this case in
   the code.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2020-08-17 10:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-31 20:08 [PATCH v2 0/5] dmaengine: dw: Introduce non-mem peripherals optimizations Serge Semin
2020-07-31 20:08 ` [PATCH v2 1/5] dt-bindings: dma: dw: Add optional DMA-channels mask cell support Serge Semin
2020-08-03 21:51   ` Rob Herring
2020-08-17 10:00     ` Andy Shevchenko [this message]
2020-08-19 14:02       ` Rob Herring
2020-07-31 20:08 ` [PATCH v2 2/5] dmaengine: dw: Activate FIFO-mode for memory peripherals only Serge Semin
2020-07-31 20:08 ` [PATCH v2 3/5] dmaengine: dw: Discard dlen from the dev-to-mem xfer width calculation Serge Semin
2020-07-31 20:08 ` [PATCH v2 4/5] dmaengine: dw: Ignore burst setting for memory peripherals Serge Semin
2020-07-31 20:08 ` [PATCH v2 5/5] dmaengine: dw: Add DMA-channels mask cell support Serge Semin
2020-08-17  6:28 ` [PATCH v2 0/5] dmaengine: dw: Introduce non-mem peripherals optimizations 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=20200817100014.GG1891694@smile.fi.intel.com \
    --to=andy.shevchenko@gmail.com \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=vireshk@kernel.org \
    --cc=vkoul@kernel.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.