The code can be revived if necessary. I still think this code should be kept tegra specific because the current implementation IMO does not work in generic case... and the generic case solution would not suit well for our needs. Our implementation assumes that both source and target devices share the same address space and thus there is no need to actually do buffer mapping when the target device wishes to access a buffer. The code just creates a scattertable for already mapped pages. Currently we wish to share buffers only between host1x devices and therefore this restriction does not cause any issues. However, in generic case the target and source devices can be in different address spaces and hence the code actually _should_ map the buffer to the target device's address space. AFAIK dma-mapping API is not smart enough to determine whether a given buffer is already mapped to some address space. It just maps and potentially creates duplicates (please correct me if I am wrong). Therefore, if the "generic case solution" is applied to our "specific case", there will always be duplicates and I do not think that is a good practice. I also considered doing a smart optimisation here, but dma-mapping API did not seem to support querying of the address space of a certain device. - Arto ________________________________________ From: Terje Bergstrom Sent: Saturday, November 24, 2012 9:59 PM To: Thierry Reding Cc: linux-tegra@xxxxxxxxxxxxxxx; Arto Merilainen Subject: Re: [PATCH 5/6] gpu: drm: tegra: Prime support On 24.11.2012 21:14, Thierry Reding wrote: > I still don't see how that's relevant here. IOMMU support has explicitly > been removed as you mentioned in your introductory email and none of the > functionality in this patch is in any way specific to Tegra. Right? You're right - my point became moot once we disabled IOMMU. Arto, can we revive the generic code? Terje -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
