Re: [PATCH v2 2/9] media: qcom: camss: Introduce SOF sequence tracking

[Bryan O'Donoghue]

On 03/11/2026 07:11, Gjorgji Rosikopulos (Consultant) wrote:
> > +
> > +void csid_sof_event(struct csid_device *csid, unsigned int id)
> > +{
> > +	struct v4l2_event event = {
> > +		.type = V4L2_EVENT_FRAME_SYNC,
> > +		.id = id,
> > +		.u.frame_sync.frame_sequence =
> > +			atomic_inc_return(&csid->sof_seq[id]),
> > +	};
> On first look this was looking strange because the id is used for the
> control id events not for frame sync. But on second thought it may make
> sense, but the question is how the userspace should interpret those ids?
> As of today userspace does not have any info for the VC and csid internal
> pipelines (so called lines). So with the current state of the code
> the id is VC which makes sense becouse the SOF/EOF packets are recieved
> based on VC. So i am thinking of two options:

The id is not the VC its the CSID:id/port/line-number. VCs don't change 
what this means; its the SOF event as seen by the CSI decoder - inside 
of which there may be multiple VC:DT combos.

This is also the case for PIX which is just another CSID 
port/id/line-number.

> 1. Move SOF event in vfe (rdi/pix sub-devs) we have per line sub-device
>     and will be well known to userspace for which line is reported.
>
> 2. Add and propose extension of videodev2 documentation that
>     id of frame_sync event types represents SOF per virtual channel.
>
> Personally i votoe for (1) because it will well fit with stream-api
> support and usespace will have clear understanding of the SOF to which
> stream belongs.

You know from the media graph which CSID drives which VFE:output so it 
is 100% possible to know which CSID:SOF relates to which VFE always. 
CSID::SOF is a hardware description of what the CSID decoder sees. I 
don't support mis-reporting it as a VFE event TBH.

More than that though, there is in-fact a VFE specific SOF/EOF and EPOCH 
event but these require the CSID feeding a frame into the VFE pipeline 
and the VFE moving through its own state-machine to process that frame.

So they are separate signals and separate logical events representing 
different things with different timings in hardware, meaning different 
things to userspace.

CSID:SOF is the thing you want to trigger off of if you are for example 
trying to align an IMU timestamp, not VFE SOF.

Feel free to propose VFE:SOF/EOF if it makes sense for VCs - I don't 
think I have a clear picture of what you want to do there - interested 
though.

---
bod