lkml.org 
[lkml]   [2015]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC/PATCH 0/9] IOMMU probe deferral support
    Hello,

    On 2015-05-15 01:00, Laurent Pinchart wrote:
    > This patch series attempts to implement support for deferring probe of both
    > IOMMU drivers and bus master drivers.
    >
    > The relationship between bus masters and IOMMUs creates a strong ordering
    > during initialization of devices. As in the general case IOMMUs are hidden
    > behind the DMA mapping API, IOMMU support relies on the automatic setup of DMA
    > operations without any direct intervention of bus master drivers.
    >
    > DMA operations are set up when platform devices are added to the system. This
    > requires IOMMUs to be available at that time. On systems where ordering of
    > device add and probe can't be guaranteed (such as, but not limited to,
    > DT-based systems) this caused incorrect DMA operation setup. This has been
    > addressed by a patches series [1] that introduced a DT-based early
    > registration mechanism for IOMMUs.
    >
    > However, that mechanism fails to address all issues. Various dependencies
    > exist between IOMMU devices and other devices, in particular on clocks and on
    > power domains (as mentioned by Marek in [2]). While there are mechanisms to
    > handle some of them without probe deferral (for instance by using the
    > OF_DECLARE macros to register clock drivers), generalizing those mechanisms
    > would essentially recreate a probe ordering mechanism similar to link order
    > probe ordering and couldn't really scale.
    >
    > Additionally, IOMMUs could also be present hot-pluggable devices and depend on
    > resources that are thus hot-plugged. OF_DECLARE wouldn't help in that case.
    > For all those reasons probe deferral for IOMMUs has been considered as desired
    > if it can be implemented cleanly. For more in-depth information see [3].
    >
    > This RFC series is a first attempt at implementing IOMMU probe deferral
    > support cleanly.
    >
    > The core idea is to move setup of DMA operations from device add time to
    > device probe time, implemented in patch 6/9. It could be possible to move
    > setup of other DMA parameters (namely masks and offset) to probe time as well,
    > but that change would be more intrusive and has a higher risk of introducing
    > regressions. For that reason I've decided to keep DMA masks and offset setup
    > at device add time and thus split DMA configuration in masks and operations
    > (patch 5/9). This can be revisited if we decide that the DMA mapping API
    > shouldn't require masks and offset to be set before probe time.
    >
    > Patch 8/9 then defers probe of bus master drivers when required IOMMUs are not
    > available yet. This requires knowing when a failed IOMMU lookup should be
    > considered as permanent or temporary. I've reused the OF_DECLARE_IOMMU for
    > this purpose, considering that the presence of a driver compatible with the
    > IOMMU DT node indicates that the failure is temporary and probing of the bus
    > master device should be deferred.
    >
    > Note that only IOMMU drivers using the recent .of_xlate() mechanism for
    > DT-based IOMMU reference can cause probe deferral of bus master devices. The
    > .add_device() mechanism isn't supported in this case.
    >
    > As an example I've converted the ipmmu-vmsa driver to the new API in patch 9/9.
    >
    > At this point many enhancements are possible, but I'd like to receive feedback
    > on the proposed approach before basing more patches on this series. One
    > particular point I would like to address (or see being addressed) in the
    > future is the use of struct iommu_ops with of_iommu_get_ops() and
    > of_iommu_set_ops(). I believe we should introduct a struct iommu and register
    > IOMMU instances instead of IOMMU operations. That should bring us one step
    > closer to removing bus_set_iommu().

    I've checked this patchset with my recent updates to Exynos IOMMU driver. It
    works fine. Then I removed my exynos_iommu_of_setup() callback and
    relied only
    on proper initialization from platform device probe() of all iommu
    controllers.
    The driver also worked fine in such case.

    The other change I had to make to get everything working was removal of some
    hackery in dma-mapping internal structures in Exynos DRM driver, but this is
    completely different story.

    You can add the following tag for the of/iommu/dma-mapping patches:
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

    > [1] http://www.spinics.net/lists/arm-kernel/msg382787.html
    > [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323238.html
    > [3] https://lkml.org/lkml/2015/2/16/345
    >
    > Laurent Pinchart (9):
    > arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
    > arm: dma-mapping: Support IOMMU mappings spanning the full 32 bits
    > range
    > of: dma: Move range size workaround to of_dma_get_range()
    > of: dma: Make of_dma_deconfigure() public
    > of: dma: Split of_configure_dma() into mask and ops configuration
    > drivers: platform: Configure dma operations at probe time
    > iommu: of: Document the of_iommu_configure() function
    > iommu: of: Handle IOMMU lookup failure with deferred probing or error
    > iommu/ipmmu-vmsa: Use DT-based instantiation
    >
    > arch/arm/include/asm/dma-iommu.h | 2 +-
    > arch/arm/mm/dma-mapping.c | 21 +++--
    > drivers/base/platform.c | 9 ++
    > drivers/iommu/ipmmu-vmsa.c | 189 +++++++++++++--------------------------
    > drivers/iommu/of_iommu.c | 29 +++++-
    > drivers/of/address.c | 20 ++++-
    > drivers/of/device.c | 77 ++++++++++------
    > drivers/of/of_pci.c | 3 +-
    > drivers/of/platform.c | 16 ++--
    > include/linux/of_device.h | 14 ++-
    > 10 files changed, 195 insertions(+), 185 deletions(-)

    Best regards
    --
    Marek Szyprowski, PhD
    Samsung R&D Institute Poland



    \
     
     \ /
      Last update: 2015-05-27 15:41    [W:4.276 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site