From: Will Deacon <will@kernel.org>
To: Xu Yang <xu.yang_2@nxp.com>
Cc: Frank.li@nxp.com, mark.rutland@arm.com, shawnguo@kernel.org,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
Subject: Re: [PATCH v2] perf: imx9_perf: Introduce AXI filter version to refactor the driver and better extension
Date: Wed, 11 Dec 2024 21:56:38 +0000 [thread overview]
Message-ID: <20241211215637.GF17486@willie-the-truck> (raw)
In-Reply-To: <20241211053455.z5zzawfacpyv2dlt@hippo>
On Wed, Dec 11, 2024 at 01:35:16PM +0800, Xu Yang wrote:
> On Tue, Dec 10, 2024 at 01:37:32PM +0000, Will Deacon wrote:
> > On Tue, Dec 10, 2024 at 10:02:12AM +0800, Xu Yang wrote:
> > > On Mon, Dec 09, 2024 at 03:44:20PM +0000, Will Deacon wrote:
> > > > On Mon, Nov 25, 2024 at 06:43:38PM +0800, Xu Yang wrote:
> > > > > The imx93 is the first supported DDR PMU that supports read transaction,
> > > > > write transaction and read beats events which corresponding respecitively
> > > > > to counter 2, 3 and 4.
> > > > >
> > > > > However, transaction-based AXI match has low accuracy when get total bits
> > > > > compared to beats-based. And imx93 doesn't assign AXI_ID to each master.
> > > > > So axi filter is not used widely on imx93. This could be regards as AXI
> > > > > filter version 1.
> > > > >
> > > > > To improve the AXI filter capability, imx95 supports 1 read beats and 3
> > > > > write beats event which corresponding respecitively to counter 2-5. imx95
> > > > > also detailed AXI_ID allocation so that most of the master could be count
> > > > > individually. This could be regards as AXI filter version 2.
> > > > >
> > > > > This will introduce AXI filter version to refactor the driver and support
> > > > > better extension, such as coming imx943.
> > > > >
> > > > > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> > > > >
> > > > > ---
> > > > > Changes in v2:
> > > > > - modify subject
> > > > > - add comments for AXI_FILTER version
> > > > > - type -> filter_ver
> > > > > ---
> > > > > drivers/perf/fsl_imx9_ddr_perf.c | 33 ++++++++++++++++++++++++--------
> > > > > 1 file changed, 25 insertions(+), 8 deletions(-)
> >
> > [...]
> >
> > > > > @@ -624,11 +641,11 @@ static int ddr_perf_event_add(struct perf_event *event, int flags)
> > > > > hwc->idx = counter;
> > > > > hwc->state |= PERF_HES_STOPPED;
> > > > >
> > > > > - if (is_imx93(pmu))
> > > > > + if (axi_filter_v1(pmu))
> > > > > /* read trans, write trans, read beat */
> > > > > imx93_ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2);
> > > >
> > > > Hmm, doesn't this change mean we now enable this for imx91 as well? My
> > > > reading of the commit message is that imx93 was the first chip which
> > > > supports this.
> > >
> > > Yes, it's enabled for imx91 too. In fact, imx91 is compatible with imx93.
> > > They use same configuration for axi filter.
> >
> > Ok, but my worry is that the above code looks like userspace now _must_
> > provide valid values for the config1 (axi_id) and config2 (axi_mask)
> > fields on imx91, whereas before I think they were ignored by the driver.
> >
> > In fact, without this change, how were the PMCFGn registers configured
> > on imx91? It looks to me like they were left uninitialised...
>
> Before this change, PMCFGn registers are indeed not configured on imx91.
> However, they should be configured as imx93. I notice this thing when
> make this patch. First thing I tried is to add is_imx91(), then check it
> and is_imx93() by "||" operator. However, this way seems not scalable as
> more imx9x Soc comes out. Basically, AXI filter version will keep at V2
> unless big changes due to new features. However, perf tool need export
> correct MetricName via identifier in sysfs. So I made this patch, then
> PMCFGn will be configured based on axi filter version rather than pmu
> name.
Gotcha. But that means this is a fix, right? The commit message doesn't
really indicate that and we probably want a Fixes: tag to indicate how
far it should be backported.
Please can you send a v3 with that so I can apply it?
Thanks,
Will
next prev parent reply other threads:[~2024-12-11 21:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 10:43 [PATCH v2] perf: imx9_perf: Introduce AXI filter version to refactor the driver and better extension Xu Yang
2024-11-25 17:22 ` Frank Li
2024-12-09 15:44 ` Will Deacon
2024-12-10 2:02 ` Xu Yang
2024-12-10 13:37 ` Will Deacon
2024-12-11 5:35 ` Xu Yang
2024-12-11 21:56 ` Will Deacon [this message]
2024-12-12 4:52 ` Xu Yang
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=20241211215637.GF17486@willie-the-truck \
--to=will@kernel.org \
--cc=Frank.li@nxp.com \
--cc=festevam@gmail.com \
--cc=imx@lists.linux.dev \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=shawnguo@kernel.org \
--cc=xu.yang_2@nxp.com \
/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