Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-11 Thread Robin Murphy
On 11/01/17 12:37, Nikita Yushchenko wrote: >> I actually have a third variation of this problem involving a PCI root >> complex which *could* drive full-width (40-bit) addresses, but won't, >> due to the way its PCI<->AXI interface is programmed. That would require >> even more complicated

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-11 Thread Arnd Bergmann
On Wednesday, January 11, 2017 3:37:22 PM CET Nikita Yushchenko wrote: > > I actually have a third variation of this problem involving a PCI root > > complex which *could* drive full-width (40-bit) addresses, but won't, > > due to the way its PCI<->AXI interface is programmed. That would require >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-11 Thread Nikita Yushchenko
> I actually have a third variation of this problem involving a PCI root > complex which *could* drive full-width (40-bit) addresses, but won't, > due to the way its PCI<->AXI interface is programmed. That would require > even more complicated dma-ranges handling to describe the windows of > valid

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Arnd Bergmann
On Tuesday, January 10, 2017 2:16:57 PM CET Robin Murphy wrote: > On 10/01/17 13:42, Arnd Bergmann wrote: > > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: > >> On 10/01/17 12:47, Nikita Yushchenko wrote: > The point here is that an IOMMU doesn't solve your issue, and the >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Arnd Bergmann
On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: > On 10/01/17 12:47, Nikita Yushchenko wrote: > >> The point here is that an IOMMU doesn't solve your issue, and the > >> IOMMU-backed DMA ops need the same treatment. In light of that, it really > >> feels to me like the DMA masks

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Christoph Hellwig
On Tue, Jan 10, 2017 at 02:42:23PM +0100, Arnd Bergmann wrote: > It's a much rarer problem for the IOMMU case though, because it only > impacts devices that are restricted to addressing of less than 32-bits. > > If you have an IOMMU enabled, the dma-mapping interface does not care > if the device

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Christoph Hellwig
On Tue, Jan 10, 2017 at 03:47:25PM +0300, Nikita Yushchenko wrote: > With this direction, semantics of dma mask becomes even more > questionable. I'd say dma_mask is candidate for removal (or to move to > swiotlb's or iommu's local area) We need the dma mask so that the device can advertise what

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Robin Murphy
On 10/01/17 13:42, Arnd Bergmann wrote: > On Tuesday, January 10, 2017 1:25:12 PM CET Robin Murphy wrote: >> On 10/01/17 12:47, Nikita Yushchenko wrote: The point here is that an IOMMU doesn't solve your issue, and the IOMMU-backed DMA ops need the same treatment. In light of that, it

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Nikita Yushchenko
>> What issue "IOMMU doesn't solve"? >> >> Issue I'm trying to address is - inconsistency within swiotlb >> dma_map_ops, where (1) any wide mask is silently accepted, but (2) then >> mask is used to decide if bounce buffers are needed or not. This >> inconsistency causes NVMe+R-Car cobmo not

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Robin Murphy
On 10/01/17 12:47, Nikita Yushchenko wrote: > Hi > >> The point here is that an IOMMU doesn't solve your issue, and the >> IOMMU-backed DMA ops need the same treatment. In light of that, it really >> feels to me like the DMA masks should be restricted in of_dma_configure >> so that the parent

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Arnd Bergmann
On Tuesday, January 10, 2017 3:47:25 PM CET Nikita Yushchenko wrote: > > > The point here is that an IOMMU doesn't solve your issue, and the > > IOMMU-backed DMA ops need the same treatment. In light of that, it really > > feels to me like the DMA masks should be restricted in of_dma_configure >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Nikita Yushchenko
Hi > The point here is that an IOMMU doesn't solve your issue, and the > IOMMU-backed DMA ops need the same treatment. In light of that, it really > feels to me like the DMA masks should be restricted in of_dma_configure > so that the parent mask is taken into account there, rather than hook >

Re: [PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-10 Thread Will Deacon
On Mon, Jan 09, 2017 at 10:30:02AM +0300, Nikita Yushchenko wrote: > It is possible that device is capable of 64-bit DMA addresses, and > device driver tries to set wide DMA mask, but bridge or bus used to > connect device to the system can't handle wide addresses. > > With swiotlb, memory above

[PATCH v2] arm64: do not set dma masks that device connection can't handle

2017-01-08 Thread Nikita Yushchenko
It is possible that device is capable of 64-bit DMA addresses, and device driver tries to set wide DMA mask, but bridge or bus used to connect device to the system can't handle wide addresses. With swiotlb, memory above 4G still can be used by drivers for streaming DMA, but *dev->mask and