Hi Dan, On Thu, May 23, 2024 at 12:22:45PM +0100, Dan Scally wrote: > Hello > > On 23/05/2024 10:49, Laurent Pinchart wrote: > > On Thu, May 23, 2024 at 11:48:02AM +0200, Jacopo Mondi wrote: > > > On Thu, May 23, 2024 at 08:03:49AM GMT, Sakari Ailus wrote: > > > > Hi Daniel, > > > [snip] > > > > > > > > + > > > > > +static int mali_c55_vb2_start_streaming(struct vb2_queue *q, unsigned int count) > > > > > +{ > > > > > + struct mali_c55_cap_dev *cap_dev = q->drv_priv; > > > > > + struct mali_c55 *mali_c55 = cap_dev->mali_c55; > > > > > + struct mali_c55_resizer *rzr = cap_dev->rzr; > > > > > + struct mali_c55_isp *isp = &mali_c55->isp; > > > > > + int ret; > > > > > + > > > > > + guard(mutex)(&isp->lock); > > > > > + > > > > > + ret = pm_runtime_resume_and_get(mali_c55->dev); > > > > > + if (ret) > > > > > + return ret; > > > > > + > > > > > + ret = video_device_pipeline_start(&cap_dev->vdev, > > > > > + &cap_dev->mali_c55->pipe); > > > > > + if (ret) { > > > > > + dev_err(mali_c55->dev, "%s failed to start media pipeline\n", > > > > > + mali_c55_cap_dev_to_name(cap_dev)); > > > > > + goto err_pm_put; > > > > > + } > > > > > + > > > > > + mali_c55_cap_dev_stream_enable(cap_dev); > > > > > + mali_c55_rzr_start_stream(rzr); > > > > > + > > > > > + /* > > > > > + * We only start the ISP if we're the only capture device that's > > > > > + * streaming. Otherwise, it'll already be active. > > > > > + */ > > > > > + if (mali_c55->pipe.start_count == 1) { > > > > Do you start streaming on the sensor when the first video node does? > > > > > > > > This means that frames may be lost. E.g. the IPU6 ISYS driver only starts > > > > streaming on the sensor once all video nodes of the pipeline have been > > > > started. > > > How would you ever know which nodes will be started ? > > That can be done with link setup. Any video device that has an active > > link to the ISP would need to be started. > > > So if you don't want to stream data from one of the two capture nodes, you'd > need to disable the link between it and the resizer? That seems quite > clunky. Does it matter if one of them starts a frame or two later? As > opposed to both of them starting in sync a frame or two later? Video frames on a given queue are lost due to the driver implementation. I might consider that to be a driver bug. It's also true that some use cases could also benefit from the behaviour but on regular CSI-2 receivers that's probably quite rare. We'd need additional APIs to be able to convey the desired behaviour to the drivers. -- Regards, Sakari Ailus