FSL 64-bit DMA window question
Scott Wood
scottwood at freescale.com
Sat Jun 8 09:29:31 EST 2013
On 06/07/2013 05:39:53 PM, Benjamin Herrenschmidt wrote:
> On Fri, 2013-06-07 at 17:34 -0500, Scott Wood wrote:
> > > You also need to account for other on-chip MMIOs no ? Or do you
> never
> > > intend to let PCI devices hit them ?
> >
> > I don't think we normally need that (other than MSIs, which have a
> > special window under 4G)... The question is whether it's better to
> let
> > odd use cases work without having to manually move the DMA window,
> at
> > the cost of decreased out-of-the-box performance with common PCIe
> cards.
>
> Sorry, I didn't parse what the tradeoff is here...
I just meant that a PCIe device targeting something other than RAM,
CCSR (it's not just MSIs that are mapped through the special window),
or another PCIe is a rather unusual case -- not something that you'd
see by just plugging in an ordinary PCIe card. The tradeoff is that if
we accommodate this strange use case, boards like the radeon would need
to use swiotlb (once we fix the > versus >= bug) unless the user tweaks
the DMA window.
It may be best to stick with the default that makes everything work,
even if a broken PCIe card ends up being a bit slower out of the box,
even if the PCIe-to-MMIO use case is weird and would require custom
setup anyway. OTOH, did we ever care about 32-bit DMA being able to
access MMIO?
> Putting the inbound window above memory seems like a reasonable
> option then
> (at least as a default that the board can override).
>
> I sincerely hope those radeons are the only remaining things with
> that sort of
> limitation but you never know ... it's all x86 fault of course for
> never having
> used high DMA windows :-)
Hmm... Why are we using this special window at all? Can't we just have
one large identity mapping starting at zero, with the MSI window
presumably taking precedence? The manual is a bit vague on whether
inbound windows can overlap with priority... in EP mode it says it
does, and the RC section is silent. Do we currently ever overlap
PCICSRBAR with a real window?
-Scott
More information about the Linuxppc-dev
mailing list