lkml.org 
[lkml]   [2011]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 08/10] iommu/omap: Use bus_set_iommu instead of register_iommu
    (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@kroah.com> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-10-02 19:27    [W:0.023 / U:31.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site