Re: [PATCH V3 0/8] IOMMU probe deferral support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sricharan,


On 2016-10-12 08:24, Sricharan wrote:
On 2016-10-04 19:03, Sricharan R wrote:
Initial post from Laurent Pinchart[1]. This is
series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is called. Similarly dma_deconfigure is called during
device/driver_detach path.


pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
         |                         |
pci_bus_add_device     (device_add/driver_register)
         |                         |
device_attach           device_initial_probe
         |                         |
__device_attach_driver    __device_attach_driver
         |
driver_probe_device
         |
really_probe
         |
dma_configure

   Similarly on the device/driver_unregister path __device_release_driver is
   called which inturn calls dma_deconfigure.

   If the ACPI bus code follows the same, we can add acpi_dma_configure
   at the same place as of_dma_configure.

   This series is based on the recently merged Generic DT bindings for
   PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy@xxxxxxx [2]

   This time tested this with platform and pci device for probe deferral
   and reprobe on arm64 based platform. There is an issue on the cleanup
   path for arm64 though, where there is WARN_ON if the dma_ops is reset while
   device is attached to an domain in arch_teardown_dma_ops.
   But with iommu_groups created from the iommu driver, the device is always
   attached to a domain/default_domain. So so the WARN has to be removed/handled
   probably.
Thanks for continuing work on this feature! Your can add my:

Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>

   Thanks for testing this. So the for the below fix, the remove_device callback
   gets called on the dma_ops cleanup path, so would it be easy to remove the
   data for the device there ?

I assumed that IOMMU driver cannot be removed reliably, so all structures that it creates are permanent. I didn't use device_add()/device_remove() callbacks, because in current implementation device_add() is called too late (after dma-mapping glue
triggers device_attach_iommu()).

Maybe once your patchset is merged, I will move creation and management of the all
IOMMU related structures to device_add/remove callbacks.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux