[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMeyCbgAFsySM5Jb-rnbR3tV3vVMDRa+DDdwAiCmbRj15gexzQ@mail.gmail.com>
Date: Fri, 20 Nov 2020 08:53:43 +0100
From: Kegl Rohit <keglrohit@...il.com>
To: Andy Duan <fugang.duan@....com>
Cc: David Laight <David.Laight@...lab.com>,
Eric Dumazet <eric.dumazet@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [EXT] Re: Fwd: net: fec: rx descriptor ring out of order
On Sun, Nov 15, 2020 at 8:48 AM Andy Duan <fugang.duan@....com> wrote:
>
> From: Kegl Rohit <keglrohit@...il.com> Sent: Sunday, November 15, 2020 1:37 AM
> > On Sat, Nov 14, 2020 at 2:58 AM Andy Duan <fugang.duan@....com> wrote:
> > >
> > > From: Kegl Rohit <keglrohit@...il.com> Sent: Friday, November 13, 2020
> > > 8:21 PM
> > > > On Fri, Nov 13, 2020 at 8:33 AM Kegl Rohit <keglrohit@...il.com> wrote:
> > > > >
> > > > > > What are the addresses of the ring entries?
> > > > > > I bet there is something wrong with the cache coherency and/or
> > > > > > flushing.
> > > > > >
> > > > > > So the MAC hardware has done the write but (somewhere) it isn't
> > > > > > visible to the cpu for ages.
> > > > >
> > > > > CMA memory is disabled in our kernel config.
> > > > > So the descriptors allocated with dma_alloc_coherent() won't be CMA
> > memory.
> > > > > Could this cause a different caching/flushing behaviour?
> > > >
> > > > Yes, after tests I think it is caused by the disabled CMA.
> > > >
> > > > @Andy
> > > > I could find this mail and the attached "i.MX6 dma memory bufferable
> > > > issue.pptx" in the archive
> > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > > rc.info
> > > > %2F%3Fl%3Dlinux-netdev%26m%3D140135147823760&data=04%7C
> > 01
> > > > %7Cfugang.duan%40nxp.com%7C121e73ec66684a125e2a08d887cea578%
> > 7C
> > > >
> > 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637408668924362983
> > > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> > LCJ
> > > >
> > BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e7Cm24Ay1Ay52UKtzT
> > > > BiX9KlhuublndP30vnwxAaugM%3D&reserved=0
> > > > Was this issue solved in some kernel versions later on?
> > > > Is CMA still necessary with a 5.4 Kernel?
> > >
> > > Yes, CMA is required. Otherwise it requires one patch for L2 cache.
> >
> > Where can I find the patch / is the patch already mainline?
> No, the patch is not in mainline. CMA can fix the issue.
>
> The original patch is: set shared override bit in PL310 AUX_CTRL register
>
> > Is it some development patch or already well tested?
> > Or would you recommend enabling CMA instead?
> > Are other components affected apart from the already mentioned peripherals
> > (ENET, Audio, USB) in the attachment?
> Yes, recommend CMA that can fix the cache issue for all components.
Ok, thanks. One more Question: The kernel's default CMA size is 16MB,
is this enough for a headless system without usage of the IPU?
Powered by blists - more mailing lists