From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Yuri Tikhonov <yur@emcraft.com>
Cc: linuxppc-dev@ozlabs.org, Detlev Zundel <dzu@denx.de>,
Wolfgang Denk <wd@denx.de>, Ilya Yanok <yanok@emcraft.com>
Subject: Re: Re[2]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes
Date: Fri, 14 Nov 2008 16:41:29 +1100 [thread overview]
Message-ID: <1226641289.7178.117.camel@pasglop> (raw)
In-Reply-To: <1102187680.20081114074513@emcraft.com>
> My understanding was that the dma-ranges property is responsible for
> setting up the inbound ranges of RAM's physical addresses, where PCI
> could DMA to/from. As regarding the outbound property, this patch
> doesn't change this, and there we have the PCI space split (2 GB of
> memory, and 64K of I/O spaces mapped from the 64-bit physical
> addresses into 32-bit PCI address space). Am I missing something ?
The PCI memory space doesn't differenciate inbound and outbound.
For example, if you take the example of a PCI 2.0 or PCI-X setup (I'm
leaving PCI-E alone in the discussion because it's a bit special in that
area, but the problem is fundamentally the same), and you have on the
PCI bus of that thing a device X configured to respond to MMIO at
address, for example, 0x80000000.
Now, what happens if another device, let's call it Y, tries to DMA to
that same address ? Who will pick up the memory write at address
0x80000000 ? The host controller or device X ?
There is no concept of "inbound" here.. it's just a memory cycle to
address A that gets decoded by whoever tries to decode it on that bus
segment.
Thus DMA ranges must -not- overlap areas of memory used for MMIO, it
just won't work.
> With the default 2GB dma-ranges we just get the following on Katmai
> with 4GB of SDRAM installed:
Because that is simply not supported at the moment unless we add what
I've talked about earlier, ie basically, swiotlb support (which Becky is
working on at the moment).
You might be able to work around it somewhat if your PCI device supports
64-bit BARs in which case you can set your outbound regions above the
32-bit space. Note that I haven't verified whether the 32-bit linux
kernel supports that tho. There used to be issues with >32-bit PCI BARs
on 32-bit kernel, at least it wouldn't assign them but that may have
been fixed.
Another option you can try if you device only does 32-bit BARs but
supports 64-bit DMA, is to move the DMA window away from the 32-bit MMIO
space. Stick it at 1T or so in PCI space. You might need a little bit of
kernel tweaking to make the dma-ops pick that up properly but that
shouldnt be too hard.
If you really need 32-bit DMA support, you'll have to wait for swiotlb
from Becky or work with her in bringing it to powerpc so that we can do
bounce buffering for those devices.
Ben.
next prev parent reply other threads:[~2008-11-14 5:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-13 8:49 [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes Yuri Tikhonov
2008-11-13 9:25 ` Benjamin Herrenschmidt
2008-11-14 4:45 ` Re[2]: " Yuri Tikhonov
2008-11-14 5:41 ` Benjamin Herrenschmidt [this message]
[not found] ` <1767195957.20081127032002@emcraft.com>
2008-11-27 0:26 ` Re[4]: " Yuri Tikhonov
2008-11-27 0:42 ` Benjamin Herrenschmidt
2008-11-27 0:59 ` Re[6]: " Yuri Tikhonov
2008-11-27 4:07 ` Benjamin Herrenschmidt
2008-11-13 11:45 ` Josh Boyer
2008-11-14 5:00 ` Grant Likely
2008-11-14 5:27 ` Re[2]: " Yuri Tikhonov
2008-11-14 5:30 ` Grant Likely
2008-11-14 5:21 ` Yuri Tikhonov
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=1226641289.7178.117.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=dzu@denx.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=wd@denx.de \
--cc=yanok@emcraft.com \
--cc=yur@emcraft.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).