Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node

[Bryan O'Donoghue]

On 13/06/2026 12:16, Atanas Filipov wrote:
> Thank you for the detailed explanation. Let me share my understanding of
> the shared upper-level blocks. They are exactly the reason we have
> frameworks like ICC with aggregate bandwidth voting, reference counting
> in the clock framework, and so on — the same applies to power domains. I
> do not think using shared resources is a problem when the drivers are
> correctly designed.
>
> We have actually validated this: we got CAMSS working alongside the
> Qualcomm downstream camera stack after fixing the shared resource
> management — something everyone considered nearly impossible at the time.
>
> On the CAMNOC and CPAS concern: if that coordination becomes necessary,
> the right fix is to address the resource management in both drivers
> independently, using the aggregate capabilities of the existing
> frameworks — not to introduce a
> hierarchical dependency between them. Moving JPEG under CAMSS does not
> solve the CAMNOC, clock and power domain coordination problems, it just
> papers over them.
>
> IMO the problem you are pointing at is more general than just CAMNOC — I
> would add priorities, QoS and other shared resources to the list as
> well. The answer to all of them is the same: correct use of the existing
> frameworks, not driver
> merging.
>
> On the idea of putting JPEG inside CAMSS with an external API: 

I haven't remotely suggested that.

> no engine or pipeline that produces YUV output, which is what the JPEG
> encoder needs as input. If JPEG moves into CAMSS without an external
> API, it becomes
> inaccessible to userspace. If it does expose one, we end up with a
> standalone interface anyway, just with an extra layer of indirection on top.

This is a very long winded way of saying no without acknowledging the 
core point that the DT should scribe the hardware the way it really is, 
as opposed to following software architecture preference.

It is the case JPEG lives inside of CAMSS. This is a fact of the 
hardware, the DT should express those facts not software preferences.

> afilipov
>
> On 6/13/2026 12:52 PM, Bryan O'Donoghue wrote:
> > On 13/06/2026 10:24, Atanas Filipov wrote:

Honestly - please quit top-posting. I'll be ignoring further top-posted 
email.

> And please no top posting !
>
> ---
> bod
>