Re: [PATCH v3 2/4] dt-bindings: media: qcom: Add JPEG encoder binding
From: Vladimir Zapolskiy
Date: Tue Jun 30 2026 - 17:03:08 EST
On 6/30/26 23:24, Bryan O'Donoghue wrote:
On 30/06/2026 14:32, Vladimir Zapolskiy wrote:
On 6/30/26 16:19, Bryan O'Donoghue wrote:
On 29/06/2026 14:38, Vladimir Zapolskiy wrote:
+ interconnects =Since the proper option for describing this hardware is to have it as
+ <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI_CH0 0>;
+ interconnect-names = "cpu-cfg",
+ "hf-mnoc",
+ "sf-mnoc",
+ "icp-mnoc";
a child device tree node of CAMSS device tree node, which should serve
or be percepted as a bus, it makes no sense to repeat and moreover rename
bus/parent's resources, here is the list:
* "hf_axi", "sf_axi", "core_ahb", "cpas_ahb" and "cnoc_axi" clocks,
* Titan GDSC power domain and all four interconnects.
Only "jpeg" clock and iommus are left specific to the hardware description
of this IP under CAMSS, right? Thus, it should be reflected like this in
the dt description as well, and the complexity of shared resource management
has to be done in the driver, which might be tedious unfortunately, but
certainly doable.
JPEG should be able to vote for its individual NoC / CamNoC dependencies
/ requirements.
There is no individual interconnects, JPEG interconnects are equal to
bus/parent CAMSS ones.
Not true.
This is exactly what is present in the dt binding, if it has to be changed,
please report it to the author of the change.
As a matter of fact, the JPEG encoder has no use-case for the ICP MNOC,
now that I look at this again.
Even if the list is identical the clocks, bandwidth, opp tables
represent individual consumers with individual votes.
I cannot parse "the clocks etc. represent individual consumers".
Anyway, it has no contradiction with what I've said above, all shared
"CAMSS bus" specific resources should get description in the CAMSS device
tree node, all individual subdevice resources should get description
in their own device tree nodes, that's so simple.
There might be no SM8250 CAMSS subcomponent, which operates without Titan
GDSC or cpas and bus clocks, then these are "CAMSS bus" resources, then it
is immediately known that every CAMSS child needs to acquire these resources
from the bus/parent, and it means there is no any single reason to repeat
them in each of 20 CAMSS subnodes.
Both GDSCs and interconnects should be described in the sub-node.
Why to do it in each child, if GDSCs and interconnects are CAMSS bus/domain
specific? There is no acceptable explanation so far.
As we've already established some of the power-domains are function
specific - for example MXA in the PHYs.
It has no contradiction with what I've said earlier.
There's no functional linkage between CAMSS/IFE and JPEG - they are
peers within the CAMSS power-island. Over time we will migrate to
I do not refer to any "functional linkage".
individual nodes for IFE CSID and these too will appear inside of the
CAMSS "bus" -> JPEG etc should describe their nocs and power-domains
individually.
camss@X{
camnoc@{}
csid@{
interconnects = <gem_noc>, <cam_noc>;
};
jpeg@ {
interconnects = <gem_noc>, <cam_noc>;
};
ife@ {
interconnects = <gem_noc>, <cam_noc>;
};
};
It makes sense only if the lists of interconnects are different, this
is not the case.
--
Best wishes,
Vladimir