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

[Konrad Dybcio]

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.

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

I don't see where such a dependency is created.

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

Patch 1 (+ devm_of_platform_populate(dev);) makes camss-bus a reality
today


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

JPEG isn't a block that's described today so I see no blockers here

Konrad