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

[Vladimir Zapolskiy]

On 6/19/26 17:38, Konrad Dybcio wrote:
> On 6/14/26 3:13 AM, Bryan O'Donoghue wrote:
> > 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.
>
> That's also precisely what the "Tree" part is about - CAMSS is essentially
> a bus (as evidenced by the existence of a set of resources, like the
> AHB/CPAS clocks, the TITAN_TOP GDSC and the interconnect paths that gate
> access to everything on it), just like MDSS essentially is a bus. The JPEG

I also agree that CAMSS should be thought as a bus, and therefore a child IP
shall both a) be described as a subnode, b) get shared resources on parent's
side like PDs and clocks avoiding unnecessary repeated description in its
own node.

I believe this general notice should be applicable to all CAMSS IPs, and I
repeat it here, because there was a disagreement about it somewhere else.

> encoder, just like all the other blocks are then devices on that bus,
> logically belonging to the CAMSS node

--
Best wishes,
Vladimir