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

["Gjorgji Rosikopulos (Consultant)" <gjorgji.rosikopulos@oss.qualcomm.com>]

Hi Bryan,

On 7/7/2026 1: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.
>
> 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.

Just to clarify, from the jpeg driver perspective does not make any 
difference whether is child node of camss or other node. For sure it 
will be explained in binding documentation,

but just in theory we may have jpeg encoder in future platforms without 
camera sub-system. So where jpeg is placed is strictly platform 
depended. Do you agree to have series just

for the jpeg driver as it should be, the changes in camss and device 
tree changes for this platform will be not part of this patch series but 
send as additional one. Or you prefer

everything to have in this patch series with different order of the changes.

~Gjorgji

>
> ---
> bod
>