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

[Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>]

On Tue, Jul 07, 2026 at 04:24:19PM +0300, 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

Please fix your email client and stop inserting extra empty lines.

> 
> you want them to be on parent side. But how to vote on bw? Most of the time
> it

If the driver actually votes on those, I think, it should be fine. This
patchset seemed to add bandwidth voting, but then it dropped all the
votes in the last commit.

> 
> 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.

Interconnects should be fine to be referenced here. Especially, if JPEG
has its own port to those busses (hint, commit message).

As I wrote, I see a bigger issue with the clocks. You need to have some
API to vote on them (and then let camss driver aggregate those votes in
a platform-specific manner).

> 
> Maybe i do not understand properly the proposal but can you just add some
> pseudo code
> 
> how you see the things?
> 
> Regards,
> 
> ~Gjorgji
> 

-- 
With best wishes
Dmitry