Messages in this thread | | | Date | Wed, 17 Nov 2021 14:46:36 +0000 | From | Daniel Thompson <> | Subject | Re: [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case |
| |
On Wed, Nov 17, 2021 at 03:03:04PM +0200, Laurentiu Tudor wrote: > Hi Daniel, > > Sorry for the late reply, please see some comments inline. > > On 11/11/2021 7:23 PM, Daniel Thompson wrote: > > Hi Laurentiu > > > > On Thu, Jul 15, 2021 at 05:07:12PM +0300, laurentiu.tudor@nxp.com wrote: > >> From: Laurentiu Tudor <laurentiu.tudor@nxp.com> > >> > >> ACPI DMA configure API may return a defer status code, so handle it. > >> On top of this, move the MC firmware resume after the DMA setup > >> is completed to avoid crashing due to DMA setup not being done yet or > >> being deferred. > >> > >> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> > > > > I saw regressions on my Honeycomb LX2 (NXP LX2060A) when I switched to > > v5.15. It seems like it results in so many sMMU errors that the system > > cannot function correctly (it's only about a 75% chance the system will > > boot to GUI and even if it does boot successfully the system will hang > > up soon after). > > > > Bisect took me up a couple of blind alleys (mostly due to unrelated boot > > problems in v5.14-rc2) by eventually led me to this patch as the cause. > > Applying/unapplying this patch to a v5.14-rc3 tree will provoke/fix the > > problem and reverting it against v5.15 also resolves the problem. > > That's pretty strange. Was the DPAA2 based networking working with this > patch reverted?
I think so. I haven't studied the LX2K architecture too heavily but I assume the 1G networking socket at the back of Honeycomb LX2 is DPAA2 baseD? If so, that 1G socket works with the patch reverted.
Note that I was already using "arm-smmu.disable_bypass=0" on this platform since I was guided into doing that based on the error messages from older kernels. It was only the new requirement to set iommu.passthrough that caught me out.
> > Is there some specific firmware version required for this patch to work > > correctly? > > It's a bit of a long story. As Jon already mentioned, we're waiting for > maintainers to agree on the IORT RMR support on which we depend to > declare in UEFI reserved memory regions for the MC firmware. > For now, the recommended workaround is to use the > "arm-smmu.disable_bypass=0" kernel boot arg.
I see. Looks like, after the traffic on the ML in October, that this patch set is pending a v8 revision in order to stimulate the next round of discussion?
Daniel.
| |