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

[Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>]

On 7/8/26 14:35, Dmitry Baryshkov wrote:
> On Wed, Jul 08, 2026 at 01:28:46PM +0300, Vladimir Zapolskiy wrote:
>> Hi Gjorgji.
>>
>> On 7/8/26 12:32, Gjorgji Rosikopulos (Consultant) wrote:
>>> Hi Vlad,
>>>
>>> On 7/8/2026 11:47 AM, Vladimir Zapolskiy wrote:
>>>> Hi Gjorgji.
>>>>
>>>> On 7/7/26 16:24, 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
>>>>> you want them to be on parent side. But how to vote on bw? Most of the
>>>>> time it
>>>>
>>>> Let's concentrate on hardware bindings description, no APIs, votes etc.
>>>> at this point of discussion.
>>> I agree but there should be an API for icc voting which Jpeg need to use,
>>> currently it is fixed to some values, but voting need to become dynamic
>>> at some point of time, because it depends on runtime parameters, resolution
>>> format etc.>
>>
>> Sure, but I believe it's quite clear that any software implementation
>> should be discussed only when the hardware description is fixed.
>>
>>>> There is SM8250 CAMSS device, which serves as a hierarchical parent (or
>>>> could be considered as a "bus" device) to this new JPEG encoder device
>>>> and probably to a number of future IPs under CAMSS. All CAMSS sub-devices
>>>> get hardware descriptions as children device tree nodes of CAMSS parent
>>>> device tree node naturally.
>>> I agree the device tree is best to represent real hw topology. >
>>
>> Well, it's not just the best, it's the only possible way.
>>
>>>> Copying of the same identical information about clocks, interconnects
>>>> and power domains from the hierarchical parent device to children devices
>>>> is not needed, and practically it only lowers signal-to-noise ratio.
>>> Here also i tend to agree.>
>>>> Since information about the actual defect in hardware description is
>>>> reported, the problem can and should be avoided, the handling of a better
>>>> hardware description and dealing with any kind of complexity will be done
>>>> in the CAMSS and/or CAMSS children drivers.
>>>>
>>>> If you need to get a bit more formal point of view on the matter, I'd
>>>> prefer to see descriptions of hardware properties organised in a tree
>>>> topology rather than in the originally proposed star topology. By doing
>>>> it the system complexity is reduced from N to 1.
>>>
>>> Maybe I'm missing the whole picture of your proposal, but I want to add my
>>> point of view on this matter.
>>>
>>> The JPEG encoder HW block has no dependency on the other processing HW
>>> blocks in the camera subsystem
>>>
>>> It shares resources like camnoc, clocks, GDSC, etc.,
>>> but does not share anything with the other HW processing blocks. For me,
>>> the JPEG driver should not have SW architectural dependencies on CAMSS.
>>
>> To move forward there should be a clear answer to a simple question,
>> does Qualcomm JPEG encoder IP belong to CAMSS group of devices or not?
>>
>> If no, then JPEG encoder device tree node shall be located outside of
>> CAMSS device tree node, all resources needed for JPEG encoder device
>> operation get their descrition in this stand-alone device tree node.
>>
>> If yes, then JPEG encoder device tree node is a child of CAMSS "bus"
>> device tree node, and only resources specific to JPEG encoder device
>> are described in its device tree node, because other resources are
>> already described in the parent device tree node.
> 
> 2c from my side (for both sides of the discussion). Please keep it
> separate, if the block simply uses the resource which is also used by
> the parent (e.g. there are no special requirements on the AHB or sleep
> clocks) or if the device needs to actuall cast a vote on a particular
> resource (e.g. for this to function at this performance level, the MMCX
> needs to be at the turbo level OR for this to function at this
> performance level it will use 123 MHz of the AXI clock). In the latter
> case the resources must be described as a part of the device.
> 

Even this "description as a part of the device" might be not quite
necessary in whole, let me try to explain.

No doubts resource usage policies specific to a child device should
be naturally described in child device tree node, and it's applicable
to any kind of hardware policies (like opp tables etc.), but a list
of needed hardware resources still can be obtained (also by a driver)
from the parent, whenever it is found applicable and unambiguous.

This is to separate planes of hardware dependencies and policies/controls
needed for hardware usage.

-- 
Best wishes,
Vladimir