linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Add pdev_archdata for dmamask
Date: Mon, 27 Jan 2014 20:36:35 +0000	[thread overview]
Message-ID: <20140127203635.GA15937@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1390854331.23180.22.camel@localhost.localdomain>

On Mon, Jan 27, 2014 at 09:25:31PM +0100, Yann Droneaud wrote:
> ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
> the infamous dma_mask pointer. So perhaps my solution is better.
> 
> This solution (adding dma_mask in pdev_archdata) is already in use in
> powerpc architecture. See arch/powerpc/kernel/setup-common.c
> 
> The advantage of this solution is that it makes a dma_mask placeholder
> available to statically allocated platform_device struct, while mine
> only address the problem for platform_device struct allocated with
> platform_device_alloc().

As I've already said in this thread, the basic problem comes from DT's
platform device creation.  It's the responsibility of the device creator
to set the dma_mask pointer appropriately, and DT doesn't do that.  So,
DT needs to be fixed rather than everyone introducing their own
workarounds for this.

> I'm also considering using dma_set_mask_and_coherent() in
> platform_device_register_full() and drivers using
> platform_device_alloc().

As the one who introduced dma_set_mask_and_coherent, consider this a
strong NAK on that.  The reason is dma_set_mask_and_coherent() is
for drivers to set their requirements, not for the bus requirements
to be set in the first place.

It also means that drivers which need no DMA support are subjected to
DMA restrictions (in that dma_set_mask_and_coherent can error out if
the platform can't support the DMA mask.)

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".

  reply	other threads:[~2014-01-27 20:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27 17:52 [PATCH] arm64: Add pdev_archdata for dmamask Laura Abbott
2014-01-27 18:18 ` Uwe Kleine-König
2014-01-27 19:24   ` Laura Abbott
2014-01-27 20:25   ` Yann Droneaud
2014-01-27 20:36     ` Russell King - ARM Linux [this message]
2014-01-27 21:42       ` Yann Droneaud
2014-01-27 19:31 ` Russell King - ARM Linux
2014-01-28  1:42   ` Laura Abbott
2014-02-17 12:29     ` Catalin Marinas
2014-02-17 12:52     ` Russell King - ARM Linux

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=20140127203635.GA15937@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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 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).