Thread (64 messages) 64 messages, 10 authors, 2020-06-06

Re: [PATCHv9 00/12] PCI: Recode Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs

From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Date: 2020-02-11 13:55:38
Also in: linux-devicetree, linux-pci, lkml


On 11.02.2020 15:04, Robin Murphy wrote:
On 2020-02-11 12:13 pm, Laurentiu Tudor wrote:
[...]
quoted
quoted
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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help