| Message ID | 20240415061320.3948707-3-xu.yang_2@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v10,1/8] dt-bindings: perf: fsl-imx-ddr: Add i.MX95 compatible | expand |
On Mon, Apr 15, 2024 at 02:13:15PM +0800, Xu Yang wrote: > In current design, the user of perf app needs to input counter ID to count > events. However, this is not user-friendly since the user needs to lookup > the map table to find the counter. Instead of letting the user to input > the counter, let this driver to manage the counters in this patch. > > This will be implemented by: > 1. allocate counter 0 for cycle event. > 2. find unused counter from 1-10 for reference events. > 3. allocate specific counter for counter-specific events. > > In this patch, counter attr will be kept for back-compatible but all the > value passed down by counter=<n> will be ignored. To mark counter-specific > events, counter ID will be encoded into perf_pmu_events_attr.id. > > Reviewed-by: Frank Li <Frank.Li@nxp.com> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com> > > --- > Changes in v6: > - new patch > Changes in v7: > - no changes > Changes in v8: > - add Rb tag > Changes in v9: > - keep 'counter' attr for back-compatible > Changes in v10: > - add some explanation about 'counter' attr in commit message > --- > drivers/perf/fsl_imx9_ddr_perf.c | 168 ++++++++++++++++++------------- > 1 file changed, 100 insertions(+), 68 deletions(-) [...] > @@ -245,8 +249,8 @@ static const struct attribute_group ddr_perf_events_attr_group = { > .attrs = ddr_perf_events_attrs, > }; > > -PMU_FORMAT_ATTR(event, "config:0-7"); > -PMU_FORMAT_ATTR(counter, "config:8-15"); > +PMU_FORMAT_ATTR(event, "config:0-15"); > +PMU_FORMAT_ATTR(counter, "config:16-23"); Although these mappings are advertised in sysfs, I don't think we can change them because userspace could be relying on them. I also can't find any examples of other PMU drivers in the kernel changing these mappings after being merged, so please keep tthem the same. If you need to expand the properties to be 16-bit, then you'll need to split them into 2x8-bit fields. Will
On Fri, Apr 19, 2024 at 04:49:13PM +0100, Will Deacon wrote: > On Mon, Apr 15, 2024 at 02:13:15PM +0800, Xu Yang wrote: > > In current design, the user of perf app needs to input counter ID to count > > events. However, this is not user-friendly since the user needs to lookup > > the map table to find the counter. Instead of letting the user to input > > the counter, let this driver to manage the counters in this patch. > > > > This will be implemented by: > > 1. allocate counter 0 for cycle event. > > 2. find unused counter from 1-10 for reference events. > > 3. allocate specific counter for counter-specific events. > > > > In this patch, counter attr will be kept for back-compatible but all the > > value passed down by counter=<n> will be ignored. To mark counter-specific > > events, counter ID will be encoded into perf_pmu_events_attr.id. > > > > Reviewed-by: Frank Li <Frank.Li@nxp.com> > > Signed-off-by: Xu Yang <xu.yang_2@nxp.com> > > > > --- > > Changes in v6: > > - new patch > > Changes in v7: > > - no changes > > Changes in v8: > > - add Rb tag > > Changes in v9: > > - keep 'counter' attr for back-compatible > > Changes in v10: > > - add some explanation about 'counter' attr in commit message > > --- > > drivers/perf/fsl_imx9_ddr_perf.c | 168 ++++++++++++++++++------------- > > 1 file changed, 100 insertions(+), 68 deletions(-) > > [...] > > > @@ -245,8 +249,8 @@ static const struct attribute_group ddr_perf_events_attr_group = { > > .attrs = ddr_perf_events_attrs, > > }; > > > > -PMU_FORMAT_ATTR(event, "config:0-7"); > > -PMU_FORMAT_ATTR(counter, "config:8-15"); > > +PMU_FORMAT_ATTR(event, "config:0-15"); > > +PMU_FORMAT_ATTR(counter, "config:16-23"); > > Although these mappings are advertised in sysfs, I don't think we can > change them because userspace could be relying on them. I also can't > find any examples of other PMU drivers in the kernel changing these > mappings after being merged, so please keep tthem the same. > > If you need to expand the properties to be 16-bit, then you'll need to > split them into 2x8-bit fields. I just see tools/perf/tests/pmu.c: { "krava01", "config:0-1,62-63\n", } So I supposed "config:" supported below format PMU_FORMAT_ATTR(event, "config:0-7,16-19"); I just want to confim with you because I have not found other perf driver using such format yet. Frank > > Will
On Fri, Apr 19, 2024 at 02:38:19PM -0400, Frank Li wrote: > On Fri, Apr 19, 2024 at 04:49:13PM +0100, Will Deacon wrote: > > On Mon, Apr 15, 2024 at 02:13:15PM +0800, Xu Yang wrote: > > > In current design, the user of perf app needs to input counter ID to count > > > events. However, this is not user-friendly since the user needs to lookup > > > the map table to find the counter. Instead of letting the user to input > > > the counter, let this driver to manage the counters in this patch. > > > > > > This will be implemented by: > > > 1. allocate counter 0 for cycle event. > > > 2. find unused counter from 1-10 for reference events. > > > 3. allocate specific counter for counter-specific events. > > > > > > In this patch, counter attr will be kept for back-compatible but all the > > > value passed down by counter=<n> will be ignored. To mark counter-specific > > > events, counter ID will be encoded into perf_pmu_events_attr.id. > > > > > > Reviewed-by: Frank Li <Frank.Li@nxp.com> > > > Signed-off-by: Xu Yang <xu.yang_2@nxp.com> > > > > > > --- > > > Changes in v6: > > > - new patch > > > Changes in v7: > > > - no changes > > > Changes in v8: > > > - add Rb tag > > > Changes in v9: > > > - keep 'counter' attr for back-compatible > > > Changes in v10: > > > - add some explanation about 'counter' attr in commit message > > > --- > > > drivers/perf/fsl_imx9_ddr_perf.c | 168 ++++++++++++++++++------------- > > > 1 file changed, 100 insertions(+), 68 deletions(-) > > > > [...] > > > > > @@ -245,8 +249,8 @@ static const struct attribute_group ddr_perf_events_attr_group = { > > > .attrs = ddr_perf_events_attrs, > > > }; > > > > > > -PMU_FORMAT_ATTR(event, "config:0-7"); > > > -PMU_FORMAT_ATTR(counter, "config:8-15"); > > > +PMU_FORMAT_ATTR(event, "config:0-15"); > > > +PMU_FORMAT_ATTR(counter, "config:16-23"); > > > > Although these mappings are advertised in sysfs, I don't think we can > > change them because userspace could be relying on them. I also can't > > find any examples of other PMU drivers in the kernel changing these > > mappings after being merged, so please keep tthem the same. > > > > If you need to expand the properties to be 16-bit, then you'll need to > > split them into 2x8-bit fields. > > I just see tools/perf/tests/pmu.c: { "krava01", "config:0-1,62-63\n", } > So I supposed "config:" supported below format > > PMU_FORMAT_ATTR(event, "config:0-7,16-19"); > > I just want to confim with you because I have not found other perf driver > using such format yet. Oh, wow, that's new syntax for me too! Does the perf tool parse it properly? (and what happens if an older tool sees the new syntax?) Will
Hi Will, On Mon, Apr 22, 2024 at 05:51:53PM +0100, Will Deacon wrote: > On Fri, Apr 19, 2024 at 02:38:19PM -0400, Frank Li wrote: > > On Fri, Apr 19, 2024 at 04:49:13PM +0100, Will Deacon wrote: > > > On Mon, Apr 15, 2024 at 02:13:15PM +0800, Xu Yang wrote: > > > > In current design, the user of perf app needs to input counter ID to count > > > > events. However, this is not user-friendly since the user needs to lookup > > > > the map table to find the counter. Instead of letting the user to input > > > > the counter, let this driver to manage the counters in this patch. > > > > > > > > This will be implemented by: > > > > 1. allocate counter 0 for cycle event. > > > > 2. find unused counter from 1-10 for reference events. > > > > 3. allocate specific counter for counter-specific events. > > > > > > > > In this patch, counter attr will be kept for back-compatible but all the > > > > value passed down by counter=<n> will be ignored. To mark counter-specific > > > > events, counter ID will be encoded into perf_pmu_events_attr.id. > > > > > > > > Reviewed-by: Frank Li <Frank.Li@nxp.com> > > > > Signed-off-by: Xu Yang <xu.yang_2@nxp.com> > > > > > > > > --- > > > > Changes in v6: > > > > - new patch > > > > Changes in v7: > > > > - no changes > > > > Changes in v8: > > > > - add Rb tag > > > > Changes in v9: > > > > - keep 'counter' attr for back-compatible > > > > Changes in v10: > > > > - add some explanation about 'counter' attr in commit message > > > > --- > > > > drivers/perf/fsl_imx9_ddr_perf.c | 168 ++++++++++++++++++------------- > > > > 1 file changed, 100 insertions(+), 68 deletions(-) > > > > > > [...] > > > > > > > @@ -245,8 +249,8 @@ static const struct attribute_group ddr_perf_events_attr_group = { > > > > .attrs = ddr_perf_events_attrs, > > > > }; > > > > > > > > -PMU_FORMAT_ATTR(event, "config:0-7"); > > > > -PMU_FORMAT_ATTR(counter, "config:8-15"); > > > > +PMU_FORMAT_ATTR(event, "config:0-15"); > > > > +PMU_FORMAT_ATTR(counter, "config:16-23"); > > > > > > Although these mappings are advertised in sysfs, I don't think we can > > > change them because userspace could be relying on them. I also can't > > > find any examples of other PMU drivers in the kernel changing these > > > mappings after being merged, so please keep tthem the same. > > > > > > If you need to expand the properties to be 16-bit, then you'll need to > > > split them into 2x8-bit fields. > > > > I just see tools/perf/tests/pmu.c: { "krava01", "config:0-1,62-63\n", } > > So I supposed "config:" supported below format > > > > PMU_FORMAT_ATTR(event, "config:0-7,16-19"); > > > > I just want to confim with you because I have not found other perf driver > > using such format yet. > > Oh, wow, that's new syntax for me too! Does the perf tool parse it > properly? (and what happens if an older tool sees the new syntax?) I've tried the new syntax with different perf version (kernel 6.x, 5.x and 4.x), all the perf tool can parse it properly. Then I'll use this syntax for my patchset in next version. Thanks, Xu Yang > > Will
Hi Frank, On Fri, Apr 19, 2024 at 02:38:19PM -0400, Frank Li wrote: > On Fri, Apr 19, 2024 at 04:49:13PM +0100, Will Deacon wrote: > > On Mon, Apr 15, 2024 at 02:13:15PM +0800, Xu Yang wrote: > > > In current design, the user of perf app needs to input counter ID to count > > > events. However, this is not user-friendly since the user needs to lookup > > > the map table to find the counter. Instead of letting the user to input > > > the counter, let this driver to manage the counters in this patch. > > > > > > This will be implemented by: > > > 1. allocate counter 0 for cycle event. > > > 2. find unused counter from 1-10 for reference events. > > > 3. allocate specific counter for counter-specific events. > > > > > > In this patch, counter attr will be kept for back-compatible but all the > > > value passed down by counter=<n> will be ignored. To mark counter-specific > > > events, counter ID will be encoded into perf_pmu_events_attr.id. > > > > > > Reviewed-by: Frank Li <Frank.Li@nxp.com> > > > Signed-off-by: Xu Yang <xu.yang_2@nxp.com> > > > > > > --- > > > Changes in v6: > > > - new patch > > > Changes in v7: > > > - no changes > > > Changes in v8: > > > - add Rb tag > > > Changes in v9: > > > - keep 'counter' attr for back-compatible > > > Changes in v10: > > > - add some explanation about 'counter' attr in commit message > > > --- > > > drivers/perf/fsl_imx9_ddr_perf.c | 168 ++++++++++++++++++------------- > > > 1 file changed, 100 insertions(+), 68 deletions(-) > > > > [...] > > > > > @@ -245,8 +249,8 @@ static const struct attribute_group ddr_perf_events_attr_group = { > > > .attrs = ddr_perf_events_attrs, > > > }; > > > > > > -PMU_FORMAT_ATTR(event, "config:0-7"); > > > -PMU_FORMAT_ATTR(counter, "config:8-15"); > > > +PMU_FORMAT_ATTR(event, "config:0-15"); > > > +PMU_FORMAT_ATTR(counter, "config:16-23"); > > > > Although these mappings are advertised in sysfs, I don't think we can > > change them because userspace could be relying on them. I also can't > > find any examples of other PMU drivers in the kernel changing these > > mappings after being merged, so please keep tthem the same. > > > > If you need to expand the properties to be 16-bit, then you'll need to > > split them into 2x8-bit fields. > > I just see tools/perf/tests/pmu.c: { "krava01", "config:0-1,62-63\n", } > So I supposed "config:" supported below format > > PMU_FORMAT_ATTR(event, "config:0-7,16-19"); It works. Thanks, Xu Yang > > I just want to confim with you because I have not found other perf driver > using such format yet. > > Frank > > > > > Will
diff --git a/drivers/perf/fsl_imx9_ddr_perf.c b/drivers/perf/fsl_imx9_ddr_perf.c index 0017f2c9ef91..3bf054614b49 100644 --- a/drivers/perf/fsl_imx9_ddr_perf.c +++ b/drivers/perf/fsl_imx9_ddr_perf.c @@ -41,9 +41,11 @@ #define NUM_COUNTERS 11 #define CYCLES_COUNTER 0 +#define CYCLES_EVENT_ID 0 #define CONFIG_EVENT GENMASK(7, 0) #define CONFIG_COUNTER GENMASK(15, 8) +#define CONFIG_COUNTER_OFFSET 8 #define to_ddr_pmu(p) container_of(p, struct ddr_pmu, pmu) @@ -130,6 +132,8 @@ static ssize_t ddr_pmu_event_show(struct device *dev, return sysfs_emit(page, "event=0x%02llx\n", pmu_attr->id); } +#define ID(counter, id) ((counter << CONFIG_COUNTER_OFFSET) | id) + #define IMX9_DDR_PMU_EVENT_ATTR(_name, _id) \ (&((struct perf_pmu_events_attr[]) { \ { .attr = __ATTR(_name, 0444, ddr_pmu_event_show, NULL),\ @@ -162,81 +166,81 @@ static struct attribute *ddr_perf_events_attrs[] = { IMX9_DDR_PMU_EVENT_ATTR(ddrc_pm_29, 63), /* counter1 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_0, 64), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_1, 65), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_2, 66), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_3, 67), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_4, 68), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_5, 69), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_6, 70), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_7, 71), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_0, ID(1, 64)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_1, ID(1, 65)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_2, ID(1, 66)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_3, ID(1, 67)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_4, ID(1, 68)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_5, ID(1, 69)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_6, ID(1, 70)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_riq_7, ID(1, 71)), /* counter2 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_0, 64), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_1, 65), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_2, 66), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_3, 67), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_4, 68), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_5, 69), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_6, 70), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_7, 71), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_empty, 72), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, 73), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_0, ID(2, 64)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_1, ID(2, 65)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_2, ID(2, 66)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_3, ID(2, 67)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_4, ID(2, 68)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_5, ID(2, 69)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_6, ID(2, 70)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_ld_wiq_7, ID(2, 71)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_empty, ID(2, 72)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_trans_filt, ID(2, 73)), /* counter3 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_0, 64), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_1, 65), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_2, 66), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_3, 67), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_4, 68), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_5, 69), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_6, 70), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_7, 71), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_full, 72), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, 73), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_0, ID(3, 64)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_1, ID(3, 65)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_2, ID(3, 66)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_3, ID(3, 67)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_4, ID(3, 68)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_5, ID(3, 69)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_6, ID(3, 70)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_collision_7, ID(3, 71)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_full, ID(3, 72)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_wr_trans_filt, ID(3, 73)), /* counter4 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_0, 64), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_1, 65), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_2, 66), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_3, 67), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_4, 68), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_5, 69), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_6, 70), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_7, 71), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2_rmw, 72), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, 73), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_0, ID(4, 64)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_1, ID(4, 65)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_2, ID(4, 66)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_3, ID(4, 67)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_4, ID(4, 68)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_5, ID(4, 69)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_6, ID(4, 70)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_row_open_7, ID(4, 71)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2_rmw, ID(4, 72)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pm_rd_beat_filt, ID(4, 73)), /* counter5 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_0, 64), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_1, 65), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_2, 66), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_3, 67), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_4, 68), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_5, 69), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_6, 70), - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_7, 71), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq1, 72), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_0, ID(5, 64)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_1, ID(5, 65)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_2, ID(5, 66)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_3, ID(5, 67)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_4, ID(5, 68)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_5, ID(5, 69)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_6, ID(5, 70)), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_start_7, ID(5, 71)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq1, ID(5, 72)), /* counter6 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_end_0, 64), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2, 72), + IMX9_DDR_PMU_EVENT_ATTR(ddrc_qx_valid_end_0, ID(6, 64)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq2, ID(6, 72)), /* counter7 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_1_2_full, 64), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_wrq0, 65), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_1_2_full, ID(7, 64)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_wrq0, ID(7, 65)), /* counter8 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_bias_switched, 64), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_1_4_full, 65), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_bias_switched, ID(8, 64)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_1_4_full, ID(8, 65)), /* counter9 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_wrq1, 65), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_3_4_full, 66), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_wrq1, ID(9, 65)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_3_4_full, ID(9, 66)), /* counter10 specific events */ - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_misc_mrk, 65), - IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq0, 66), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_misc_mrk, ID(10, 65)), + IMX9_DDR_PMU_EVENT_ATTR(eddrtq_pmon_ld_rdq0, ID(10, 66)), NULL, }; @@ -245,8 +249,8 @@ static const struct attribute_group ddr_perf_events_attr_group = { .attrs = ddr_perf_events_attrs, }; -PMU_FORMAT_ATTR(event, "config:0-7"); -PMU_FORMAT_ATTR(counter, "config:8-15"); +PMU_FORMAT_ATTR(event, "config:0-15"); +PMU_FORMAT_ATTR(counter, "config:16-23"); PMU_FORMAT_ATTR(axi_id, "config1:0-17"); PMU_FORMAT_ATTR(axi_mask, "config2:0-17"); @@ -366,13 +370,10 @@ static void ddr_perf_counter_local_config(struct ddr_pmu *pmu, int config, } } -static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1, int cfg2) +static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int event, + int counter, int axi_id, int axi_mask) { u32 pmcfg1, pmcfg2; - int event, counter; - - event = FIELD_GET(CONFIG_EVENT, cfg); - counter = FIELD_GET(CONFIG_COUNTER, cfg); pmcfg1 = readl_relaxed(pmu->base + PMCFG1); @@ -392,12 +393,12 @@ static void ddr_perf_monitor_config(struct ddr_pmu *pmu, int cfg, int cfg1, int pmcfg1 &= ~PMCFG1_RD_BT_FILT_EN; pmcfg1 &= ~FIELD_PREP(PMCFG1_ID_MASK, 0x3FFFF); - pmcfg1 |= FIELD_PREP(PMCFG1_ID_MASK, cfg2); + pmcfg1 |= FIELD_PREP(PMCFG1_ID_MASK, axi_mask); writel(pmcfg1, pmu->base + PMCFG1); pmcfg2 = readl_relaxed(pmu->base + PMCFG2); pmcfg2 &= ~FIELD_PREP(PMCFG2_ID, 0x3FFFF); - pmcfg2 |= FIELD_PREP(PMCFG2_ID, cfg1); + pmcfg2 |= FIELD_PREP(PMCFG2_ID, axi_id); writel(pmcfg2, pmu->base + PMCFG2); } @@ -465,6 +466,28 @@ static void ddr_perf_event_start(struct perf_event *event, int flags) hwc->state = 0; } +static int ddr_perf_alloc_counter(struct ddr_pmu *pmu, int event, int counter) +{ + int i; + + if (event == CYCLES_EVENT_ID) { + // Cycles counter is dedicated for cycle event. + if (pmu->events[CYCLES_COUNTER] == NULL) + return CYCLES_COUNTER; + } else if (counter != 0) { + // Counter specific event use specific counter. + if (pmu->events[counter] == NULL) + return counter; + } else { + // Auto allocate counter for referene event. + for (i = 1; i < NUM_COUNTERS; i++) + if (pmu->events[i] == NULL) + return i; + } + + return -ENOENT; +} + static int ddr_perf_event_add(struct perf_event *event, int flags) { struct ddr_pmu *pmu = to_ddr_pmu(event->pmu); @@ -472,10 +495,17 @@ static int ddr_perf_event_add(struct perf_event *event, int flags) int cfg = event->attr.config; int cfg1 = event->attr.config1; int cfg2 = event->attr.config2; - int counter; + int event_id, counter; + event_id = FIELD_GET(CONFIG_EVENT, cfg); counter = FIELD_GET(CONFIG_COUNTER, cfg); + counter = ddr_perf_alloc_counter(pmu, event_id, counter); + if (counter < 0) { + dev_dbg(pmu->dev, "There are not enough counters\n"); + return -EOPNOTSUPP; + } + pmu->events[counter] = event; pmu->active_events++; hwc->idx = counter; @@ -485,7 +515,7 @@ static int ddr_perf_event_add(struct perf_event *event, int flags) ddr_perf_event_start(event, flags); /* read trans, write trans, read beat */ - ddr_perf_monitor_config(pmu, cfg, cfg1, cfg2); + ddr_perf_monitor_config(pmu, event_id, counter, cfg1, cfg2); return 0; } @@ -506,9 +536,11 @@ static void ddr_perf_event_del(struct perf_event *event, int flags) { struct ddr_pmu *pmu = to_ddr_pmu(event->pmu); struct hw_perf_event *hwc = &event->hw; + int counter = hwc->idx; ddr_perf_event_stop(event, PERF_EF_UPDATE); + pmu->events[counter] = NULL; pmu->active_events--; hwc->idx = -1; }