On 11/02/2020 1:55 pm, Laurentiu Tudor wrote:
On 11.02.2020 15:04, Robin Murphy wrote:
On 2020-02-11 12:13 pm, Laurentiu Tudor wrote:
[...]
This is a known issue about DPAA2 MC bus not working well with SMMU
based IO mapping. Adding Laurentiu to the chain who has been looking
into this issue.
Yes, I'm closely following the issue. I actually have a workaround
(attached) but haven't submitted as it will probably raise a lot of
eyebrows. In the mean time I'm following some discussions [1][2][3]
on the iommu list which seem to try to tackle what appears to be a
similar issue but with framebuffers. My hope is that we will be able
to leverage whatever turns out.
Indeed it's more general than framebuffers - in fact there was a
specific requirement from the IORT side to accommodate network/storage
controllers with in-memory firmware/configuration data/whatever set up
by the bootloader that want to be handed off 'live' to Linux because
the overhead of stopping and restarting them is impractical. Thus this
DPAA2 setup is very much within scope of the desired solution, so
please feel free to join in (particularly on the DT parts) :)
Will sure do. Seems that the 2nd approach (the one with list of
compatibles in arm-smmu) fits really well with our scenario. Will this
be the way to go forward?
I'm hoping that Thierry's proposal can be made to work out, since it's
closer to how the ACPI version should work, which means we would be able
to do a lot more in shared common code rather than baking magic
knowledge and duplicated functionality into individual IOMMU drivers.
As for right now, note that your patch would only be a partial
mitigation to slightly reduce the fault window but not remove it
entirely. To be robust the SMMU driver *has* to know about live
streams before the first arm_smmu_reset() - hence the need for generic
firmware bindings - so doing anything from the MC driver is already
too late (and indeed the current iommu_request_dm_for_dev() mechanism
is itself a microcosm of the same problem).
I think you might have missed in the patch that it pauses the firmware
at early boot, in its driver init and it resumes it only after
iommu_request_dm_for_dev() has completed. :)
Ah, from the context I missed that that was non-modular and relying on
initcall trickery... fair enough, in that case I'll downgrade my "it's
insufficient" to "it's ugly and somewhat fragile" :P
Thanks,
Robin.
