mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Gjorgji Rosikopulos (Consultant)" <gjorgji.rosikopulos@oss.qualcomm.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
	Loic Poulain <loic.poulain@oss.qualcomm.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Bryan O'Donoghue <bod@kernel.org>
Subject: Re: [PATCH 00/14] Add SOF/EOF sequence logic
Date: Thu, 29 Oct 2026 16:51:42 +0200	[thread overview]
Message-ID: <a3aba02c-03fc-4386-952b-d53fccd65465@oss.qualcomm.com> (raw)
In-Reply-To: <22d2cfcd-045d-48dd-bbde-c1ac2d958737@linaro.org>



On 10/29/2026 4:44 PM, Bryan O'Donoghue wrote:
> On 29/10/2026 13:28, Gjorgji Rosikopulos (Consultant) wrote:
>> Hi Bryan,
>>
>> On 10/29/2026 11:55 AM,bryan.odonoghue@linaro.org wrote:
>>> 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.
>>>
>> It is great to finally have V4L2_EVENT_FRAME_SYNC support in CAMSS. 🙂
>>
>> I would like to share my opinion on tagging vb.sequence at EOF.
>>
>> The EOF event is received from the CSID decoder when the EOF short packet
>> is decoded. In contrast, buffer completion is reported when the write
>> master has finished writing the corresponding buffer.
>>
>> Because the processing pipeline includes buffering and line buffers,
>> buf_done on the pixel path may be received after the EOF.
>> Conversely, when cropping is enabled on an output, buf_done may be
>> received before EOF.
>>
>> That is why using EOF to assign the buffer sequence may result in inconsistent
>> sequence numbers across buffers.
>>
>> I would propose:
>>
>> SOF
>> Increment the frame sequence and generate the V4L2_EVENT_FRAME_SYNC event
>> for userspace.
>>
>> REG_UPDATE
>> Once REG_UPDATE occurs, we have a guarantee that the configuration for the
>> new frame has been latched. At this point, we can iterate over all active
>> buffers being processed and assign them the current sequence number.
>> The bus-write active-status register indicates which address is currently being
>> processed by the bus-write engine and could also be used to detect frame skips,
>> if necessary.
>>
>> BUSWR_DONE
>> Complete the corresponding buffer as usual. Optionally, we can verify whether its
>> sequence has already been updated. If it has not, we can determine how the buffer
>> should be handled.
>>
>> This approach ties the buffer sequence to the point at which the frame configuration
>> is latched, rather than to the arrival of EOF, which may not be ordered consistently
>> with buffer completion.
> 
> Come to think of it, I'm not entirely sure an EOF or reg-update 
> additional variable is required.
> 
> SOF.seq should do.
> 
> - Reading SOF.seq @ crop is fine because the SOF.seq always preceds
> - Reading SOF.seq @ buf_done is fine ditto
> - Reading SOF.seq for params return stamping is correct
> - Reading SOF.seq for stats frame correlation is also correct
> 
> We want the EOF signal but we don't need a second seqno to accompany. 
> And with one source of seq truth we don't need to change the point at 
> which we latch since pre-frame-drop SOF < everythign else.

I agree. REG_UPDATE is only necessary if we decide to use the bus-write active-status
register to determine which buffer is currently being processed. This can give real guarantee
that we are not missing something on heavily loaded systems when irq-s were disabled for some time,
in that case sequence may not be in sync anyway...

~Gjorgji

      reply	other threads:[~2026-10-29 14:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  9:55 bryan.odonoghue
2026-10-29  9:55 ` [PATCH 01/14] media: qcom: camss: Introduce CPU latency QoS during streaming bryan.odonoghue
2026-10-29 10:10   ` Loic Poulain
2026-10-29 11:03     ` Bryan O'Donoghue
2026-10-29  9:55 ` [PATCH 02/14] media: qcom: camss: vfe: Add eof_seq to vfe_line bryan.odonoghue
2026-10-29  9:55 ` [PATCH 03/14] media: qcom: camss: Introduce SOF sequence tracking bryan.odonoghue
2026-10-29  9:55 ` [PATCH 04/14] media: qcom: camss: Introduce EOF " bryan.odonoghue
2026-10-29  9:55 ` [PATCH 05/14] media: qcom: camss: csid-gen3: Enable RDI SOF driving bryan.odonoghue
2026-10-29 15:43   ` Loic Poulain
2026-10-29 15:46     ` Loic Poulain
2026-10-29 15:49       ` Bryan O'Donoghue
2026-10-29 16:25         ` Gjorgji Rosikopulos (Consultant)
2026-10-29 15:47     ` Bryan O'Donoghue
2026-10-29  9:55 ` [PATCH 06/14] media: qcom: camss: csid-gen3: Enable RDI EOF tracking bryan.odonoghue
2026-10-29  9:55 ` [PATCH 07/14] media: qcom: camss: csid-680: Enable RDI SOF tracking bryan.odonoghue
2026-10-29  9:55 ` [PATCH 08/14] media: qcom: camss: csid-680: Enable RDI EOF tracking bryan.odonoghue
2026-10-29  9:55 ` [PATCH 09/14] media: qcom: camss: csid-gen2: Enable RDI SOF tracking bryan.odonoghue
2026-10-29  9:55 ` [PATCH 10/14] media: qcom: camss: csid-gen2: Enable RDI EOF tracking bryan.odonoghue
2026-10-29  9:55 ` [PATCH 11/14] media: qcom: camss: Switch on frame_sync_en logic for sm8650 bryan.odonoghue
2026-10-29  9:55 ` [PATCH 12/14] media: qcom: camss: Switch on frame_sync_en for x1e/x2e bryan.odonoghue
2026-10-29  9:55 ` [PATCH 13/14] media: qcom: camss: Switch on frame_sync_en for sm8250 bryan.odonoghue
2026-10-29  9:55 ` [PATCH 14/14] media: qcom: camss: Switch on frame_sync_en for sdm845 bryan.odonoghue
2026-10-29 13:28 ` [PATCH 00/14] Add SOF/EOF sequence logic Gjorgji Rosikopulos (Consultant)
2026-10-29 14:44   ` Bryan O'Donoghue
2026-10-29 14:51     ` Gjorgji Rosikopulos (Consultant) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a3aba02c-03fc-4386-952b-d53fccd65465@oss.qualcomm.com \
    --to=gjorgji.rosikopulos@oss.qualcomm.com \
    --cc=bod@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=mchehab@kernel.org \
    --cc=vladimir.zapolskiy@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®