lkml.org 
[lkml]   [2021]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2021-11-17 15:47    [W:0.267 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site