Re: [PATCH v4 5/5] media: qcom: jpeg: Add Qualcomm JPEG V4L2 encoder
From: Vladimir Zapolskiy
Date: Wed Jul 08 2026 - 12:43:38 EST
On 7/8/26 18:44, Gjorgji Rosikopulos (Consultant) wrote:
Hi Vlad, Dmitry
On 7/8/2026 3:01 PM, Vladimir Zapolskiy wrote:
On 7/8/26 14:35, Dmitry Baryshkov wrote:
On Wed, Jul 08, 2026 at 01:28:46PM +0300, Vladimir Zapolskiy wrote:
Hi Gjorgji.
On 7/8/26 12:32, Gjorgji Rosikopulos (Consultant) wrote:
Hi Vlad,
On 7/8/2026 11:47 AM, Vladimir Zapolskiy wrote:
Hi Gjorgji.I agree but there should be an API for icc voting which Jpeg need to use,
On 7/7/26 16:24, Gjorgji Rosikopulos (Consultant) wrote:
Hi Vlad,
On 7/6/2026 10:46 AM, Vladimir Zapolskiy wrote:
<snip>
+ interconnects = <&gem_noc MASTER_AMPSS_M0
QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG
QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF
QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0
QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF
QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI_CH0
QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-cfg",
+ "hf-mnoc",
+ "sf-mnoc";
This is the topic, which may raise a disagreement, but I'll repeat my
position about the need to remove all "CAMSS bus" specific resources from
the device node, they are found and should be allocated on parent's side.
The interconnect has functionality to handle bw requests from different
clients.
Yes the best will be to have camss interconnect, so jpeg and other hw's
to vote
on that (actually it is possible in icc framework) but what is the
benefit of moving
those to camss? Is it not better to create camss icc. I understand
you want them to be on parent side. But how to vote on bw? Most of the
time it
Let's concentrate on hardware bindings description, no APIs, votes etc.
at this point of discussion.
currently it is fixed to some values, but voting need to become dynamic
at some point of time, because it depends on runtime parameters, resolution
format etc.>
Sure, but I believe it's quite clear that any software implementation
should be discussed only when the hardware description is fixed.
There is SM8250 CAMSS device, which serves as a hierarchical parent (orI agree the device tree is best to represent real hw topology. >
could be considered as a "bus" device) to this new JPEG encoder device
and probably to a number of future IPs under CAMSS. All CAMSS sub-devices
get hardware descriptions as children device tree nodes of CAMSS parent
device tree node naturally.
Well, it's not just the best, it's the only possible way.
Copying of the same identical information about clocks, interconnectsHere also i tend to agree.>
and power domains from the hierarchical parent device to children devices
is not needed, and practically it only lowers signal-to-noise ratio.
Since information about the actual defect in hardware description is
reported, the problem can and should be avoided, the handling of a better
hardware description and dealing with any kind of complexity will be done
in the CAMSS and/or CAMSS children drivers.
If you need to get a bit more formal point of view on the matter, I'd
prefer to see descriptions of hardware properties organised in a tree
topology rather than in the originally proposed star topology. By doing
it the system complexity is reduced from N to 1.
Maybe I'm missing the whole picture of your proposal, but I want to add my
point of view on this matter.
The JPEG encoder HW block has no dependency on the other processing HW
blocks in the camera subsystem
It shares resources like camnoc, clocks, GDSC, etc.,
but does not share anything with the other HW processing blocks. For me,
the JPEG driver should not have SW architectural dependencies on CAMSS.
To move forward there should be a clear answer to a simple question,
does Qualcomm JPEG encoder IP belong to CAMSS group of devices or not?
If no, then JPEG encoder device tree node shall be located outside of
CAMSS device tree node, all resources needed for JPEG encoder device
operation get their descrition in this stand-alone device tree node.
If yes, then JPEG encoder device tree node is a child of CAMSS "bus"
device tree node, and only resources specific to JPEG encoder device
are described in its device tree node, because other resources are
already described in the parent device tree node.
2c from my side (for both sides of the discussion). Please keep it
separate, if the block simply uses the resource which is also used by
the parent (e.g. there are no special requirements on the AHB or sleep
clocks) or if the device needs to actuall cast a vote on a particular
resource (e.g. for this to function at this performance level, the MMCX
needs to be at the turbo level OR for this to function at this
performance level it will use 123 MHz of the AXI clock). In the latter
case the resources must be described as a part of the device.
Even this "description as a part of the device" might be not quite
necessary in whole, let me try to explain.
No doubts resource usage policies specific to a child device should
be naturally described in child device tree node, and it's applicable
to any kind of hardware policies (like opp tables etc.), but a list
of needed hardware resources still can be obtained (also by a driver)
from the parent, whenever it is found applicable and unambiguous.
If that is the intention than that can be done without significant
changes in the jpeg driver.
I won't expect any complexity on driver's side, but firstly it would make
sense to get to the agreement how to describe hardware in a proper way.
So far I haven't seen any technical objections to the approach I promote,
and since it gives complete and simpler hardware description, it might be
preferred over anything else, it's still under discussion though.
This is to separate planes of hardware dependencies and policies/controls
needed for hardware usage.
Currently JPEG is part of the "camera peripheral block and support" (CPAS) in
the "camera subsystem" (CAMSS), CCI is there as well. Then maybe we should move
i2c-qcom-cci into CAMSS. Note that CCI can be used without CAMSS, and it can be
used for some I2C peripheral devices which are not camera-related.
Pracical usage of CCI does not define its exact placement (grouping)
on the SoC.
Also, to reflect the exact HW configuration, maybe we need a CPAS sub-node.
One point of view: in the hardware configuration there are no dedicated
camera subsystem block (CAMSS) registers (based on my knowledge).
Those are a group of HW blocks belonging to the camera subsystem which share
some resources, including camnoc, clocks, GDSC, etc.
There is a number of dt bindings which introduce "Camera Subsystem" term,
see qcom,x1e80100-camss.yaml or qcom,sm8250-camss.yaml etc. Whatever it
is, and if there is a justification for such device tree binding to exist,
it sounds it should be rationally and prudently exploited, for instance
this node already holds phandles to "shared resources", this cannot be
removed, but fortunately it can be reused.
So, based on Vlad's proposal, the changes in the different drivers will just
be about where they take some resources from (parent device) or the current
device — so the changes in the drivers will not be significant.
I hope so, and my anticipation is that dt bindings will become simpler.
If one day it becomes obvious that the properties I vote for removal are
utterly needed, they can be added without breaking dtb to kernel ABI.
--
Best wishes,
Vladimir