On Wednesday, August 31, 2016 6:23:24 PM CEST Thierry Reding wrote: > From: Thierry Reding <treding@xxxxxxxxxx> > > According to the TRM, the SD/MMC controller on Tegra124 supports 34-bit > addressing, but testing shows that this doesn't work. On a device which > has more than 2 GiB of RAM and LPAE enabled, buffer allocations can use > addresses above the 32-bit boundary. > > One way to work around this would be to enable IOMMU physical to virtual > address translations for the SD/MMC controllers, but that's not easy to > implement without breaking existing use-cases. It's also not obvious why > 34-bit addressing doesn't work as advertised. In order to fix this for > existing users, add the SDHCI_QUIRK2_BROKEN_64_BIT_DMA quirk for now. > > Reported-by: Paul Kocialkowski <contact@xxxxxxxx> > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> > --- Acked-by: Arnd Bergmann <arnd@xxxxxxxx> I also tried to find the code that handles bounce buffers for the attached devices in the absence of SWIOTLB (which ARM does not use). The mmc block driver handles this correctly with the blk_queue_bounce_limit() call, and any SDIO network devices will work as long as they a) don't advertize NETIF_F_HIGHDMA, and b) all memory that is out of reach of the SDHCI device is also beyond the highmem boundary (this might not be true with CONFIG_VMSPLIT_1G) All other SDIO devices (camera, DVB, bluetooth) might need driver changes or SWIOTLB support here, but those devices are fairly rare, and it's possible that all upstream drivers are actually ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
