linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Clement LE GOFFIC <clement.legoffic@foss.st.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Jonathan Corbet <corbet@lwn.net>,
	Gatien Chevallier <gatien.chevallier@foss.st.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Gabriel Fernandez <gabriel.fernandez@foss.st.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<linux-perf-users@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-clk@vger.kernel.org>
Subject: Re: [PATCH 06/13] perf: stm32: introduce DDRPERFM driver
Date: Mon, 23 Jun 2025 17:02:22 +0200	[thread overview]
Message-ID: <1ff31bd6-08e0-46da-a1b0-c60dbb1e3cb8@foss.st.com> (raw)
In-Reply-To: <9cb1575e-ae27-4a78-adb7-8a9e7072375e@kernel.org>

On 6/23/25 11:45, Krzysztof Kozlowski wrote:
> On 23/06/2025 11:27, Clément Le Goffic wrote:
>> +	if (of_property_present(pmu->dev->of_node, "access-controllers")) {
>> +		ret = stm32_firewall_get_firewall(pmu->dev->of_node, &firewall, 1);
>> +		if (ret) {
>> +			dev_err(pmu->dev, "Failed to get firewall\n");
>> +			return ret;
>> +		}
>> +		ret = stm32_firewall_grant_access_by_id(&firewall, firewall.firewall_id);
>> +		if (ret) {
>> +			dev_err(pmu->dev, "Failed to grant access\n");
>> +			return ret;
>> +		}
>> +	}
>> +
>> +	if (of_property_present(pmu->dev->of_node, "clocks")) {
> 
> No, don't open-code get clk optional.

Ok

> 
>> +		pmu->clk = devm_clk_get_prepared(pmu->dev, NULL);
>> +		if (IS_ERR(pmu->clk)) {
>> +			dev_err(pmu->dev, "Failed to get clock\n");
>> +			return PTR_ERR(pmu->clk);
>> +		}
>> +	}
>> +
>> +	clk_enable(pmu->clk);
>> +
>> +	if (of_property_present(pdev->dev.of_node, "resets")) {
>> +		rst = devm_reset_control_get(&pdev->dev, NULL);
>> +		if (IS_ERR(rst)) {
>> +			dev_err(&pdev->dev, "Failed to get reset\n");
>> +			ret = PTR_ERR(rst);
>> +			goto err_clk;
>> +		}
>> +		reset_control_assert(rst);
>> +		reset_control_deassert(rst);
>> +	}
>> +
>> +	pmu->poll_period = ms_to_ktime(POLL_MS);
>> +	hrtimer_setup(&pmu->hrtimer, stm32_ddr_pmu_poll, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>> +
>> +	for (int i = 0; i < MP2_CNT_NB; i++)
>> +		INIT_LIST_HEAD(&pmu->counters[i]);
>> +
>> +	pmu->selected_set = -1;
>> +
>> +	pmu->pmu = (struct pmu) {
>> +		.task_ctx_nr = perf_invalid_context,
>> +		.start = stm32_ddr_pmu_event_start,
>> +		.stop = stm32_ddr_pmu_event_stop,
>> +		.add = stm32_ddr_pmu_event_add,
>> +		.del = stm32_ddr_pmu_event_del,
>> +		.read = stm32_ddr_pmu_event_read,
>> +		.event_init = stm32_ddr_pmu_event_init,
>> +		.attr_groups = pmu->cfg->attribute,
>> +		.module = THIS_MODULE,
>> +	};
>> +
>> +	ret = perf_pmu_register(&pmu->pmu, DRIVER_NAME, -1);
>> +	if (ret) {
>> +		dev_err(&pdev->dev, "Couldn't register DDRPERFM driver as a PMU\n");
>> +		goto err_clk;
>> +	}
>> +
>> +	if (pmu->cfg->regs->dram_inf.reg) {
>> +		ret = of_property_read_u32(pdev->dev.of_node, "st,dram-type", &pmu->dram_type);
>> +		if (ret) {
>> +			dev_err(&pdev->dev, "Missing device-tree property 'st,dram-type'\n");
>> +			perf_pmu_unregister(&pmu->pmu);
>> +
>> +			return ret;
>> +		}
>> +
>> +		writel_relaxed(pmu->dram_type, pmu->membase + pmu->cfg->regs->dram_inf.reg);
>> +	}
>> +
>> +	clk_disable(pmu->clk);
> 
> Why do you keep clock prepared? This device does not know what sort of
> clock it gets, so you end up with clock always active for example and
> this being no-op.

Ok will disable_unprepare

>> +
>> +	return 0;
>> +
>> +err_clk:
>> +	clk_disable_unprepare(pmu->clk);
>> +
>> +	return ret;
>> +}
>> +
>> +static void stm32_ddr_pmu_device_remove(struct platform_device *pdev)
>> +{
>> +	struct stm32_ddr_pmu *stm32_ddr_pmu = platform_get_drvdata(pdev);
>> +
>> +	perf_pmu_unregister(&stm32_ddr_pmu->pmu);
>> +}
>> +
>> +static int __maybe_unused stm32_ddr_pmu_device_resume(struct device *dev)
>> +{
>> +	struct stm32_ddr_pmu *pmu = dev_get_drvdata(dev);
>> +
>> +	clk_enable(pmu->clk);
>> +	writel_relaxed(pmu->dram_type, pmu->membase + pmu->cfg->regs->dram_inf.reg);
>> +	clk_disable(pmu->clk);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct stm32_ddr_pmu_regspec stm32_ddr_pmu_regspec_mp1 = {
>> +	.stop =		{ DDRPERFM_CTRL, CTRL_STOP },
>> +	.start =	{ DDRPERFM_CTRL, CTRL_START },
>> +	.enable =	{ DDRPERFM_CFG },
>> +	.cfg =		{ DDRPERFM_CFG },
>> +	.status =	{ DDRPERFM_STATUS, MP1_STATUS_BUSY },
>> +	.clear_cnt =	{ DDRPERFM_CLR, MP1_CLR_CNT},
>> +	.clear_time =	{ DDRPERFM_CLR, MP1_CLR_TIME},
>> +	.counter_time =	{ DDRPERFM_TCNT },
>> +	.counter_evt =	{
>> +				{ DDRPERFM_EVCNT(0) },
>> +				{ DDRPERFM_EVCNT(1) },
>> +				{ DDRPERFM_EVCNT(2) },
>> +				{ DDRPERFM_EVCNT(3) },
>> +	},
>> +};
>> +
>> +static const struct stm32_ddr_pmu_regspec stm32_ddr_pmu_regspec_mp2 = {
>> +	.stop =		{ DDRPERFM_CTRL, CTRL_STOP },
>> +	.start =	{ DDRPERFM_CTRL, CTRL_START },
>> +	.status =	{ DDRPERFM_MP2_STATUS, MP2_STATUS_BUSY },
>> +	.clear_cnt =	{ DDRPERFM_CLR, MP2_CLR_CNT},
>> +	.clear_time =	{ DDRPERFM_CLR, MP2_CLR_TIME},
>> +	.cfg0 =		{ DDRPERFM_MP2_CFG0 },
>> +	.cfg1 =		{ DDRPERFM_MP2_CFG1 },
>> +	.enable =	{ DDRPERFM_MP2_CFG5 },
>> +	.dram_inf =	{ DDRPERFM_MP2_DRAMINF },
>> +	.counter_time =	{ DDRPERFM_MP2_TCNT },
>> +	.counter_evt =	{
>> +				{ DDRPERFM_MP2_EVCNT(0) },
>> +				{ DDRPERFM_MP2_EVCNT(1) },
>> +				{ DDRPERFM_MP2_EVCNT(2) },
>> +				{ DDRPERFM_MP2_EVCNT(3) },
>> +				{ DDRPERFM_MP2_EVCNT(4) },
>> +				{ DDRPERFM_MP2_EVCNT(5) },
>> +				{ DDRPERFM_MP2_EVCNT(6) },
>> +				{ DDRPERFM_MP2_EVCNT(7) },
>> +	},
>> +};
>> +
>> +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.
> 
>> +	},
>> +	{
>> +		.compatible = "st,stm32mp251-ddr-pmu",
>> +		.data = &stm32_ddr_pmu_cfg_mp2
>> +	},
>> +	{ },
>> +};
>> +MODULE_DEVICE_TABLE(of, stm32_ddr_pmu_of_match);
>> +
>> +static struct platform_driver stm32_ddr_pmu_driver = {
>> +	.driver = {
>> +		.name = DRIVER_NAME,
>> +		.pm = &stm32_ddr_pmu_pm_ops,
>> +		.of_match_table = of_match_ptr(stm32_ddr_pmu_of_match),
> 
> Drop of_match_ptr, you have here warnings.
> 
> 
> 
> Best regards,
> Krzysztof


  reply	other threads:[~2025-06-23 15:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-23  9:27 [PATCH 00/13] Introduce STM32 DDR PMU for STM32MP platforms Clément Le Goffic
2025-06-23  9:27 ` [PATCH 01/13] bus: firewall: move stm32_firewall header file in include folder Clément Le Goffic
2025-06-23  9:27 ` [PATCH 02/13] dt-bindings: stm32: stm32mp25: add `access-controller-cell` property Clément Le Goffic
2025-06-23 10:32   ` Rob Herring (Arm)
2025-06-23  9:27 ` [PATCH 03/13] clk: stm32mp25: add firewall grant_access ops Clément Le Goffic
2025-06-23  9:27 ` [PATCH 04/13] arm64: dts: st: set rcc as an access-controller Clément Le Goffic
2025-06-23  9:27 ` [PATCH 05/13] dt-bindings: perf: stm32: introduce DDRPERFM dt-bindings Clément Le Goffic
2025-06-23  9:48   ` Krzysztof Kozlowski
2025-06-23 15:00     ` Clement LE GOFFIC
2025-06-23  9:27 ` [PATCH 06/13] perf: stm32: introduce DDRPERFM driver Clément Le Goffic
2025-06-23  9:45   ` Krzysztof Kozlowski
2025-06-23 15:02     ` Clement LE GOFFIC [this message]
2025-06-24 10:43     ` Clement LE GOFFIC
2025-06-25  6:35       ` Krzysztof Kozlowski
2025-06-25  8:33         ` Clement LE GOFFIC
2025-06-25  8:48           ` Krzysztof Kozlowski
2025-06-25  9:09             ` Clement LE GOFFIC
2025-06-23 20:43   ` kernel test robot
2025-06-26 23:52   ` kernel test robot
2025-06-30  8:38   ` Philipp Zabel
2025-07-02 14:13     ` Clement LE GOFFIC
2025-06-23  9:27 ` [PATCH 07/13] Documentation: perf: stm32: add ddrperfm support Clément Le Goffic
2025-06-23  9:27 ` [PATCH 08/13] MAINTAINERS: add myself as STM32 DDR PMU maintainer Clément Le Goffic
2025-06-23  9:27 ` [PATCH 09/13] ARM: dts: stm32: add ddrperfm on stm32mp131 Clément Le Goffic
2025-06-23  9:27 ` [PATCH 10/13] ARM: dts: stm32: add ddrperfm on stm32mp151 Clément Le Goffic
2025-06-23  9:27 ` [PATCH 11/13] arm64: dts: st: add ddrperfm on stm32mp251 Clément Le Goffic
2025-06-23  9:27 ` [PATCH 12/13] arm64: dts: st: support ddrperfm on stm32mp257f-dk Clément Le Goffic
2025-06-23  9:27 ` [PATCH 13/13] arm64: dts: st: support ddrperfm on stm32mp257f-ev1 Clément Le Goffic

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=1ff31bd6-08e0-46da-a1b0-c60dbb1e3cb8@foss.st.com \
    --to=clement.legoffic@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gabriel.fernandez@foss.st.com \
    --cc=gatien.chevallier@foss.st.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=will@kernel.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;
as well as URLs for NNTP newsgroup(s).