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

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

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

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.

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.

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.

Also i dont see the reason to mix the both works. Lets have it jpeg as 
separate independend driver and the create series and rework CAMSS

to child nodes and move all existing sub-devices as child nodes, and 
then move the jpeg and Ope.

Regards,

~Gjorgji