From: Sascha Hauer <s.hauer@pengutronix.de> To: Robin Murphy <robin.murphy@arm.com> Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Heiko Stuebner <heiko@sntech.de>, Kyungmin Park <kyungmin.park@samsung.com>, MyungJoo Ham <myungjoo.ham@samsung.com>, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, kernel@pengutronix.de, Michael Riesch <michael.riesch@wolfvision.net> Subject: Re: [PATCH v4 15/21] PM / devfreq: rockchip-dfi: Add perf support Date: Tue, 16 May 2023 17:27:43 +0200 [thread overview] Message-ID: <20230516152743.GS15436@pengutronix.de> (raw) In-Reply-To: <71827018-8e29-2966-380b-66ddfdcd3668@arm.com> On Tue, May 09, 2023 at 09:04:58PM +0100, Robin Murphy wrote: > On 2023-05-05 12:38, Sascha Hauer wrote: > > diff --git a/drivers/devfreq/event/rockchip-dfi.c b/drivers/devfreq/event/rockchip-dfi.c > > index eae010644935a..400b1b360e3c9 100644 > > --- a/drivers/devfreq/event/rockchip-dfi.c > > +++ b/drivers/devfreq/event/rockchip-dfi.c > > @@ -20,6 +20,7 @@ > > #include <linux/of_device.h> > > #include <linux/bitfield.h> > > #include <linux/bits.h> > > +#include <linux/perf_event.h> > > #include <soc/rockchip/rockchip_grf.h> > > #include <soc/rockchip/rk3399_grf.h> [...] > > +static int rockchip_ddr_perf_event_init(struct perf_event *event) > > +{ > > + struct rockchip_dfi *dfi = container_of(event->pmu, struct rockchip_dfi, pmu); > > + > > + if (event->attr.type != event->pmu->type) > > + return -ENOENT; > > + > > + if (event->attach_state & PERF_ATTACH_TASK) > > + return -EOPNOTSUPP; > > IMO this should be -EINVAL - the event isn't something that the driver would > consider valid in general but happens to not be supported by this particular > PMU instance, it's something that's fundamentally meaningless because the > memory controller has no notion of what a task or even a CPU is, much less > the ability to ever attribute low-level DRAM accesses to one. > > > + > > + if (event->cpu < 0) { > > + dev_warn(dfi->dev, "Can't provide per-task data!\n"); > > + return -EOPNOTSUPP; > > Ditto. > > > + } > > + > > If you can't snapshot multiple counters atomically (and don't want to > start/stop the whole monitor to achieve the same effect - I guess it would > be hard to do that without getting in the way of devfreq operation), then > you should ideally also check for and reject event groups containing > multiple hardware events. Yes, starting/stopping the monitor for atomic snapshots is hard to do without influencing devfreq operation, that's why I decided against it. OTOH I consider it very useful being able to monitor read-bytes and write-bytes at the same time (or to simultaneously monitor multiple channels in the next version). Indeed non atomically reading the snapshots introduces a small error, but normally the time it takes to read out all channels should be rather small compared to the time between the snapshots, so I think this error is negligible. > > +static int rockchip_ddr_perf_init(struct rockchip_dfi *dfi) > > +{ > > + struct pmu *pmu = &dfi->pmu; > > + int ret; > > + > > + pmu->module = THIS_MODULE; > > + pmu->capabilities = PERF_PMU_CAP_NO_EXCLUDE; > > + pmu->task_ctx_nr = perf_invalid_context; > > + pmu->attr_groups = attr_groups; > > + pmu->event_init = rockchip_ddr_perf_event_init; > > + pmu->add = rockchip_ddr_perf_event_add; > > + pmu->del = rockchip_ddr_perf_event_del; > > + pmu->start = rockchip_ddr_perf_event_start; > > + pmu->stop = rockchip_ddr_perf_event_stop; > > + pmu->read = rockchip_ddr_perf_event_update; > > + > > + dfi->cpu = raw_smp_processor_id(); > > + > > + ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, > > + "rockchip_ddr_perf_pmu", > > + NULL, > > + ddr_perf_offline_cpu); > > So, each instance gets its own distinct multi-instance state to only support > a single instance each, except there can clearly only ever be a single > instance globally anyway, since the PMU is registered with a fixed name... I > can only guess that maybe such a contrivance is born of the notion of > "global variables are bad", but honestly, this is worse :/ So you are suggesting that struct pmu should be statically initialized rather than dynamically allocated, right? Are you referring to struct pmu only or also to struct rockchip_dfi? I am not sure I would like this. Yes, the fixed name makes the driver inherently single instance only, nevertheless I think the driver code is easier to follow when it's written the usual way, with lifetime of the dynamic data between probe() and remove(). As a compromise I could allocate the name dynamically as well, but I have no idea how to make up a good id. Some other drivers use the base address of the device, but that would mean the 'perf stat' calls would differ between different SoCs without any real gain. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Sascha Hauer <s.hauer@pengutronix.de> To: Robin Murphy <robin.murphy@arm.com> Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Heiko Stuebner <heiko@sntech.de>, Kyungmin Park <kyungmin.park@samsung.com>, MyungJoo Ham <myungjoo.ham@samsung.com>, Will Deacon <will@kernel.org>, Mark Rutland <mark.rutland@arm.com>, kernel@pengutronix.de, Michael Riesch <michael.riesch@wolfvision.net> Subject: Re: [PATCH v4 15/21] PM / devfreq: rockchip-dfi: Add perf support Date: Tue, 16 May 2023 17:27:43 +0200 [thread overview] Message-ID: <20230516152743.GS15436@pengutronix.de> (raw) In-Reply-To: <71827018-8e29-2966-380b-66ddfdcd3668@arm.com> On Tue, May 09, 2023 at 09:04:58PM +0100, Robin Murphy wrote: > On 2023-05-05 12:38, Sascha Hauer wrote: > > diff --git a/drivers/devfreq/event/rockchip-dfi.c b/drivers/devfreq/event/rockchip-dfi.c > > index eae010644935a..400b1b360e3c9 100644 > > --- a/drivers/devfreq/event/rockchip-dfi.c > > +++ b/drivers/devfreq/event/rockchip-dfi.c > > @@ -20,6 +20,7 @@ > > #include <linux/of_device.h> > > #include <linux/bitfield.h> > > #include <linux/bits.h> > > +#include <linux/perf_event.h> > > #include <soc/rockchip/rockchip_grf.h> > > #include <soc/rockchip/rk3399_grf.h> [...] > > +static int rockchip_ddr_perf_event_init(struct perf_event *event) > > +{ > > + struct rockchip_dfi *dfi = container_of(event->pmu, struct rockchip_dfi, pmu); > > + > > + if (event->attr.type != event->pmu->type) > > + return -ENOENT; > > + > > + if (event->attach_state & PERF_ATTACH_TASK) > > + return -EOPNOTSUPP; > > IMO this should be -EINVAL - the event isn't something that the driver would > consider valid in general but happens to not be supported by this particular > PMU instance, it's something that's fundamentally meaningless because the > memory controller has no notion of what a task or even a CPU is, much less > the ability to ever attribute low-level DRAM accesses to one. > > > + > > + if (event->cpu < 0) { > > + dev_warn(dfi->dev, "Can't provide per-task data!\n"); > > + return -EOPNOTSUPP; > > Ditto. > > > + } > > + > > If you can't snapshot multiple counters atomically (and don't want to > start/stop the whole monitor to achieve the same effect - I guess it would > be hard to do that without getting in the way of devfreq operation), then > you should ideally also check for and reject event groups containing > multiple hardware events. Yes, starting/stopping the monitor for atomic snapshots is hard to do without influencing devfreq operation, that's why I decided against it. OTOH I consider it very useful being able to monitor read-bytes and write-bytes at the same time (or to simultaneously monitor multiple channels in the next version). Indeed non atomically reading the snapshots introduces a small error, but normally the time it takes to read out all channels should be rather small compared to the time between the snapshots, so I think this error is negligible. > > +static int rockchip_ddr_perf_init(struct rockchip_dfi *dfi) > > +{ > > + struct pmu *pmu = &dfi->pmu; > > + int ret; > > + > > + pmu->module = THIS_MODULE; > > + pmu->capabilities = PERF_PMU_CAP_NO_EXCLUDE; > > + pmu->task_ctx_nr = perf_invalid_context; > > + pmu->attr_groups = attr_groups; > > + pmu->event_init = rockchip_ddr_perf_event_init; > > + pmu->add = rockchip_ddr_perf_event_add; > > + pmu->del = rockchip_ddr_perf_event_del; > > + pmu->start = rockchip_ddr_perf_event_start; > > + pmu->stop = rockchip_ddr_perf_event_stop; > > + pmu->read = rockchip_ddr_perf_event_update; > > + > > + dfi->cpu = raw_smp_processor_id(); > > + > > + ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, > > + "rockchip_ddr_perf_pmu", > > + NULL, > > + ddr_perf_offline_cpu); > > So, each instance gets its own distinct multi-instance state to only support > a single instance each, except there can clearly only ever be a single > instance globally anyway, since the PMU is registered with a fixed name... I > can only guess that maybe such a contrivance is born of the notion of > "global variables are bad", but honestly, this is worse :/ So you are suggesting that struct pmu should be statically initialized rather than dynamically allocated, right? Are you referring to struct pmu only or also to struct rockchip_dfi? I am not sure I would like this. Yes, the fixed name makes the driver inherently single instance only, nevertheless I think the driver code is easier to follow when it's written the usual way, with lifetime of the dynamic data between probe() and remove(). As a compromise I could allocate the name dynamically as well, but I have no idea how to make up a good id. Some other drivers use the base address of the device, but that would mean the 'perf stat' calls would differ between different SoCs without any real gain. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-05-16 15:28 UTC|newest] Thread overview: 121+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-05 11:38 [PATCH v4 00/21] Add perf support to the rockchip-dfi driver Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 01/21] PM / devfreq: rockchip-dfi: Embed desc into private data struct Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-07 10:08 ` Heiko Stübner 2023-05-07 10:08 ` Heiko Stübner 2023-05-16 15:12 ` Jonathan Cameron 2023-05-16 15:12 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 02/21] PM / devfreq: rockchip-dfi: use consistent name for " Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-07 10:22 ` Heiko Stübner 2023-05-07 10:22 ` Heiko Stübner 2023-05-16 15:27 ` Jonathan Cameron 2023-05-16 15:27 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 03/21] PM / devfreq: rockchip-dfi: Make pmu regmap mandatory Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 15:33 ` Jonathan Cameron 2023-05-16 15:33 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 04/21] PM / devfreq: rockchip-dfi: Add SoC specific init function Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 15:40 ` Jonathan Cameron 2023-05-16 15:40 ` Jonathan Cameron 2023-05-17 9:20 ` Sascha Hauer 2023-05-17 9:20 ` Sascha Hauer 2023-05-17 10:19 ` Jonathan Cameron 2023-05-17 10:19 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 05/21] PM / devfreq: rockchip-dfi: dfi store raw values in counter struct Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 15:43 ` Jonathan Cameron 2023-05-16 15:43 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 06/21] PM / devfreq: rockchip-dfi: Use free running counter Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 15:48 ` Jonathan Cameron 2023-05-16 15:48 ` Jonathan Cameron 2023-05-17 9:29 ` Sascha Hauer 2023-05-17 9:29 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 07/21] PM / devfreq: rockchip-dfi: introduce channel mask Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 15:50 ` Jonathan Cameron 2023-05-16 15:50 ` Jonathan Cameron 2023-05-17 9:33 ` Sascha Hauer 2023-05-17 9:33 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 08/21] PM / devfreq: rk3399_dmc,dfi: generalize DDRTYPE defines Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 15:54 ` Jonathan Cameron 2023-05-16 15:54 ` Jonathan Cameron 2023-05-17 10:51 ` Sascha Hauer 2023-05-17 10:51 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 09/21] PM / devfreq: rockchip-dfi: Clean up DDR type register defines Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:01 ` Jonathan Cameron 2023-05-16 16:01 ` Jonathan Cameron 2023-05-17 11:11 ` Sascha Hauer 2023-05-17 11:11 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 10/21] PM / devfreq: rockchip-dfi: Add RK3568 support Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:04 ` Jonathan Cameron 2023-05-16 16:04 ` Jonathan Cameron 2023-05-17 11:38 ` Sascha Hauer 2023-05-17 11:38 ` Sascha Hauer 2023-05-17 14:46 ` Jonathan Cameron 2023-05-17 14:46 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 11/21] PM / devfreq: rockchip-dfi: Handle LPDDR2 correctly Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:06 ` Jonathan Cameron 2023-05-16 16:06 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 12/21] PM / devfreq: rockchip-dfi: Handle LPDDR4X Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:09 ` Jonathan Cameron 2023-05-16 16:09 ` Jonathan Cameron 2023-05-19 6:14 ` Sascha Hauer 2023-05-19 6:14 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 13/21] PM / devfreq: rockchip-dfi: Pass private data struct to internal functions Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:10 ` Jonathan Cameron 2023-05-16 16:10 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 14/21] PM / devfreq: rockchip-dfi: Prepare for multiple users Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:16 ` Jonathan Cameron 2023-05-16 16:16 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 15/21] PM / devfreq: rockchip-dfi: Add perf support Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-09 20:04 ` Robin Murphy 2023-05-10 19:56 ` Sascha Hauer 2023-05-16 15:39 ` Sascha Hauer 2023-05-16 15:39 ` Sascha Hauer 2023-05-16 15:27 ` Sascha Hauer [this message] 2023-05-16 15:27 ` Sascha Hauer 2023-05-17 10:53 ` Jonathan Cameron 2023-05-17 10:53 ` Jonathan Cameron 2023-05-17 14:26 ` Sascha Hauer 2023-05-17 14:26 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 16/21] PM / devfreq: rockchip-dfi: make register stride SoC specific Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-16 16:18 ` Jonathan Cameron 2023-05-16 16:18 ` Jonathan Cameron 2023-05-19 6:45 ` Sascha Hauer 2023-05-19 6:45 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 17/21] PM / devfreq: rockchip-dfi: account for multiple DDRMON_CTRL registers Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-17 10:23 ` Jonathan Cameron 2023-05-17 10:23 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 18/21] PM / devfreq: rockchip-dfi: add support for RK3588 Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-17 10:24 ` Jonathan Cameron 2023-05-17 10:24 ` Jonathan Cameron 2023-05-05 11:38 ` [PATCH v4 19/21] arm64: dts: rockchip: rk3399: Enable DFI Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 20/21] arm64: dts: rockchip: rk356x: Add DFI Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-05 11:38 ` [PATCH v4 21/21] dt-bindings: devfreq: event: convert Rockchip DFI binding to yaml Sascha Hauer 2023-05-05 11:38 ` Sascha Hauer 2023-05-05 16:29 ` Krzysztof Kozlowski 2023-05-05 16:29 ` Krzysztof Kozlowski 2023-05-05 16:31 ` Krzysztof Kozlowski 2023-05-05 16:31 ` Krzysztof Kozlowski 2023-05-09 9:37 ` Sascha Hauer 2023-05-09 9:40 ` Krzysztof Kozlowski 2023-05-09 10:02 ` Sascha Hauer 2023-05-05 16:38 ` [PATCH v4 00/21] Add perf support to the rockchip-dfi driver Vincent Legoll 2023-05-05 16:38 ` Vincent Legoll
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=20230516152743.GS15436@pengutronix.de \ --to=s.hauer@pengutronix.de \ --cc=heiko@sntech.de \ --cc=kernel@pengutronix.de \ --cc=kyungmin.park@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=mark.rutland@arm.com \ --cc=michael.riesch@wolfvision.net \ --cc=myungjoo.ham@samsung.com \ --cc=robin.murphy@arm.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.