Re: [PATCH v3 00/11] Add SOF sequence logic

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

Hi Bryan,

The whole series were verified on RB8 board (SA8775P).

Tested-by: Gjorgji Rosikopulos <gjorgji.rosikopulos@oss.qualcomm.com>

~Gjorgji

On 11/7/2026 3:01 AM, bryan.odonoghue@linaro.org wrote:
> v3:
> - Added CSID-340 patches from Loic wit permission - Loic
> - Explains the initial -1. - Loic
> - Drops the .id field enumeration - Gjorgji
> - Accumulates RB as indicated.
> - Link to v2: https://patch.msgid.link/20261102-v4l2-frame-sync-v2-0-25cbed7a772f@kernel.org
> 
> v2:
> - Amends series title to drop EOF
> - Drops EOF inclusion until we actually use it for stats production seq_no - Gjorgji, bod
> - Moves QoS into pm_runtime() callbacks - Loic
> - Switches on vb.sequence change for every SoC the silicon enabling code
>   supports - bod, Loic
> - Link to v1: https://patch.msgid.link/20261029-v4l2-frame-sync-v1-0-d37992559c58@kernel.org
> 
> v1:
> 
> This series enables SOF AND EOF event tracking making use of both events.
> Whilst the code is actually very simple the functionality we want to build
> off of that simple code is not.
> 
> - SOF
>   Serves two functions. Firstly. Informing user-space of CSID SOF events.
>   Standard Linux V4L2_EVENT_FRAME_SYNC is trigger from this event.
>   User-space wants to capture this trigger because it allows user-space to
>   better align the time a frame begins to events elsewhere such as IMU
>   event timestamps.
> 
>   That functionality is directly applicable in this series.
> 
>   However we will also build on the SOF event in later patches to allow us
>   to begin programming of shadow-registers for the next camera frame.
> 
>   When the EOF event happens, we switch from one shadow bank to the next.
>   This is only possible if you have the SOF event.
> 
>   So SOF serves the immediate purpose of timestamp alignment in user-space
>   as well as the 'evil plan' to trigger off of it programming camera
>   parameters for the next frame.
> 
> - EOF
>   EOF even on its own is useful because it allows us to increment
>   vb.sequence for each frame as per the spec not just when we have
>   buffer-data.
> 
> There is another purpose to having an SOF and EOF event with sequence
> numbers and that is.
> 
> User-space submits a parameters buffer. Kernel accepts that parameters
> buffer but can make no guarantee about _when_ the entire buffer will be
> applied.
> 
> So when kernel finishes application of the entire params sequence the
> returned buffer contains the sequence number - from the EOF tracking which
> informs user-space _which_ frame vb.sequence its given params buffer was
> applied.
> 
> Similarly when kernel produces a statistics buffer that buffer will have a
> sequence number - and that sequence number will align to the frame sequence
> number that the statistics describe.
> 
> Thus SOF/EOF tracking is fundamental to passing parameters, returning
> statistics to user-space and for the IPA algorithm in user-space to
> understand which stats, params and frames are related.
> 
> The first patch in the series addresses a corner-case when a quiescent
> system can take quite a while to wake from idle, too long in fact such that
> the SOF event is effectively missed.
> 
> On 'normal' systems doing lots of things, this is not a problem we would
> see however on my test X1-CRD system running from ramdisk - there's
> basically nothing else happening and the wake-time becomes apparent.
> 
> This is not strictly speaking a bugfix since right now nothing in CAMSS
> cares about SOF or EOF so if we take an additional 2.5 ms to process a
> data-buffer on a fully quiescent system, that's not the end of the world.
> 
> OTOH as soon as you start to care about SOF/EOF then missing those events
> is no bueno.
> 
> The CPU latency value chosen is 100% stolen from IPU7 which seems like a
> good starting point - the stealing obviously - and happens to also work.
> 
> This series is really an enabling series for more work to come but even on
> its own is an improvement on the current situation.
> 
> Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
> ---
> Bryan O'Donoghue (9):
>       media: qcom: camss: Introduce CPU latency QoS during streaming
>       media: qcom: camss: Introduce SOF sequence tracking
>       media: qcom: camss: Use SOF sequence tracking for vb.sequence
>       media: qcom: camss: csid-gen3: Enable RDI SOF driving
>       media: qcom: camss: csid-680: Enable RDI SOF tracking
>       media: qcom: camss: csid-gen2: Enable RDI SOF tracking
>       media: qcom: camss: Switch on frame_sync_en logic for csid-gen3.
>       media: qcom: camss: Switch on frame_sync_en for x1e/x2e
>       media: qcom: camss: Switch on frame_sync_en for csid-gen2
> 
> Loic Poulain (2):
>       media: qcom: camss: csid-340: Enable RDI SOF tracking
>       media: qcom: camss: Switch on frame_sync_en for csid-340
> 
>  drivers/media/platform/qcom/camss/camss-csid-340.c | 39 ++++++++++++-
>  drivers/media/platform/qcom/camss/camss-csid-680.c | 18 ++++++
>  .../media/platform/qcom/camss/camss-csid-gen2.c    | 15 +++++
>  .../media/platform/qcom/camss/camss-csid-gen3.c    | 27 +++++++++
>  drivers/media/platform/qcom/camss/camss-csid.c     | 68 +++++++++++++++++++++-
>  drivers/media/platform/qcom/camss/camss-csid.h     | 21 +++++++
>  drivers/media/platform/qcom/camss/camss-vfe-17x.c  |  5 +-
>  drivers/media/platform/qcom/camss/camss-vfe.c      |  9 ++-
>  drivers/media/platform/qcom/camss/camss-vfe.h      |  1 +
>  drivers/media/platform/qcom/camss/camss.c          | 65 ++++++++++++++++++++-
>  drivers/media/platform/qcom/camss/camss.h          |  2 +
>  11 files changed, 265 insertions(+), 5 deletions(-)
> ---
> base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
> change-id: 20261029-v4l2-frame-sync-0d6fb94ab6e6
> 
> Best regards,
> --  
> ---
> bod