jmondi: re: https://patchwork.linuxtv.org/project/linux-media/list/?series=5847
It's on my todo list, but I didn't manage to review it before my vacation. I hope to get to it this week, but it won't make it for 5.15 (too late for that).
hverkuil: no pressure! thanks for replying to such an old message :)
subdev_do_ioctl_lock() takes vdev->lock if available, but I can't figure out how to set that lock. how is that supposed to be used by the drivers?
tomba: I don't think it's supposed to :-)
it comes from the fact that we reuse video_device internally in v4l2_subdev
(I had initially proposed splitting video_device in two, with a part that manages the devnode, and a part that manages the V4L2 video device API itself, but that wasn't accepted)
there's a locking mechanism there, it has been blindly plumbed in subdev_do_ioctl_lock(), but I don't think we've ever tried to make use of it
pinchartl: ok, thanks
Can anyone answer to my question? If no driver actually support this control id, shall we make the specification about it at this time? https://lore.kernel.org/linux-media/CAO5uPHM-n9Rh6MPTNoyzOGR-jV5-qy3zj67MZuSM8uaAN=RNXw@mail.gmail.com/
svarbanov: ^^^
svarbanov: didn't you have venus patches pending adding support for these controls?
does anybody know if there are newer USB cameras that use USB3 to transmit raw 1080p/4K frames? USB3 should have sufficient bandwidth
so far, the cams that I used were USB2 based, and I had to rely on mjpeg transmission to get 30fps at 1080p
and if there are USB3 cameras, do these require something newer than the UVC standard?
I suppose the linux uvcvideo implementation should support UVC 1.5 .. ?
dv_: the logitech brio can do 1080p @30fps in YUYV according to its UVC descriptors
I'm sure there are others
ah - yes, that's a USB3 one
it's supported by the uvcvideo driver
great, thanks
there's the logitech streamcam too, 1080p @30fps (and 2304x1296 @5fps)
oh, and can usb3 cams stream frames as a whole instead of per-packet?
how do you mean ?
more specifically, can captured frames in USB3 cams be read by simple DMA (that is, not scatter-gather)?
USB is packet-based
no
there will always be a memcpy
so, any SoC that does not have SG-DMA will use CPU% when capturing frames via USB
that's inherent to the uvc protocol
significant CPU% that is
even USB controllers that have scatter-gather DMA support won't help
packets are prefixed by a header
the size of the header is variable and unknown in advance
oh so they need to be parsed
yes
the data portion of each packet has to be copied to the image buffer
so ... capturing with USB3 webcams that deliver something like 1080p60 will always cause significant CPU usage
it would be possible to implement a USB host controller with support for UVC, splitting headers and image data in two different buffers, but I'm not aware of such a device
on an embedded SoC that is
yes, it will always cause significant CPU usage
hm I suppose that is an argument for using MJPEG even in newer webcams then
we've actually deferred the copy to a workqueue in order to parallelize copy operations between multiple CPUs
for the logitech brio
a single CPU wasn't able to cope
since the MJPEG decoding can be done by a hw decoder and decode into physically contiguous mem
I'd have thought that USB3 and newer would introduce _something_ to make it easier to use bulk DMA transfers
I guess you could use a generic DMA controller to pick the buffers apart too, though the setup/interrupt costs might be too heavy to be worthwhile.
the buffers are fairly small :-S
Not small enough!
:-)