Re: FSL 64-bit DMA window question

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2013-06-07 at 18:29 -0500, Scott Wood wrote:

> 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.

Yeah, well, swiotlb won't work for radeon anyway. It has its own
"mmu" (a GART really) and will constantly want to pin pages in it,
swiotlb will be at best a mess and at worst will just not work.

> 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?

Not that I know of.

> 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? 

Then you'd have to reserve the RAM covered by the MSI window, not
necessarily a big deal. It would also still allow swiotlb to work, so it
actually doesn't seem like a bad idea if you don't have an actual /
usable iommu.

So if it works, I like that idea even better.

>  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?

Cheers,
Ben.