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

[Bryan O'Donoghue <bod@kernel.org>]

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@nxsw.ie/
>>>>>
>>>>>        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