Re: [PATCH v4 0/5] Add Qualcomm JPEG V4L2 encoder for SM8250

[Bryan O'Donoghue]

On 07/07/2026 11:11, Konrad Dybcio wrote:
> On 7/7/26 12:00 PM, Bryan O'Donoghue wrote:
> > On 07/07/2026 10:24, Konrad Dybcio wrote:
> > > On 7/6/26 3:37 PM, Bryan O'Donoghue wrote:
> > > > On 06/07/2026 14:02, Vladimir Zapolskiy wrote:
> >
> > > > > > The idea is to make all of these peers, eventually. Not particular block
> > > > > > owns the TITAN_TOP_GDSC - the entire CAMSS block is a collapsible block.
> > > > >
> > > > > The statement provides the same information as before, e.g. it's found here:
> > > > >
> > > > > https://lore.kernel.org/linux-media/fbc018f5- c025-4747-85f2-53b45b0f0496@xxxxxxx/
> > > > >
> > > > >        There's no functional linkage between CAMSS/IFE and JPEG - they are
> > > > >        peers within the CAMSS power-island.
> > > > >
> > > > > Thus "the CAMSS power-island" exists, and it got its hardware description
> > > > > as the CAMSS top device tree node, and TITAN_TOP_GDSC power domain is
> > > > > a natural resource of all devices on "CAMSS power-island",
> > > >
> > > > Vlad honestly, TITAN_TOP_GDSC is provided to the CAMSS island - all of the nodes within it depend on that and it is _external_ to the block.
> > > >
> > > > There is a CSID MUX on some SOC other than that I'll restate it again, I'm not sure why you won't accept it.
> > > >
> > > > There is no dependency between JPEG and IFE, one is _not_ subordinate to the other and trying to find ways to invalidate that statement runs counter to the facts.
> > >
> > > They are all subordinate to CAMSS_TOP - Vlad indeed said they are
> > > peers (i.e. there's no co-dependence between them specifically, but
> > > their parent is shared).
> > >
> > > You can't use any of these IP blocks if you don't first power up
> > > TOP because of the physical layout.
> >
> > Yes and I'm asking for TOP to be listed in each of the subordinate nodes for reasons given below.
> >
> > But unlike MDSS - OPE for example doesn't require IFE or CSID to do its job.
>
> MDSS also contains a number of unrelated peers - e.g. DP and DSI
> controllers.

OK, I can see how this thread is confusing.

The idea is to start to declare sub-nodes "on the road" to making camss 
into a bus. The legacy binding we have is really for the IFE domain - 
that is CSIPHY, CSID, IFE.

Right now the camss binding describes those things - so linking say OPE 
or JPEG back to the thing that describes those isn't right.

OTOH we _want_ to make the top-level binding into a bus, we've discussed 
that several times.

To transition from monolith IFE-domain only, to camss-bus, we should 
have the sub-nodes fully describe themselves as "camss-bus" doesn't 
exist yet.

Once we have compat="camss-bus" then fine, make that linkage, I fully 
support that.

That roadmap BTW is why I'm asking Antanas and Loic to make JPEG and OPE 
sub-nodes of camss - but make them complete sub-nodes - power-domains, 
clocks, nocs, including the TOP_GDSC.

It means we can work on splitting apart the existing camss node in 
isolation to make CSID, IFE as peer sub-nodes.

We definitely shouldn't be making those sub-nodes dependent on 
compat="camss" but they definitely will be dependent once we finish 
making compat="camss-bus".

When that is done I fully agree TOP_GDSC belongs in the bus node, like MDSS.

I hope that makes sense.

---
bod