Re: [PATCH 08/10] iommu/omap: Use bus_set_iommu instead of register_iommu

[Ohad Ben-Cohen]

(sorry for the late response; we had a big holiday here and I was
forced away from my keyboard :)

On Thu, Sep 29, 2011 at 11:04 PM, Greg KH <greg@xxxxxxxxx> wrote:
> On Fri, Sep 23, 2011 at 05:45:54PM +0200, Joerg Roedel wrote:
>> -     register_iommu(&omap_iommu_ops);
>> +     bus_set_iommu(&platform_bus_type, &omap_iommu_ops);
>
> I too worry about this.
>
> It kind of looks like the omap code should not be using the platform bus
> code for this, but instead, use their own bus code, as I'm sure that not
> all platform devices really work properly with this iommu controller,
> right?

You're right that not all omap platform devices will work with this
iommu device.

But maybe it's worth explaining the bigger difference here: there is
no omap bus really that makes sense here as much as pci does with x86.

On OMAP each iommu device services a single, and specific, on-chip
device (and not a group of devices that resides on a specific hardware
bus). E.g. on OMAP4 we have an iommu for the DSP, and another one for
the dual Cortex M3.

Those remote processors devices happen to be platform devices (because
there isn't really any relevant hardware bus here), and board code (or
DT) will set their iommu archdata to point at the relevant iommu
devices they're physically attached to. This way their drivers will be
able to configure the appropriate iommu devices as needed.

Binding the iommu ops to the platform bus will not enable other
platform drivers to configure the iommu: no other device will have the
relevant iommu archdata set, and any attempt to erroneously configure
the iommu by an unrelated driver will immediately fail (i.e.
iommu_attach_device() will fail).

In that sense, binding the iommu ops to the platform bus does not
increase the chance of error. I guess it even reduces it, because
today the iommu ops are globally accessible.

I was worried that with this change, sub-devices of the original
platform device, that belong to a different bus (e.g. virtio or
rpmsg), might not be able to access those iommu ops anymore. But I
guess that as long as we set the parent-child device hierarchy
appropriately, that would be a non issue.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/