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

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

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.

Regards,
~Gjorgji