Re: Correct way to use vb2_dma_sg via USB?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Florian,

W dniu 29.11.2022 o 17:28, Hans Verkuil pisze:
On 29/11/2022 16:48, Florian Echtler wrote:
Following up on [PATCH 1/7] media: videobuf-dma-contig: use dma_mmap_coherent:

If the videobuf framework is going to be replaced anyway, would it even make sense to try and fix this bug in the (admittedly very specific) sur40 driver?

videobuf is the old predecessor of the videobuf2 framework. The sur40 driver
uses vb2 (as it should), and vb2 is here to stay.

The old videobuf framework is on the way out, but that's unrelated to your driver.

I'm afraid I'm not a usb expert, so I can't help with this.

Regards,

	Hans


If the answer should be yes, then I'd still need a hint about how to make vb2_dma_sg work with usb_sg_init...

Best, Florian

On 14.11.22 15:32, Florian Echtler wrote:
Sorry to nag again, but is there anyone around who might be able to give me hint? Have not been able to find any conclusive documentation on this.

Best, Florian

On 09.11.22 11:09, Florian Echtler wrote:
Hello everyone,

while trying to fix the regression in sur40.ko mentioned earlier, I noticed that apparently some other bits of the DMA pipeline have changed as well in the meantime.

The code bit in question in sur40.c currently looks as follows:

      sgt = vb2_dma_sg_plane_desc(&new_buf->vb.vb2_buf, 0);

I can't give you a fish, but maybe I can point to where the fishing rod is.

Based on the description (nents == 0) I'd _assume_ that the problem is not at
the videobuf2-usb intersection but rather in a way videobuf2 is/should be used.
This is only an _assumption_, though.

The above call ends up in vb2_dma_sg_cookie(). The "cookie" is buf->dma_sgt,
which, according to the comment in struct vb2_dma_sg_buf definition, will point
to eiter sg_table (vb2_dma_sg_buf's member) or dma_buf sglist.

You need to know which memory model you use: mmap, userptr or dmabuf.

The reason why nents is (still?) zero might be that dma_map_sgtable() has never
been called. Or __dma_map_sg_attrs() in dma_map_sgtable() returns < 0, or 0.
While at it, sgt->orig_nents is actually used in __dma_map_sg_attrs()
invocation. Inside __dma_map_sg_attrs() a zero is returned if !dev->dma_mask.
Otherwise a result of either dma_direct_map_sg() or ops->map_sg() is returned.

Maybe that helps you debug the issue.

Regards,

Andrzej


      result = usb_sg_init(&sgr, sur40->usbdev,
          usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), 0,
          sgt->sgl, sgt->nents, sur40->pix_fmt.sizeimage, GFP_KERNEL);

However, when I put in some debug output, I noticed that sgt->nents is zero. Shouldn't that be initialized by vb2_dma_sg_plane_desc?

I tried to manually set it to 1 and got some partially-filled buffers back, so this seems the right way to go, but I couldn't find any other driver/example that uses this combination. Any hints
very welcome.

Best, Florian







[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux