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@xxxxxxxxxxx>
>> ---
>
> [...]
>
>>
>> + if (desc->config) {
>> + struct resource *res;
>> + void __iomem *base;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + goto skip_qos_config;
>> +
>> + base = devm_ioremap_resource(dev, res);
>
> You were asked to substitute this call like 3 times already..
>
> devm_platform_get_and_ioremap_resource
>
> or even better, devm_platform_ioremap_resource
>
> [...]
>
>> @@ -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@xxxxxxxxxx/
>
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.
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.
Thanks,
Odelu
