Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Sibi Sankar <quic_sibis@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <myungjoo.ham@samsung.com>, <Kyungmin.park@samsung.com>,
	<cw00.choi@samsung.com>, Viresh Kumar <viresh.kumar@linaro.org>,
	<sudeep.holla@arm.com>, <cristian.marussi@arm.com>,
	<andersson@kernel.org>, <konrad.dybcio@linaro.org>,
	<robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<quic_rgottimu@quicinc.com>, <quic_kshivnan@quicinc.com>,
	<conor+dt@kernel.org>, <arm-scmi@vger.kernel.org>,
	Amir Vajid <avajid@quicinc.com>
Subject: Re: [PATCH V4 4/5] soc: qcom: Introduce SCMI based Memlat (Memory Latency) governor
Date: Tue, 17 Dec 2024 16:35:15 +0530	[thread overview]
Message-ID: <d2d95756-c51d-17bb-ce12-d8ae390a3bac@quicinc.com> (raw)
In-Reply-To: <uwwiz2o6brn5zczbpaiajdq7yva2qpcpgzwdr26lhg4jvlwvvj@w5bkiuhdalze>



On 12/17/24 16:16, Dmitry Baryshkov wrote:
> On Tue, Dec 17, 2024 at 03:46:24PM +0530, Sibi Sankar wrote:
>>
>>
>> On 12/5/24 17:00, Dmitry Baryshkov wrote:
>>> On Thu, 5 Dec 2024 at 12:53, Sibi Sankar <quic_sibis@quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 11/14/24 18:02, Dmitry Baryshkov wrote:
>>>>> On Thu, Nov 14, 2024 at 09:43:53AM +0530, Sibi Sankar wrote:
>>>>>>
>>>>>>
>>>>>> On 10/26/24 23:46, Dmitry Baryshkov wrote:
>>>>>>> On Tue, Oct 22, 2024 at 01:48:25PM +0530, Sibi Sankar wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/7/24 23:27, Dmitry Baryshkov wrote:
>>>>>>>>> On Mon, Oct 07, 2024 at 11:40:22AM GMT, Sibi Sankar wrote:
>>>>>
>>>>>>>>>
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +struct map_param_msg {
>>>>>>>>>> +        u32 hw_type;
>>>>>>>>>> +        u32 mon_idx;
>>>>>>>>>> +        u32 nr_rows;
>>>>>>>>>> +        struct map_table tbl[MAX_MAP_ENTRIES];
>>>>>>>>>> +} __packed;
>>>>>>>>>> +
>>>>>>>>>> +struct node_msg {
>>>>>>>>>> +        u32 cpumask;
>>>>>>>>>> +        u32 hw_type;
>>>>>>>>>> +        u32 mon_type;
>>>>>>>>>> +        u32 mon_idx;
>>>>>>>>>> +        char mon_name[MAX_NAME_LEN];
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +struct scalar_param_msg {
>>>>>>>>>> +        u32 hw_type;
>>>>>>>>>> +        u32 mon_idx;
>>>>>>>>>> +        u32 val;
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +enum common_ev_idx {
>>>>>>>>>> +        INST_IDX,
>>>>>>>>>> +        CYC_IDX,
>>>>>>>>>> +        CONST_CYC_IDX,
>>>>>>>>>> +        FE_STALL_IDX,
>>>>>>>>>> +        BE_STALL_IDX,
>>>>>>>>>> +        NUM_COMMON_EVS
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +enum grp_ev_idx {
>>>>>>>>>> +        MISS_IDX,
>>>>>>>>>> +        WB_IDX,
>>>>>>>>>> +        ACC_IDX,
>>>>>>>>>> +        NUM_GRP_EVS
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +#define EV_CPU_CYCLES           0
>>>>>>>>>> +#define EV_INST_RETIRED         2
>>>>>>>>>> +#define EV_L2_D_RFILL           5
>>>>>>>>>> +
>>>>>>>>>> +struct ev_map_msg {
>>>>>>>>>> +        u32 num_evs;
>>>>>>>>>> +        u32 hw_type;
>>>>>>>>>> +        u32 cid[NUM_COMMON_EVS];
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +struct cpufreq_memfreq_map {
>>>>>>>>>> +        unsigned int cpufreq_mhz;
>>>>>>>>>> +        unsigned int memfreq_khz;
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +struct scmi_monitor_info {
>>>>>>>>>> +        struct cpufreq_memfreq_map *freq_map;
>>>>>>>>>> +        char mon_name[MAX_NAME_LEN];
>>>>>>>>>> +        u32 mon_idx;
>>>>>>>>>> +        u32 mon_type;
>>>>>>>>>> +        u32 ipm_ceil;
>>>>>>>>>> +        u32 mask;
>>>>>>>>>> +        u32 freq_map_len;
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +struct scmi_memory_info {
>>>>>>>>>> +        struct scmi_monitor_info *monitor[MAX_MONITOR_CNT];
>>>>>>>>>> +        u32 hw_type;
>>>>>>>>>> +        int monitor_cnt;
>>>>>>>>>> +        u32 min_freq;
>>>>>>>>>> +        u32 max_freq;
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +struct scmi_memlat_info {
>>>>>>>>>> +        struct scmi_protocol_handle *ph;
>>>>>>>>>> +        const struct qcom_generic_ext_ops *ops;
>>>>>>>>>> +        struct scmi_memory_info *memory[MAX_MEMORY_TYPES];
>>>>>>>>>> +        u32 cluster_info[NR_CPUS];
>>>>>>>>>> +        int memory_cnt;
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>> +static int populate_cluster_info(u32 *cluster_info)
>>>>>>>>>> +{
>>>>>>>>>> +        char name[MAX_NAME_LEN];
>>>>>>>>>> +        int i = 0;
>>>>>>>>>> +
>>>>>>>>>> +        struct device_node *cn __free(device_node) = of_find_node_by_path("/cpus");
>>>>>>>>>> +        if (!cn)
>>>>>>>>>> +                return -ENODEV;
>>>>>>>>>> +
>>>>>>>>>> +        struct device_node *map __free(device_node) = of_get_child_by_name(cn, "cpu-map");
>>>>>>>>>> +        if (!map)
>>>>>>>>>> +                return -ENODEV;
>>>>>>>>>> +
>>>>>>>>>> +        do {
>>>>>>>>>> +                snprintf(name, sizeof(name), "cluster%d", i);
>>>>>>>>>> +                struct device_node *c __free(device_node) = of_get_child_by_name(map, name);
>>>>>>>>>> +                if (!c)
>>>>>>>>>> +                        break;
>>>>>>>>>> +
>>>>>>>>>> +                *(cluster_info + i) = of_get_child_count(c);
>>>>>>>>>> +                i++;
>>>>>>>>>> +        } while (1);
>>>>>>>>>
>>>>>>>>> Can you use existing API from drivers/base/arch_topology.c? If not, can
>>>>>>>>> it be extended to support your usecase?
>>>>>>>>
>>>>>>>> ack. But I'm pretty sure it's going to take a while for reaching such
>>>>>>>> an agreement so I'll drop this feature during the next re-spin.
>>>>>>>
>>>>>>> Why? What kind of API do you actually need? The arch_topology.c simply
>>>>>>> exports a table of struct cpu_topology. Is it somehow different from
>>>>>>> what you are parsing manually?
>>>>>>
>>>>>> yup, we had to figure out the physical id of the cpu
>>>>>> since cpus can be disabled by the bootloader using
>>>>>> status = "failed" property and we have to pass this
>>>>>> onto the cpucp memlat algorithm.
>>>>>
>>>>> Isn't it equal to the index in the cpu_topology table?
>>>>
>>>> from what I see cpu_topology indexes remain unpopulated
>>>> for cpus that are disabled since get_cpu_for_node
>>>> ignores those?
>>>
>>> Why do you need cpu_topology for disabled aka non-existing CPU devices?
>>
>> sorry was out sick couldn't back earlier. We need the know
>> what cpus are disbled to pass on the correct mask of cpus
>> enabled to the SCP.
> 
> Yes. So isn't it enough to know only the enabled CPUs?

yes just knowing the physical index of the enabled cpus
should be enough.

> 
> 

  reply	other threads:[~2024-12-17 11:05 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-07  6:10 [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Sibi Sankar
2024-10-07  6:10 ` [PATCH V4 1/5] dt-bindings: firmware: Document bindings for QCOM SCMI Generic Extension Sibi Sankar
2024-10-07 18:06   ` Dmitry Baryshkov
2024-10-22  7:13     ` Sibi Sankar
2024-10-24 19:54       ` Dmitry Baryshkov
2024-10-08  6:47   ` Krzysztof Kozlowski
2024-10-08  6:49   ` Krzysztof Kozlowski
2024-10-08 12:10     ` Dmitry Baryshkov
2024-10-08 12:11       ` Krzysztof Kozlowski
2024-10-22  7:25         ` Sibi Sankar
2024-10-24 13:29           ` Krzysztof Kozlowski
2024-10-24 19:46             ` Dmitry Baryshkov
2024-10-24 19:48           ` Dmitry Baryshkov
2024-11-06 22:18   ` Jeffrey Hugo
2024-11-14  4:17     ` Sibi Sankar
2024-12-05 15:27   ` Sudeep Holla
2024-12-17 11:45     ` Sibi Sankar
2024-10-07  6:10 ` [PATCH V4 2/5] firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation Sibi Sankar
2024-10-22 10:22   ` Cristian Marussi
2024-11-14  4:32     ` Sibi Sankar
2024-10-07  6:10 ` [PATCH V4 3/5] firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions Sibi Sankar
2024-10-07 18:13   ` Dmitry Baryshkov
2024-10-22  7:18     ` Sibi Sankar
2024-10-07  6:10 ` [PATCH V4 4/5] soc: qcom: Introduce SCMI based Memlat (Memory Latency) governor Sibi Sankar
2024-10-07 17:57   ` Dmitry Baryshkov
2024-10-22  8:18     ` Sibi Sankar
2024-10-26 18:16       ` Dmitry Baryshkov
2024-11-14  4:13         ` Sibi Sankar
2024-11-14 12:32           ` Dmitry Baryshkov
2024-12-05 10:52             ` Sibi Sankar
2024-12-05 11:30               ` Dmitry Baryshkov
2024-12-17 10:16                 ` Sibi Sankar
2024-12-17 10:46                   ` Dmitry Baryshkov
2024-12-17 11:05                     ` Sibi Sankar [this message]
2024-12-17 12:10                       ` Dmitry Baryshkov
2024-11-15  0:38           ` MyungJoo Ham
2024-12-05 10:17             ` Sibi Sankar
2024-10-28  8:30       ` Cristian Marussi
2024-10-10 12:18   ` Jonathan Cameron
2024-10-22  7:31     ` Sibi Sankar
2024-10-22 12:00   ` Cristian Marussi
2024-11-29  9:57   ` Shivnandan Kumar
2024-12-05 11:03     ` Sibi Sankar
2024-12-05 12:39       ` Cristian Marussi
2024-12-23 13:57         ` Sibi Sankar
2024-10-07  6:10 ` [PATCH V4 5/5] arm64: dts: qcom: x1e80100: Enable LLCC/DDR/DDR_QOS dvfs Sibi Sankar
2024-10-08  6:52 ` [PATCH V4 0/5] arm_scmi: vendors: Qualcomm Generic Vendor Extensions Krzysztof Kozlowski
2024-10-22  8:24   ` Sibi Sankar
2024-11-06 12:55 ` Johan Hovold
2024-11-06 20:03   ` Cristian Marussi
2024-11-08 15:14     ` Johan Hovold
2024-11-14  4:22       ` Sibi Sankar
2024-11-22  8:37         ` Johan Hovold
2024-12-05 10:56           ` Sibi Sankar
2024-12-05 15:52             ` Johan Hovold
2024-12-17 11:49               ` Sibi Sankar
2024-12-19 10:37                 ` Johan Hovold
2024-12-23 14:00                   ` Sibi Sankar
2024-12-05 17:01           ` Sudeep Holla
2024-12-17 12:25             ` Sibi Sankar
2024-12-17 14:45               ` Cristian Marussi
2024-12-23 14:09                 ` Sibi Sankar
2024-12-17 17:59               ` Sudeep Holla
2024-12-23 14:14                 ` Sibi Sankar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d2d95756-c51d-17bb-ce12-d8ae390a3bac@quicinc.com \
    --to=quic_sibis@quicinc.com \
    --cc=Kyungmin.park@samsung.com \
    --cc=andersson@kernel.org \
    --cc=arm-scmi@vger.kernel.org \
    --cc=avajid@quicinc.com \
    --cc=conor+dt@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=quic_kshivnan@quicinc.com \
    --cc=quic_rgottimu@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox