public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Rob Herring <robherring2@gmail.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	Russell King <linux@arm.linux.org.uk>,
	Olof Johansson <olof@lixom.net>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 4/7] of: configure the platform device dma_mask and dma_pfn_offset
Date: Sun, 9 Mar 2014 07:39:18 +0100	[thread overview]
Message-ID: <201403090739.18351.arnd@arndb.de> (raw)
In-Reply-To: <CAL_JsqLu_16p-8FLjBYt7xQA2eAyiprPML2q5R3fnivZPrvPug@mail.gmail.com>

On Saturday 08 March 2014, Rob Herring wrote:
> On Fri, Mar 7, 2014 at 10:02 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > a) Follow what we do for PCI devices: assume that we can do DMA_MASK(32)
> > on any device, and have drivers call dma_set_mask(DMA_MASK(64)) on devices
> > that would like to do more than that, or call e.g. dma_set_mask(DMA_MASK(28))
> > for devices that can do less than 32 bit, as given in the argument. This
> > approach would be most consistent with the way PCI works, but it doesn't
> > really work well for the case where the mask is less than 32-bit and the
> > device driver doesn't know that.
> >
> > b) Never have to call dma_set_mask() for platform devices and assume that the
> > platform code sets it up correctly. This would probably be the simpler
> > solution, and I can't think of any downsides at the moment.
> 
> I don't think we want this. In the case of setting up 64-bit masters,
> it is typically the device that knows if it can do 64-bit DMA either
> thru a capabilities register or compatible value. That device specific
> knowledge should really stay within the device's driver.

So you think we should still set a 64-bit mask in the "ranges" property
for devices that can only do 32-bit and let the driver figure it out?

I think this approach is much less useful for platform devices than it is
for PCI devices, where we don't explicitly describe the "ranges" for each
device. Are you thinking of off-chip or on-chip DMA masters here? If
on-chip, I don't think it's likely that we would end up with different
versions of the chip that have the same device on there but not the
same DMA capabilities.

	Arnd

  reply	other threads:[~2014-03-11 13:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-06  9:19 [PATCH 0/7] of: setup dma parameters using dma-ranges and dma-coherent Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 1/7] device: introduce per device dma_pfn_offset Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 2/7] of: introduce of_dma_get_range() helper Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 3/7] of: introduce of_dma_is_coherent() helper Santosh Shilimkar
2014-03-07  3:13   ` Rob Herring
2014-03-07  3:44     ` Santosh Shilimkar
2014-03-07  3:55       ` Rob Herring
2014-03-07  4:18         ` Santosh Shilimkar
2014-03-07 16:09           ` Arnd Bergmann
2014-03-10 13:28             ` Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 4/7] of: configure the platform device dma_mask and dma_pfn_offset Santosh Shilimkar
2014-03-07  3:49   ` Rob Herring
2014-03-07  4:16     ` Santosh Shilimkar
2014-03-07 16:02       ` Arnd Bergmann
2014-03-08 20:11         ` Rob Herring
2014-03-09  6:39           ` Arnd Bergmann [this message]
2014-03-12  0:15             ` Rob Herring
2014-03-12 13:19               ` Grygorii Strashko
2014-03-12 16:58                 ` Arnd Bergmann
2014-03-14 14:14                   ` Rob Herring
2014-03-14 17:25                     ` Arnd Bergmann
2014-03-25 18:06                       ` Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 5/7] of: Add set_arch_dma_coherent_ops() and setup coherent dma_ops Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 6/7] ARM: dma: Use dma_pfn_offset for dma address translation Santosh Shilimkar
2014-03-06  9:19 ` [PATCH 7/7] ARM: dma: implement set_arch_dma_coherent_ops() Santosh Shilimkar

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=201403090739.18351.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=grygorii.strashko@ti.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=robherring2@gmail.com \
    --cc=santosh.shilimkar@ti.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