Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support

[Konrad Dybcio <konrad.dybcio@linaro.org>]

On 3.04.2024 10:45 AM, Odelu Kukatla wrote:
> 
> 
> On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
>> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>>> It adds QoS support for QNOC device and includes support for
>>> configuring priority, priority forward disable, urgency forwarding.
>>> This helps in priortizing the traffic originating from different
>>> interconnect masters at NoC(Network On Chip).
>>>
>>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>>> ---

[...]

>>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>>>  	u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>>>  	struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>>>  	size_t num_bcms;
>>> +	const struct qcom_icc_qosbox *qosbox;
>>
>> I believe I came up with a better approach for storing this.. see [1]
>>
>> Konrad
>>
>> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
>>
> 
> I see in this series, QoS parameters are moved into struct qcom_icc_desc. 
> Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.

I don't see how it could be the case, we're obviously telling the controller which
endpoints have priority over others, not telling nodes whether the data they
transfer can omit the queue.

> It will be easier later to know which master's QoS we are programming if we add in node data.
> Readability point of view,  it might be good to keep QoS parameters in node data.  

I don't agree here either, with the current approach we've made countless mistakes
when converting the downstream data (I have already submitted some fixes with more
in flight), as there's tons of jumping around the code to find what goes where.

Konrad