Messages in this thread | | | Subject | Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs | From | Laurentiu Tudor <> | Date | Tue, 11 Feb 2020 15:55:20 +0200 |
| |
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?
> 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. :)
--- Best Regards, Laurentiu
| |