Message-ID: <CAFA6WYM+xJ0YDKenWFPMHrTz4gLWatnog84wyk31Xy2dTiT2RA@mail.gmail.com>
Date:   Tue, 9 Feb 2021 13:28:47 +0530
From:   Sumit Garg <sumit.garg@...aro.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        obayashi.yoshimasa@...ionext.com
Cc:     hch@....de, m.szyprowski@...sung.com, robin.murphy@....com,
        iommu@...ts.linux-foundation.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Daniel Thompson <daniel.thompson@...aro.org>
Subject: Re: DMA direct mapping fix for 5.4 and earlier stable branches

Thanks Greg for your response.

On Tue, 9 Feb 2021 at 12:28, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Tue, Feb 09, 2021 at 11:39:25AM +0530, Sumit Garg wrote:
> > Hi Christoph, Greg,
> >
> > Currently we are observing an incorrect address translation
> > corresponding to DMA direct mapping methods on 5.4 stable kernel while
> > sharing dmabuf from one device to another where both devices have
> > their own coherent DMA memory pools.
>
> What devices have this problem?

The problem is seen with V4L2 device drivers which are currently under
development for UniPhier PXs3 Reference Board from Socionext [1].
Following is brief description of the test framework:

The issue is observed while trying to construct a Gstreamer pipeline
leveraging hardware video converter engine (VPE device) and hardware
video encode/decode engine (CODEC device) where we use dmabuf
framework for Zero-Copy.

Example GStreamer pipeline is:
gst-launch-1.0 -v -e videotestsrc \
> ! video/x-raw, width=480, height=270, format=NV15 \
> ! v4l2convert device=/dev/vpe0 capture-io-mode=dmabuf-import \
> ! video/x-raw, width=480, height=270, format=NV12 \
> ! v4l2h265enc device=/dev/codec0 output-io-mode=dmabuf \
> ! video/x-h265, format=byte-stream, width=480, height=270 \
> ! filesink location=out.hevc

Using GStreamer's V4L2 plugin,
- v4l2convert controls VPE driver,
- v4l2h265enc controls CODEC driver.

In the above pipeline, VPE driver imports CODEC driver's DMABUF for Zero-Copy.

[1] arch/arm64/boot/dts/socionext/uniphier-pxs3-ref.dts

> And why can't then just use 5.10 to
> solve this issue as that problem has always been present for them,
> right?

As the drivers are currently under development and Socionext has
chosen 5.4 stable kernel for their development. So I will let
Obayashi-san answer this if it's possible for them to migrate to 5.10
instead?

BTW, this problem belongs to the common code, so others may experience
this issue as well.

>
> > I am able to root cause this issue which is caused by incorrect virt
> > to phys translation for addresses belonging to vmalloc space using
> > virt_to_page(). But while looking at the mainline kernel, this patch
> > [1] changes address translation from virt->to->phys to dma->to->phys
> > which fixes the issue observed on 5.4 stable kernel as well (minimal
> > fix [2]).
> >
> > So I would like to seek your suggestion for backport to stable kernels
> > (5.4 or earlier) as to whether we should backport the complete
> > mainline commit [1] or we should just apply the minimal fix [2]?
>
> Whenever you try to create a "minimal" fix, 90% of the time it is wrong
> and does not work and I end up having to deal with the mess.

I agree with your concerns for having to apply a non-mainline commit
onto a stable kernel.

>  What
> prevents you from doing the real thing here?  Are the patches to big?
>

IMHO, yes the mainline patch is big enough to touch multiple
architectures. But if that's the only way preferred then I can
backport the mainline patch instead.

> And again, why not just use 5.10 for this hardware?  What hardware is
> it?
>

Please see my response above.

-Sumit

> thanks,
>
> greg k-h

Powered by blists - more mailing lists