[PATCH V3 0/8] IOMMU probe deferral support
Sricharan
sricharan at codeaurora.org
Mon Oct 24 05:30:46 PDT 2016
Hi Marek,
>>>> 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 at arm.com [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 at samsung.com>
>>>
>> 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.
>
ok understand it.
Regards,
Sricharan
More information about the linux-arm-kernel
mailing list