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); >>> >>> 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 >> >
