Messages in this thread | | | Subject | Re: [PATCH 17/18] media/omap3isp: Clean up IOMMU workaround | From | Suman Anna <> | Date | Mon, 24 Aug 2020 16:55:42 -0500 |
| |
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@arm.com> >>>> >>>> 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.
| |