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

["Gjorgji Rosikopulos (Consultant)" <gjorgji.rosikopulos@oss.qualcomm.com>]

Hi Bryan,

On 11/3/2026 2:19 PM, Bryan O'Donoghue wrote:
> 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.

Yes i know that, but does the userpsace developer knows based on the API and
documentation provided? Or he needs to ask the linux media?

We have some kind of id which is mapped to line and that is known just
by the driver, if you can point other drivers using id for frame sync
events will be helpfull. 


> 
> 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.

Well that make sense i agree that it make sense to be part of the csid
but it should be documented somewhere, maybe proper thing to do is update
the comment in videodev2.h and update the documentation for camss driver.

> 
> 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.

I am not proposing that, but from the current state of the code each line is mapped
to different VC (before multistream patches). So this means as of today, id can
be mapped to VC. Anyway my point is to either document or open discussion for
"id" field in v4l2_event structure when event type is V4L2_EVENT_FRAME_SYNC. If
not document for me it looks like some kind of a workaround just for our own driver.

~Gjorgji

> 
> ---
> bod