[lkml]   [2021]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
<> 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

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.


> thanks,
> greg k-h

 \ /
  Last update: 2021-02-09 09:02    [W:0.113 / U:1.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site