On Tue, Jul 16, 2024 at 11:13:24PM +0100, Bryan O'Donoghue wrote: > The use_count check was introduced so that multiple concurrent Raw Data > Interfaces RDIs could be driven by different virtual channels VCs on the > CSIPHY input driving the video pipeline. > > This is an invalid use of use_count though as use_count pertains to the > number of times a video entity has been opened by user-space not the number > of active streams. > > If use_count and stream-on count don't agree then stop_streaming() will > break as is currently the case and has become apparent when using CAMSS > with libcamera's released softisp 0.3. > > The use of use_count like this is a bit hacky and right now breaks regular > usage of CAMSS for a single stream case. As an example the "qcam" > application in libcamera will fail with an -EBUSY result on stream stop and > cannot then subsequently be restarted. No, stopping qcam results in the splat below, and then it cannot be started again and any attempts to do so fails with -EBUSY. > The kernel log for this fault looks like this: > > [ 1265.509831] WARNING: CPU: 5 PID: 919 at drivers/media/common/videobuf2/videobuf2-core.c:2183 __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] > ... > [ 1265.510630] Call trace: > [ 1265.510636] __vb2_queue_cancel+0x230/0x2c8 [videobuf2_common] > [ 1265.510648] vb2_core_streamoff+0x24/0xcc [videobuf2_common] > [ 1265.510660] vb2_ioctl_streamoff+0x5c/0xa8 [videobuf2_v4l2] > [ 1265.510673] v4l_streamoff+0x24/0x30 [videodev] > [ 1265.510707] __video_do_ioctl+0x190/0x3f4 [videodev] > [ 1265.510732] video_usercopy+0x304/0x8c4 [videodev] > [ 1265.510757] video_ioctl2+0x18/0x34 [videodev] > [ 1265.510782] v4l2_ioctl+0x40/0x60 [videodev] > ... > [ 1265.510944] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state > [ 1265.511175] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 1 in active state > [ 1265.511398] videobuf2_common: driver bug: stop_streaming operation is leaving buffer 2 in active st Johan
