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

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

On 11/3/2026 2:30 PM, Gjorgji Rosikopulos (Consultant) wrote:
> 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.

Just an proposal if it is decided the id to be used, it make sense to contain
stream_id. Then userspace based on the stream routing can map SOF
for the stream of interest. But the API for retrieving stream_id is still
experimental and i am not sure if will be well accepted.

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