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

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 7/6/26 3:37 PM, Bryan O'Donoghue wrote:
> On 06/07/2026 14:02, Vladimir Zapolskiy wrote:
>>>>
>>>> Why? The common power domain and interconnects have already been
>>>> described as resources of the parent CAMSS device, there is no need
>>>> to duplicate descriptions in every child device tree node of CAMSS.
>>>
>>> CSID, IFE etc are not parents of the JPEG encoder.

This is either a strawman argument or a misinterpretation of what
is being argued.

>>>
>>> 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.

This is exactly identical to the MDSS case.
I was hoping this was clear after N other similar threads.

Konrad