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

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

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.

Over time we can move the bindings to a model where the only thing in 
CAMSS is a top-level bus like declaration but _right_now_ what you would 
do is create an artificial dependency on say CSIPHY for JPEG.

> This is exactly identical to the MDSS case.
> I was hoping this was clear after N other similar threads.
When we split IFE, CSID etc up into their own individual nodes it would 
be possible to model as for argument sake

compat = "camss-bus";
power-domains = <TITAN_TOP_GDSC>;

jpeg@x {
	power-domains = <JPEG_GDSC>, <MMCX>, <MXC>;
};

What I'm saying here is do this

compat = "camss";
regs = ife, csid; // exisiting bindings for the last ~ 11 years
power-domains = <TITAN_TOP_GDSC>;

jpeg@x {
	power-domains = <TITAN_TOP_GDSC>, <JPEG_GDSC>, <MMCX>, <MXC>;
};

Otherwise you create entirely artificial dependencies between IFE, 
CSIPHY and JPEG, OPE et al.

And BTW if/when we get to the camss-bus stage of things having 
TITAN_TOP_GDSC listed in OPE and JPEG is a very small price to pay.

We've already agreed to gradually transition the bindings instead of go 
for a big-band integration several times.

---
bod