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

[Gjorgji Rosikopulos (Consultant)]

On 11/3/2026 4:39 PM, Bryan O'Donoghue wrote:
> On 03/11/2026 14:35, Gjorgji Rosikopulos (Consultant) wrote:
>> Hi Bryan,
>>
>> On 11/3/2026 3:27 PM, Bryan O'Donoghue wrote:
>>> On 03/11/2026 13:13, Gjorgji Rosikopulos (Consultant) wrote:
>>>>>> 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.
>>>>
>>> Ah yes right I didn't really grok your point about .id = <integer> yes I
>>> agree with you, the assignment of port/line number should be dropped and
>>> left @ 0 - also what is the point of stuffing the line id into the .id
>>> field is not warranted.
>>>
>>> Agreed, that's a mistake.
>> Maybe this is a good point to raise. My concern is with the multistream patches:
>> the id field is also used when subscribing to an event,  so it would be useful
>> for userspace to identify which SOF it receives in a GMSL use case.
>>
>> We can leave the id as 0 for this series, but I think we should discuss how to
>> handle cases where two different cameras arrive on the same PHY over different
>> virtual channels—for example, one using RDI0 and the other RDI1.
>> For sure what is currently missing  in stream_api support is the events and
>> how they can be adopted to be per stream/streams.
>>
>> I hope that clarifies my intent—I’m not looking to hold up the series...
> 
> Off the top of my head VC kind of makes sense here.
> 
> OTOH it probably makes more sense - the VC differentiator in the VFE 
> delivering the data but I think we end up debating if the SOF triggered 
> in that VFE is the VFE SOF (yes) or he CSID (no) and if the VFE SOF 
> really transmits any real data user-space cares about...
> 
> Leaving this series @ 0 is compliant with existing stuff elsewhere and 
> lets us reason about the multi-stream stuff separately and potentially 
> as you say addressing a gap in what's upstream for multi-stream right now.

Yes i agree lets move the discussion of multi-stream support series 
where maybe it belongs, i am re-basing them right now most probably i will
re-base on top of this series as well.

I just want to add that we need to avoid sending multiple SOF's to userspace
with ID'0 when multiple RDI's are enabled in parallel. Or at least to have
explanation in the commit message that is expected behavior until we agree
out the multi-stream frame sync events.

~Gjorgji