Hi Joerg, On 09/01/2017 05:01 AM, Joerg Roedel wrote: > Hi Suman, > > On Thu, Aug 31, 2017 at 08:14:02AM -0500, Suman Anna wrote: >> The OMAP IOMMU driver has been enhanced to support allowing >> multiple IOMMUs to be programmed by a single client user. This >> support is being added mainly to handle the DSP subsystems on >> the DRA7xx SoCs, which have two MMUs within the same subsystem. >> These MMUs provide translations to a processor core port and >> an internal EDMA port. This support allows both the MMUs to >> be programmed together, but with each one retaining it's own >> internal state objects. The internal EDMA is managed by the >> software running on the DSPs, and this design provides on-par >> functionality with previous generation OMAP DSPs where the >> EDMA and the DSP core shared the same MMU. > > I didn't get that from the review, so a question here: Do both MMUs show > show up in sysfs, means, do you register both of them the the core code? Yes, both MMUs are identical instances of the IP, and both are represented as their own platform devices (unique DT nodes), and since we created the iommu_group in probe of each device, each MMU has its own iommu_group as well. Here's a bit more output, root@dra7xx-evm:~# dmesg | grep mmu [ 0.519087] omap-iommu 40d01000.mmu: 40d01000.mmu registered [ 0.519580] omap-iommu 40d02000.mmu: 40d02000.mmu registered [ 0.520050] omap-iommu 58882000.mmu: 58882000.mmu registered [ 0.520495] omap-iommu 55082000.mmu: 55082000.mmu registered [ 0.521145] omap-iommu 41501000.mmu: 41501000.mmu registered [ 0.521634] omap-iommu 41502000.mmu: 41502000.mmu registered [ 0.522100] iommu: Adding device 58820000.ipu to group 2 [ 0.522260] iommu: Adding device 55020000.ipu to group 3 [ 0.522520] iommu: Adding device 40800000.dsp to group 0 [ 0.522955] iommu: Adding device 41000000.dsp to group 4 root@dra7xx-evm:~# ls -l /sys/class/iommu/ lrwxrwxrwx 1 root root 0 Aug 8 03:59 40d01000.mmu -> ../../devices/platform/44000000.ocp/40d01000.mmu/iommu/40d01000.mmu lrwxrwxrwx 1 root root 0 Aug 8 03:59 40d02000.mmu -> ../../devices/platform/44000000.ocp/40d02000.mmu/iommu/40d02000.mmu lrwxrwxrwx 1 root root 0 Aug 8 03:59 41501000.mmu -> ../../devices/platform/44000000.ocp/41501000.mmu/iommu/41501000.mmu lrwxrwxrwx 1 root root 0 Aug 8 03:59 41502000.mmu -> ../../devices/platform/44000000.ocp/41502000.mmu/iommu/41502000.mmu lrwxrwxrwx 1 root root 0 Aug 8 03:59 55082000.mmu -> ../../devices/platform/44000000.ocp/55082000.mmu/iommu/55082000.mmu lrwxrwxrwx 1 root root 0 Aug 8 03:59 58882000.mmu -> ../../devices/platform/44000000.ocp/58882000.mmu/iommu/58882000.mmu > Because I think with the solution implemented here, only a single, > combined MMU should be visible to iommu core code and in sysfs. So, the way I have implemented atm is to do the device linking only to one MMU in .add_device ops, while most of the remaining ops like map, unmap, attach_device, detach_device loop through both MMUs to do the programming. It's primarily a question of whether each iommu platform device need to be represented as a unique iommu_device or not. If you still think that both these need to be presented to iommu core as one device, I would have to add some glue logic in probe to tie the two devices together. regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
