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

["Gjorgji Rosikopulos (Consultant)" <gjorgji.rosikopulos@oss.qualcomm.com>]

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

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?

Regards,

~Gjorgji