On 30/03/18 01:45 PM, Jerome Glisse wrote: > Looking at upstream code it seems that the x86 bits never made it upstream > and thus what is now upstream is only for ARM. See [1] for x86 code. Dunno > what happen, i was convince it got merge. So yes current code is broken on > x86. ccing Joerg maybe he remembers what happened there. > > [1] https://lwn.net/Articles/646605/ That looks like a significant improvement over what's upstream. But it's three years old and looks to have been abandoned. I think I agree with Bjorn's comments in that if it's going to be a general P2P API it will need the device the resource belongs to in addition to the device that's initiating the DMA request. > Given it is currently only used by ARM folks it appear to at least work > for them (tm) :) Note that Christian is doing this in PCIE only context > and again dma_map_resource can easily figure that out if the address is > a PCIE or something else. Note that the exporter export the CPU bus > address. So again dma_map_resource has all the informations it will ever > need, if the peer to peer is fundamentaly un-doable it can return dma > error and it is up to the caller to handle this, just like GPU code do. > > Do you claim that dma_map_resource is missing any information ? Yes, that's what I said. All the existing ARM code appears to use it for platform devices only. I suspect platform P2P is relatively trivial to support on ARM. I think it's a big difference from using it for PCI P2P or general P2P on any bus. > I agree and understand that but for platform where such feature make sense > this will work. For me it is PowerPC and x86 and given PowerPC has CAPI > which has far more advance feature when it comes to peer to peer, i don't > see something more basic not working. On x86, Intel is a bit of lone wolf, > dunno if they gonna support this usecase pro-actively. AMD definitly will. Well PowerPC doesn't even support P2P between root ports. And I fail to see how CAPI applies unless/until we get this memory mapped into userspace and the mappings need to be dynamically managed. Seems like that's a long way away. Logan
