Re: [PATCH v4 0/5] Add Qualcomm JPEG V4L2 encoder for SM8250
From: Gjorgji Rosikopulos (Consultant)
Date: Tue Jul 07 2026 - 07:23:45 EST
On 7/7/2026 2:13 PM, Bryan O'Donoghue wrote:
On 07/07/2026 11:55, Gjorgji Rosikopulos (Consultant) wrote:Sorry i have missed that. I understand now the direction which has been agreed on.
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
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.
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@xxxxxxxxxx/
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