From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org, Anton Blanchard <anton@au1.ibm.com>,
Brian J King <bjking1@us.ibm.com>
Subject: Re: [PATCH 2/3] powerpc/dma: Support 32-bit coherent mask with 64-bit dma_mask
Date: Wed, 25 Feb 2015 07:40:57 +1100 [thread overview]
Message-ID: <1424810457.12891.49.camel@kernel.crashing.org> (raw)
In-Reply-To: <1424810077.4698.30.camel@freescale.com>
On Tue, 2015-02-24 at 14:34 -0600, Scott Wood wrote:
> On Fri, 2015-02-20 at 19:35 +1100, Benjamin Herrenschmidt wrote:
> > @@ -149,14 +141,13 @@ static void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sg,
> >
> > static int dma_direct_dma_supported(struct device *dev, u64 mask)
> > {
> > -#ifdef CONFIG_PPC64
> > - /* Could be improved so platforms can set the limit in case
> > - * they have limited DMA windows
> > - */
> > - return mask >= get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
> > -#else
> > - return 1;
> > + u64 offset = get_dma_offset(dev);
> > + u64 limit = offset + memblock_end_of_DRAM() - 1;
> > +
> > +#if defined(CONFIG_ZONE_DMA32)
> > + limit = offset + dma_get_zone_limit(ZONE_DMA32);
> > #endif
> > + return mask >= limit;
> > }
>
> I'm confused as to whether dma_supported() is supposed to be testing a
> coherent mask or regular mask... The above suggests coherent, as does
> the call to dma_supported() in dma_set_coherent_mask(), but if swiotlb
> is used, swiotlb_dma_supported() will only check for a mask that can
> accommodate io_tlb_end, without regard for coherent allocations.
This is confusing indeed, but without the above, dma_set_coherent_mask()
won't work ... so I'm assuming the above. Notice that x86 doesn't even
bother and basically return 1 for anything above a 24 bit mask (appart
from the force_sac case but we can ignore it).
So we probably should fix our swiotlb implementation as well... but
that's orthogonal.
> > static u64 dma_direct_get_required_mask(struct device *dev)
> > diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> > index f146ef0..a7f15e2 100644
> > --- a/arch/powerpc/mm/mem.c
> > +++ b/arch/powerpc/mm/mem.c
> > @@ -277,6 +277,11 @@ int dma_pfn_limit_to_zone(u64 pfn_limit)
> > return -EPERM;
> > }
> >
> > +u64 dma_get_zone_limit(int zone)
> > +{
> > + return max_zone_pfns[zone] << PAGE_SHIFT;
> > +}
>
> If you must do this in terms of bytes rather than pfn, cast to u64
> before shifting -- and even then the result will be PAGE_SIZE - 1 too
> small.
Do we have RAM above what a unsigned long can hold ? I think I'll just
make it a pfn and respin...
Cheers,
Ben.
> -Scott
>
next prev parent reply other threads:[~2015-02-24 20:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 8:35 [PATCH 2/3] powerpc/dma: Support 32-bit coherent mask with 64-bit dma_mask Benjamin Herrenschmidt
2015-02-24 20:34 ` Scott Wood
2015-02-24 20:40 ` Benjamin Herrenschmidt [this message]
2015-02-24 23:05 ` Scott Wood
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=1424810457.12891.49.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=anton@au1.ibm.com \
--cc=bjking1@us.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.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).