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

[Dmitry Baryshkov]

On Tue, Jul 07, 2026 at 04:47:07PM +0300, Gjorgji Rosikopulos (Consultant) wrote:
> Hi Dmitry,
> 
> On 7/7/2026 4:32 PM, Dmitry Baryshkov wrote:
> > 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.
> Apologies for that. Some Thunderbird settings were missing on my side, i hope now is fine...> 
> >>
> >> 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).
> Can we use icc-clk framework to vote on them. I think even today there may be some issues in camss
> for the clock voting.

Please discuss it with the Camera team, working on the camss
improvements.

-- 
With best wishes
Dmitry