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

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

On 7/7/2026 2:13 PM, Bryan O'Donoghue wrote:
> On 07/07/2026 11:55, Gjorgji Rosikopulos (Consultant) wrote:
>> Hi Vladimir, Bryan,
>>
>> On 7/6/2026 3:00 PM, Vladimir Zapolskiy wrote:
>>> On 7/6/26 13:12, Bryan O'Donoghue wrote:
>>>> On 06/07/2026 08:11, Atanas Filipov wrote:
>>>>> Note: The handling of shared camera subsystem resources (power 
>>>>> domains,
>>>>> interconnects) for child IP blocks is still an open design question.
>>>>
>>>> Why ?
>>>>
>>>> A device needs to vote on its own interconnect and power-domains on 
>>>> any
>>>> bus. A sub-device of another device may wish to ramp a clock for
>>>> whatever reason.
>>>
>>> Certainly a CAMSS device will vote on all needed to it resources, 
>>> some of
>>> which are shared and got their description under CAMSS device tree 
>>> node.
>>>
>>>> There is no "master" device in this block of devices - save perhaps 
>>>> for
>>>> the CSID mux / wrappers on some of these parts.
>>>>
>>>> We have shared resources like camera noc, system noc and external
>>>> clocks.
>>>>
>>>> Please include power-domains and interconnects.
>>>>
>>>
>>> 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.
>>>
>> The initial patch and work for JPEG was as independent driver. I agree
>> from hw perspective it is
>>
>> part of CAMSS subsystem and maybe from design perspective proper way is
>> to be child node not of the CAMSS.
>>
>> However the resources shared by both can be abstracted in other
>> frameworks, example ICC voting allows to have shared
>>
>> clocks which can have policy to keep the higher rate and satisfy both of
>> the HW's.
>>
>> So maybe it need to be decided:
>>
>> Do we want really additional logic for handling CAMSS resource of the
>> CAMMS sub-devices by the CAMSS driver and create separate CAMSS API,s
>
> No, agreed.
>
>> or we can use existing fw's for that. ICC, clock, OPP which all allow
>> sharing of the resources. Also there are cases where CAMSS and
>>
>> is not needed but JPEG encoder is: Example RTSP streaming or UVC
>> streaming which require jpeg encoder.
>
> Yes.
>
>>
>> Anyways my opinion:
>>
>> 1. CAMSS is not prepared and not ready to handle child devices, only the
>> populate child nodes is not enough. I think it is little bit mess,
>>
>> some of the HW;s CSID, IFE etc are instantiated directly from CAMSS and
>> jpeg and Ope are described as child nodes.
>
> That's not the strategy.
>
> The strategy is gradual transition from monolith to bus.
>
> https://lore.kernel.org/all/d5407ab1-1af7-4678-ae67-5cf30ce8fa4b@kernel.org/ 
>
Sorry i have missed that. I understand now the direction which has been 
agreed on.
>
>
>> 2. Jpeg on its own currently does not have any dependency with CAMSS
>> driver code. It can use shared resources without issue and leave
>>
>> the ICC, clock and other frameworks to do the job.
>
> Yes as a fully self-described sub-node so that we can do 
> compat="camss-bus" with the minimal amount of additional churn on top.
>
> Make JPEG a distinct standlone node now, and you preclude the bus - 
> you have to make the argument to Krzysztof, Rob and Conor that "the 
> old binding was wrong but let me away with a change to it now"
>
> Not an argument I will be making ;)
>
> We should put the JPEG, OPE, ICP as sub-nodes of compat=camss so that 
> we can make
>
> camera-bus {
>     compat=camss
>     power-domains=<whatever is common>
>     csid {
>         compat=csid;
>     }
>     jpeg {
>         compat=jpeg;
>     }
> }
>
> a reality.
>
> Put jpeg at the same level as camera-bus and you basically preclude 
> that model.

Ok understood, lets wait for more review comments, and move to this 
model for the next patchset. Thanks for the clarification :-)

~Gjorgji