[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49483568-b287-45ca-a66c-1e0ad0490225@kernel.org>
Date: Wed, 25 Jun 2025 08:35:06 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Clement LE GOFFIC <clement.legoffic@...s.st.com>,
Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Philipp Zabel <p.zabel@...gutronix.de>, Jonathan Corbet <corbet@....net>,
Gatien Chevallier <gatien.chevallier@...s.st.com>,
Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Gabriel Fernandez <gabriel.fernandez@...s.st.com>
Cc: linux-arm-kernel@...ts.infradead.org, linux-perf-users@...r.kernel.org,
devicetree@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
linux-clk@...r.kernel.org
Subject: Re: [PATCH 06/13] perf: stm32: introduce DDRPERFM driver
On 24/06/2025 12:43, Clement LE GOFFIC wrote:
> On 6/23/25 11:45, Krzysztof Kozlowski wrote:
> [...]
>
> Hi Krzysztof,
>
> Sorry I forgot to address comments below.
>
>>> +
>>> +static const struct stm32_ddr_pmu_cfg stm32_ddr_pmu_cfg_mp1 = {
>>> + .regs = &stm32_ddr_pmu_regspec_mp1,
>>> + .attribute = stm32_ddr_pmu_attr_groups_mp1,
>>> + .counters_nb = MP1_CNT_NB,
>>> + .evt_counters_nb = MP1_CNT_NB - 1, /* Time counter is not an event counter */
>>> + .time_cnt_idx = MP1_TIME_CNT_IDX,
>>> + .get_counter = stm32_ddr_pmu_get_event_counter_mp1,
>>> +};
>>> +
>>> +static const struct stm32_ddr_pmu_cfg stm32_ddr_pmu_cfg_mp2 = {
>>> + .regs = &stm32_ddr_pmu_regspec_mp2,
>>> + .attribute = stm32_ddr_pmu_attr_groups_mp2,
>>> + .counters_nb = MP2_CNT_NB,
>>> + .evt_counters_nb = MP2_CNT_NB - 1, /* Time counter is an event counter */
>>> + .time_cnt_idx = MP2_TIME_CNT_IDX,
>>> + .get_counter = stm32_ddr_pmu_get_event_counter_mp2,
>>> +};
>>> +
>>> +static const struct dev_pm_ops stm32_ddr_pmu_pm_ops = {
>>> + SET_SYSTEM_SLEEP_PM_OPS(NULL, stm32_ddr_pmu_device_resume)
>>> +};
>>> +
>>> +static const struct of_device_id stm32_ddr_pmu_of_match[] = {
>>> + {
>>> + .compatible = "st,stm32mp131-ddr-pmu",
>>> + .data = &stm32_ddr_pmu_cfg_mp1
>>> + },
>>> + {
>>> + .compatible = "st,stm32mp151-ddr-pmu",
>>> + .data = &stm32_ddr_pmu_cfg_mp1
>>
>> So devices are compatible, thus express it correctly and drop this.
>
> Ok so I assume this comes with your comment in the bindings and
> basically don't get you point here.
> Can you please be more precise ?
Express compatibility in the bindings, like 90% of SoCs are doing, so
with proper fallback and drop this entry in the table. My comment was
pretty precise, because this is completely standard pattern, also used
already in stm32.
Best regards,
Krzysztof
Powered by blists - more mailing lists