On Monday 19 May 2014 10:03:40 Catalin Marinas wrote: > On Mon, May 19, 2014 at 09:32:43AM +0100, Arnd Bergmann wrote: > > On Friday 16 May 2014 13:55:01 Catalin Marinas wrote: > > > On Thu, May 15, 2014 at 05:53:53PM +0100, Liviu Dudau wrote: > > > > On Thu, May 15, 2014 at 04:36:25PM +0100, Alan Stern wrote: > > > > > On Thu, 15 May 2014, Liviu Dudau wrote: > > > > > > On Thu, May 15, 2014 at 03:11:48PM +0100, Alan Stern wrote: > > > > > > > On Wed, 14 May 2014, Mark Brown wrote: > > > > > > > > arm64 architecture handles correctly 64bit DMAs and can enable support > > > > > > > > for 64bit EHCI host controllers. > > > > > > > > > > > > > > Did you folks tested this for all sorts of host controllers? I have no > > > > > > > way to verify that it works, and last I heard, many (or even most) > > > > > > > controllers don't work right with 64-bit DMA. > > > > > > > > > > > > I have tested it with a host controller that is capable of 64-bit DMA and > > > > > > without this change it doesn't work. > > > > > > > > > > What do you mean it doesn't work? Can't the host controller use 32-bit > > > > > DMA? > > > > > > > > It could if arm64 would restrict the DMA addresses to 32-bit, but it doesn't > > > > and I end up on my platform with USB DMA buffers allocated >4GB address. > > > > > > dma_alloc_coherent() on arm64 should return 32-bit addresses if the > > > coherent_dma_mask is set to 32-bit. Which kernel version is this? > > > > The more important question is what happens to high buffers allocated elsewhere > > that get passed into dma_map_sg by a device driver. Depending on the DT properties > > of the device and its parents, this needs to do one of three things: > > > > a) translate the 64-bit virtual address into a 64-bit bus address > > b) create an IOMMU entry for the 64-bit address and pass the 32-bit IOMMU > > address to the driver > > c) use the swiotlb code to create a bounce buffer at a 32-bit DMA address > > and copy the data around > > > > It's definitely wrong to just hardcode a DMA mask in the driver because that > > code doesn't know which of the three cases is being used. Moreover, you can't > > do it using an #ifdef CONFIG_ARM64, because it's completely independent of > > the architecture, and we need to do the exact same logic on ARM32 and any > > other architecture. > > I agree. > > The problem we currently have is system topology description to pass the > DMA mask and in a hierarchical way. I can see Santosh's patches > introducing dma-ranges but the coherent dma mask still set as 32-bit. We > can use the dma-ranges to infer a mask but that's only specific to the > device and the driver doesn't know whether it goes through an iommu or > not. We definitely have to fix this very quickly, before people start building real arm64 systems and shipping them. We should not merge any hacks that attempt to work around the problem, but try to come to a conclusion how to handle them properly. My hope was that we could just always set the dma mask to whatever the DT says it should be to keep the burden from device drivers, unless they want to restrict it further (e.g. when the specific peripheral hardware has a bug that prevents us from using high addresses, even though the SoC in theory supports it everywhere). Rob Herring argued that we should always mimic PCI and call dma_set_mask() in drivers but default to a 32-bit mask otherwise, independent of whether the hardware can do more or less than that, IIRC. While we currently don't have a set of swiotlb DMA ops on ARM32, we do have it on ARM64, and I think we should be using them properly. It should really not be hard to implement a proper dma_set_mask() function for ARM64 that gets is able to set up the swiotlb based on the dma-ranges properties and always returns success but leaves the mask unchanged. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
