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

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

On 7/7/2026 5:47 PM, Dmitry Baryshkov wrote:
> 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.
Thanks we will discuss this topic.>