Re: [PATCH v4 0/5] Add Qualcomm JPEG V4L2 encoder for SM8250
From: Gjorgji Rosikopulos (Consultant)
Date: Tue Jul 07 2026 - 06:55:50 EST
Hi Vladimir, Bryan,
On 7/6/2026 3:00 PM, Vladimir Zapolskiy wrote:
On 7/6/26 13:12, Bryan O'Donoghue wrote:The initial patch and work for JPEG was as independent driver. I agree from hw perspective it is
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.
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