Message-ID: <CABdtJHsroGYe9Q7WdwusjG7Ac8_RNT+E0DbQCOo_VzZqkWdiLw@mail.gmail.com>
Date:   Wed, 17 Nov 2021 14:22:52 +0100
From:   Jon Nettleton <jon@...id-run.com>
To:     Laurentiu Tudor <laurentiu.tudor@....com>
Cc:     Daniel Thompson <daniel.thompson@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Diana Madalina Craciun <diana.craciun@....com>,
        Ioana Ciornei <ioana.ciornei@....com>, leoyang.li@....com
Subject: Re: [PATCH 2/8] bus: fsl-mc: handle DMA config deferral in ACPI case

On Wed, Nov 17, 2021 at 2:07 PM Laurentiu Tudor <laurentiu.tudor@....com> wrote:
>
>
>
> On 11/12/2021 7:31 PM, Daniel Thompson wrote:
> > On Thu, Nov 11, 2021 at 06:36:58PM +0100, Jon Nettleton wrote:
> >> On Thu, Nov 11, 2021 at 6:23 PM Daniel Thompson
> >> <daniel.thompson@...aro.org> wrote:
> >>>
> >>> Hi Laurentiu
> >>>
> >>> On Thu, Jul 15, 2021 at 05:07:12PM +0300, laurentiu.tudor@....com wrote:
> >>>> From: Laurentiu Tudor <laurentiu.tudor@....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@....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.
> >>>
> >>> Is there some specific firmware version required for this patch to work
> >>> correctly?
> >>
> >> This patch was merged as a requirement for operational on board networking.
> >> This was merged as a prerequisite to landing the patches to support MDIO and
> >> phy initialization in general.
> >
> > Interesting.
> >
> > I assumed the change of behaviour comes from properly handling
> > -EPROBE_DEFER (which can hardly be regarded as a fault with the patch).
> >
> > Having said that the patch does not seem to be mandatory to get the 1G
> > networking working on Honeycomb LX2 (running ACPI). By taking v5.15 and
> > reverting as I shared previously, I am still able to access the network
> > using the 1G port on the back of the unit (although I didn't do any
> > performance tests).
> >
> >
> >> The correct solution for the problem you are seeing is the ACPI
> >> maintainers figuring out how to land the IORT RMR patchset.  Until
> >> that is done the only workaround is setting "arm-smmu.disable_bypass=0
> >> iommu.passthrough=1" on the kernel commandline.  The latter option is
> >> required since 5.15 and I haven't had time or energy to figure out
> >> why.  The proper solution is to just land the IORT RMR patchset and
> >> let HoneyComb run with the SMMU enabled.
> >
> > Thanks for the update. I'll probably adopt iommu.passthrough=1 for now.
> > That allows me to adopt a distro kernel when it updates to v5.15.
>
> The "iommu.passthrough=1" kernel arg shouldn't be needed. By chance, do
> you remember what errors were you seeing? What was failing?

This wasn't needed prior to 5.15, both are needed now. I have not bothered
to bisect what caused it, since we have a proper solution that just needs
to be merged.  Then we won't need any kernel arguments.

-Jon

>
> ---
> Thanks & Best Regards, Laurentiu

Powered by blists - more mailing lists