Am Mittwoch, den 14.12.2016, 14:48 +0100 schrieb Thierry Reding: > On Wed, Dec 14, 2016 at 12:35:31PM +0100, Lucas Stach wrote: > > Am Mittwoch, den 14.12.2016, 13:16 +0200 schrieb Mikko Perttunen: > > > Add a new IO virtual memory allocation API to allow clients to > > > allocate non-GEM memory in the Tegra DRM IOMMU domain. This is > > > required e.g. for loading client firmware when clients are attached > > > to the IOMMU domain. > > > > > > The allocator allocates contiguous physical pages that are then > > > mapped contiguously to the IOMMU domain using the iova_domain > > > library provided by the kernel. Contiguous physical pages are > > > used so that the same allocator works also when IOMMU support > > > is disabled and therefore devices access physical memory directly. > > > > > Why is this needed? If you use the DMA API for those buffers you should > > end up with CMA memory in the !IOMMU case and normal paged memory with > > IOMMU enabled. From my understanding this should match the requirements. > > We can't currently use the DMA API for these allocations because it > doesn't allow (or at least didn't back when this was first implemented) > us to share a mapping between two devices. Hm, maybe I'm overlooking something, but isn't this just a matter of allocating on one device, then constructing a SG list (dma_get_sgtable) from the buffer you got and use that to dma_map_sg() the buffer on the other device? Maybe doing the firmware buffer allocation on host1x (with a 4GB upper bound) and then sharing the SG list to the devices? > The reason why we need these patches is that when IOMMU is enabled, then > the units' falcons will read memory through the IOMMU, so we must have > allocations for GEM buffers and the firmware go through the same > mechanism. Sorry for maybe dumb questions. Do you have any engines other than the GPU that can handle SG themselves? Wouldn't you want the GEM objects to be backed by CMA in the !MMU case? How are ordinary GEM objects different from the falcon firmware? Regards, Lucas -- 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
