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?
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.
