REGRESSION in 6.0-rc7 caused by patch "ARM/dma-mapping: use dma-direct unconditionally"

Marcin Wojtas mw at semihalf.com
Tue Oct 4 05:59:29 PDT 2022


wt., 4 paź 2022 o 14:37 Marek Behún <kabel at kernel.org> napisał(a):
>
> On Tue, 4 Oct 2022 10:08:15 +0100
> "Russell King (Oracle)" <linux at armlinux.org.uk> wrote:
>
> > On Tue, Oct 04, 2022 at 10:30:40AM +0200, Marcin Wojtas wrote:
> > > Thanks for the explanation and I agree with your reasoning. Therefore
> > > the below should be sufficient if we use HW BM and non-coherent
> > > setting:
> > >
> > > --- a/drivers/net/ethernet/marvell/mvneta_bm.c
> > > +++ b/drivers/net/ethernet/marvell/mvneta_bm.c
> > > @@ -103,7 +103,7 @@ int mvneta_bm_construct(struct hwbm_pool
> > > *hwbm_pool, void *buf)
> > >          */
> > >         *(u32 *)buf = (u32)buf;
> > >         phys_addr = dma_map_single(&priv->pdev->dev, buf, bm_pool->buf_size,
> > > -                                  DMA_FROM_DEVICE);
> > > +                                  DMA_BIDIRECTIONAL);
> > >         if (unlikely(dma_mapping_error(&priv->pdev->dev, phys_addr)))
> > >                 return -ENOMEM;
> > >
> > > Marek - can you please confirm that?
> >
> > This is insufficient. Marek's patch is the correct version.
> >
> > The DMA API requires that the direction argument is the same for
> > mapping, unmapping and syncing a region.
>
> And now I am wondering about whether this didn't also cause the buffer
> manager not working on Armada 3720. Marvell just gave an erratum that
> HWBM is broken on 3720, but maybe they didn't notice this and just gave
> up.

I implemented inital version of this support, which was never
published > 5y ago (I checked my oldest repos, but the code is gone
unfortunately). I don't recall exact HW issue justification - I
remember it was not related to coherency though, but the decision was
to drop it.

>
> Also mvneta works only with one CPU on 3720 (see usage of
> pp->neta_armada3700 in mvneta.c), which I also still don't know why,
> and maybe it is related to this.
>

The single-core processing is result of the problems with per-CPU IRQ
routing for the NETA controllers (never to be fixed eventually), not
related to coherency whatsoever.

Best regards,
Marcin



More information about the linux-arm-kernel mailing list