All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org, Anton Blanchard <anton@samba.org>,
	Shaohui Xie <Shaohui.Xie@freescale.com>
Subject: Re: [PATCH 1/4] powerpc: Dynamic DMA zone limits
Date: Tue, 14 Oct 2014 11:44:25 +0200	[thread overview]
Message-ID: <1413279865.2878.20.camel@aoeu.buserror.net> (raw)
In-Reply-To: <1413273473.26478.52.camel@pasglop>

On Tue, 2014-10-14 at 18:57 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-10-14 at 09:39 +0200, Scott Wood wrote:
> > For a short-term workaround, I'd rather leave CONFIG_ZONE_DMA32 where
> > it
> > is and put #ifdef CONFIG_FSL_SOC (with a comment) around the whole
> > thing.
> 
> I'd like to not enable CONFIG_ZONE_DMA32 when we don't need it, ie,
> on !BOOKE 64-bit

How does 64-bit powermac deal with it, with random PCI cards?  Does it
use an IOMMU for coherent allocations?

In any case, CONFIG_ZONE_DMA32 should be harmless if the zone isn't
dynamically created, but we can limit it to booke if you want.  The
current breakage has nothing to do with ZONE_DMA32, but rather to the
fact that we now check zones at all.  This is why I'd rather have the
short term workaround be a new ifdef, rather than moving ifdef
CONFIG_ZONE_DMA32 (moving it also obscures the way the code should look
if and when the workaround can be removed).

-Scott

      reply	other threads:[~2014-10-14  9:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08 23:40 [PATCH 1/4] powerpc: Dynamic DMA zone limits Scott Wood
2014-08-08 23:40 ` [PATCH 2/4] powerpc/64: Honor swiotlb limit in coherent allocations Scott Wood
2014-08-08 23:40 ` [PATCH 3/4] powerpc/64: Limit ZONE_DMA32 to 4GiB in swiotlb_detect_4g() Scott Wood
2014-08-08 23:40 ` [PATCH 4/4] powerpc/fsl-pci: Limit ZONE_DMA32 to 2GiB on 64-bit platforms Scott Wood
2014-10-13  7:14 ` [PATCH 1/4] powerpc: Dynamic DMA zone limits Anton Blanchard
2014-10-13  7:30   ` Benjamin Herrenschmidt
2014-10-13  9:00   ` Michael Ellerman
2014-10-14  7:39     ` Scott Wood
2014-10-14  7:57       ` Benjamin Herrenschmidt
2014-10-14  9:44         ` Scott Wood [this message]

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=1413279865.2878.20.camel@aoeu.buserror.net \
    --to=scottwood@freescale.com \
    --cc=Shaohui.Xie@freescale.com \
    --cc=anton@samba.org \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.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.