Re: [PATCH 01/14] media: qcom: camss: Introduce CPU latency QoS during streaming

[Bryan O'Donoghue]

On 29/10/2026 10:10, Loic Poulain wrote:
> > +
> > +void camss_cpu_latency_get(struct camss *camss)
> > +{
> > +       mutex_lock(&camss->cpu_latency_lock);
> > +
> > +       if (camss->cpu_latency_users++ == 0)
> > +               cpu_latency_qos_add_request(&camss->cpu_latency,
> > +                                           CAMSS_CPU_LATENCY_US);
> > +
> > +       mutex_unlock(&camss->cpu_latency_lock);
> I agree that we need such a latency request mechanism, but the current
> approach requires additional logic and locking.
>
> What about one of the following alternatives instead?
> - Move the latency request handling to the suspend/resume paths. The
> request lifecycle would then be naturally serialized and balanced, and
> in practice there are very few cases where the device is resumed but
> not actively streaming.
> - Alternatively, add a dedicated latency request instance to each VFE
> and let each VFE manage its own request during start/stop. That would
> keep the ownership local to the VFE and avoid the need for extra
> locking altogether.
>
> Regards,
> Loic

yeah both of those would work.

I'll have a think about that, thx

---
bod