Re: [PATCH v4 5/5] media: qcom: jpeg: Add Qualcomm JPEG V4L2 encoder

[Vladimir Zapolskiy]

Hi Gjorgji.

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.

There is SM8250 CAMSS device, which serves as a hierarchical parent (or
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.

Copying of the same identical information about clocks, interconnects
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.

> depends on the jpeg encoder configuration based on resolution format
> etc. to set properly average bw.
>
> So i dont see how that can be done with not explicit dependency on jpeg
> with camss and some exported
>
> API's which we discussed with Bryan they are preferable.
>
> Maybe i do not understand properly the proposal but can you just add
> some pseudo code
>
> how you see the things?

Let's define and agree on hardware description first, then the path
to its implementation in drivers will be clear.

--
Best wishes,
Vladimir