(reviving an old thread) On Sunday 09 November 2014 21:27:40 Arnd Bergmann wrote: > > > >> + /* > > >> + * Inbound address translation setup > > >> + * Northstar only maps up to 128 MiB inbound, DRAM could be up to 1 GiB. > > >> + * > > >> + * For now allow access to entire DRAM, assuming it is less than 128MiB, > > >> + * otherwise DMA bouncing mechanism may be required. > > >> + * Also consider DMA mask to limit DMA physical address > > >> + */ > > >> + /* 64-bit LE regs, write low word, high is 0 at reset */ > > >> + bcma_write32(bdev, BCMA_CORE_PCIE2_FUNC0_IMAP1, PHYS_OFFSET | 0x1); > > >> + bcma_write32(bdev, BCMA_CORE_PCIE2_IARR1_LOWER, > > >> + PHYS_OFFSET | ((SZ_128M >> 20) & 0xff)); > > > > > > Maybe I should bully you into enabling swiotlb on arm32 > > > > This sounds complicated, I hope I can avoid it. > > I'd really hope that it's not that hard. We basically just need a copy of > coherent_swiotlb_dma_ops/noncoherent_swiotlb_dma_ops from arm64 and > use those on bcma devices, with the right dma_mask set. Peter Senna has tested this on bcm4708a0 (Buffalo WZR-1750DHP) and found that all RAM is DMA capable, as tested with CONFIG_VMSPLIT_1G. Could the code comment here be incorrect, or is it possible that it was fixed in later chip versions? If this works, using CONFIG_VMSPLIT_1G should result in noticeably better I/O performance on this chip. I have created a patch that lets him simulate the broken behavior on his machine, so he can work on implementing swiotlb, but it would certainly be best to understand which machines are really affected. Note that the driver that was merged as drivers/pci/host/pcie-iproc.c does not seem to touch the BCMA_CORE_PCIE2_IARR1_LOWER (offset 0xd08) register, and presumably the power-on default for this register maps all of RAM correctly. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
