On Dec 1, 2011, at 12:03 AM, Kumar Gala wrote: > There is an issue on FSL-BookE 64-bit devices (P5020) in which PCIe > devices that are capable of doing 64-bit DMAs (like an Intel e1000) do > not function and crash the kernel if we have >4G of memory in the system. > > The reason is that the existing code only sets up one inbound window for > access to system memory across PCIe. That window is limited to a 32-bit > address space. So on systems we'll end up utilizing SWIOTLB for dma > mappings. However SWIOTLB dma ops implement dma_alloc_coherent() as > dma_direct_alloc_coherent(). Thus we can end up with dma addresses that > are not accessible because of the inbound window limitation. > > We could possibly set the SWIOTLB alloc_coherent op to > swiotlb_alloc_coherent() however that does not address the issue since > the swiotlb_alloc_coherent() will behave almost identical to > dma_direct_alloc_coherent() since the devices coherent_dma_mask will be > greater than any address allocated by swiotlb_alloc_coherent() and thus > we'll never bounce buffer it into a range that would be dma-able. > > The easiest and best solution is to just make it so that a 64-bit > capable device is able to DMA to any internal system address. > > We accomplish this by opening up a second inbound window that maps all > of memory above the internal SoC address width so we can set it up to > access all of the internal SoC address space if needed. > > We than fixup the dma_ops and dma_offset for PCIe devices with a dma > mask greater than the maximum internal SoC address. > > Signed-off-by: Kumar Gala <ga...@kernel.crashing.org> > --- > arch/powerpc/sysdev/fsl_pci.c | 55 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 55 insertions(+), 0 deletions(-)
applied to merge - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
