On 8/20/20 6:01 PM, Robin Murphy wrote: > On 2020-08-20 20:55, Sakari Ailus wrote: >> On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote: >>> On 2020-08-20 17:53, Sakari Ailus wrote: >>>> Hi Robin, >>>> >>>> On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote: >>>>> Now that arch/arm is wired up for default domains and iommu-dma, devices >>>>> behind IOMMUs will get mappings set up automatically as appropriate, so >>>>> there is no need for drivers to do so manually. >>>>> >>>>> Signed-off-by: Robin Murphy <robin.murphy@xxxxxxx> >>>> >>>> Thanks for the patch. >>> >>> Many thanks for testing so quickly! >>> >>>> I haven't looked at the details but it seems that this causes the buffer >>>> memory allocation to be physically contiguous, which causes a failure to >>>> allocate video buffers of entirely normal size. I guess that was not >>>> intentional? >>> >>> Hmm, it looks like the device ends up with the wrong DMA ops, which implies >>> something didn't go as expected with the earlier IOMMU setup and default >>> domain creation. Chances are that either I missed some subtlety in the >>> omap_iommu change, or I've fundamentally misjudged how the ISP probing works >>> and it never actually goes down the of_iommu_configure() path in the first >>> place. Do you get any messages from the IOMMU layer earlier on during boot? Yeah, I don't think we go through the of_iommu_configure() path, the setup is mostly done using .probe_device() and .attach_dev() ops. Since the MMUs are present directly in the respective sub-systems and relies on the sub-system clocking and power, the MMU itself is turned ON and enabled during .attach_dev(). regards Suman >> >> I do get these: >> >> [ 2.934936] iommu: Default domain type: Translated >> [ 2.940917] omap-iommu 480bd400.mmu: 480bd400.mmu registered >> [ 2.946899] platform 480bc000.isp: Adding to iommu group 0 >> > > So that much looks OK, if there are no obvious errors. Unfortunately there's no > easy way to tell exactly what of_iommu_configure() is doing (beyond enabling a > couple of vague debug messages). The first thing I'll do tomorrow is > double-check whether it's really working on my boards here, or whether I was > just getting lucky with CMA... (I assume you don't have CMA enabled if you're > ending up in remap_allocator_alloc()) > > Robin. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
