Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Hi Joonas, > > > The GT has its own properties and in sysfs they should be grouped > > > in the 'gt/' directory. > > > > > > Create a 'gt/' directory in sysfs which will contain gt0...gtN > > > directories related to each tile configured in the GPU. Move the > > > power management files inside those directories. > > > > > > The previous power management files are kept in their original > > > root directory to avoid breaking the ABI. They point to the tile > > > '0' and a warning message is printed whenever accessed to. > > This is wrong. They should act as multiplexers to all the tiles. > > Needs to be fixed before merging. I have a patch for this and I planned to send it later. I have even been asked to split this one in more chunks as the review is a bit difficult. > > > The > > > deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2 > > > flag in order to be generated. > > > > CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least > > does not appear to contain it so please update the commit message to > > reflect current state. > > > > Adding Joonas to help address the question of how strict are userspace > > requirements for sysfs additions. Personally sysadmin use sounds fine to > > me, although it needs to be mentioned/documented as Matt requested, but > > I fear it may not be enough to upstream. Is Level0 at the stage where we > > can upstream for it I am also not sure. > > Sysadmin usage is fine for the simple interfaces that can truly be used > from the command line. This patch seems to just expose the existing > interface in per-tile manner, so should not be a concern. This will definitely help this patch (series) to get in, but I my understanding is that Level0 is a bit behind for upstreaming. > However, the controls not under gt directories, need to be converted to > apply to all tiles. (I've definitely given that feedback multiple > times). Otherwise it will be very unexpected to the end user when what > previously applied to whole device would only apply to part of it. It's not forgotten :) > Regards, Joonas Thank you, Andi
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Quoting Tvrtko Ursulin (2022-01-17 18:02:50) > > On 17/01/2022 15:09, Andi Shyti wrote: > > The GT has its own properties and in sysfs they should be grouped > > in the 'gt/' directory. > > > > Create a 'gt/' directory in sysfs which will contain gt0...gtN > > directories related to each tile configured in the GPU. Move the > > power management files inside those directories. > > > > The previous power management files are kept in their original > > root directory to avoid breaking the ABI. They point to the tile > > '0' and a warning message is printed whenever accessed to. This is wrong. They should act as multiplexers to all the tiles. Needs to be fixed before merging. > > The > > deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2 > > flag in order to be generated. > > CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least > does not appear to contain it so please update the commit message to > reflect current state. > > Adding Joonas to help address the question of how strict are userspace > requirements for sysfs additions. Personally sysadmin use sounds fine to > me, although it needs to be mentioned/documented as Matt requested, but > I fear it may not be enough to upstream. Is Level0 at the stage where we > can upstream for it I am also not sure. Sysadmin usage is fine for the simple interfaces that can truly be used from the command line. This patch seems to just expose the existing interface in per-tile manner, so should not be a concern. However, the controls not under gt directories, need to be converted to apply to all tiles. (I've definitely given that feedback multiple times). Otherwise it will be very unexpected to the end user when what previously applied to whole device would only apply to part of it. Regards, Joonas > > While I am here I also left some nits below (not full review). > > > > > The new sysfs structure will have a similar layout for the 4 tile > > case: > > > > /sys/.../card0 > > \u251c\u2500\u2500 gt > > \u2502 \u251c\u2500\u2500 gt0 > > \u2502 \u2502 \u251c\u2500\u2500 id > > \u2502 \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > >. . > >. . > >. . > > \u2502 \u2514\u2500\u2500 gt3 > > \u2502 \u251c\u2500\u2500 id > > \u2502 \u251c\u2500\u2500 rc6_enable > > \u2502 \u251c\u2500\u2500 rc6_residency_ms > > \u2502 \u251c\u2500\u2500 rps_act_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_boost_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_cur_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_max_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_min_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP0_freq_mhz > > \u2502 \u251c\u2500\u2500 rps_RP1_freq_mhz > > \u2502 \u2514\u2500\u2500 rps_RPn_freq_mhz > > \u251c\u2500\u2500 gt_act_freq_mhz -+ > > \u251c\u2500\u2500 gt_boost_freq_mhz | > > \u251c\u2500\u2500 gt_cur_freq_mhz|Original interface > > \u251c\u2500\u2500 gt_max_freq_mhz+\u2500-> kept as existing > > ABI; > > \u251c\u2500\u2500 gt_min_freq_mhz|it points to gt0/ > > \u251c\u2500\u2500 gt_RP0_freq_mhz| > > \u2514\u2500\u2500 gt_RP1_freq_mhz| > > \u2514\u2500\u2500 gt_RPn_freq_mhz -+ > > > > As soon as multitile platforms will start being supported, this > > interface will allow to control the power (either manually or > > with tools) on each tile, instead of affecting only tile 0 and > > getting incomplete results. > > > > Signed-off-by: Andi Shyti > > Signed-off-by: Lucas De Marchi > > Cc: Matt Roper > > Cc: Sujaritha Sundaresan > > Cc: Tvrtko Ursulin > > Reviewed-by: Sujaritha Sundaresan > > --- > > drivers/gpu/drm/i915/Makefile | 4 +- > > drivers/gpu/drm/i915/gt/intel_gt.c| 2 + > > drivers/gpu/drm/i915/gt/sysfs_gt.c| 126 + > > drivers/gpu/drm/i915/gt/sysfs_gt.h| 44 +++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 393 ++ > > drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++ > > drivers/gpu/drm/i915/i915_drv.h | 2 + > > drivers/gpu/drm/i915/i915_reg.h | 1 + > >
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
Hi Tvrtko,
> > The previous power management files are kept in their original
> > root directory to avoid breaking the ABI. They point to the tile
> > '0' and a warning message is printed whenever accessed to. The
> > deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2
> > flag in order to be generated.
>
> CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least does
> not appear to contain it so please update the commit message to reflect
> current state.
>
> Adding Joonas to help address the question of how strict are userspace
> requirements for sysfs additions. Personally sysadmin use sounds fine to me,
> although it needs to be mentioned/documented as Matt requested, but I fear
> it may not be enough to upstream. Is Level0 at the stage where we can
> upstream for it I am also not sure.
no need... it's a leftover in the commit message. The deprecated
was removed a year ago, maybe. Thanks!
[...]
> > + pr_devel_ratelimited(DEPRECATED
> > + "%s (pid %d) is trying to access deprecated %s "
> > + "sysfs control, please use gt/gt/%s instead\n",
>
> Maybe reword "is trying to access" to "is accesing" to remove any doubt
> whether something is failing or not?
OK
[...]
> > + if (sysfs_create_file(dir, _attr_id.attr))
> > + drm_err(>i915->drm,
> > + "failed to create sysfs %s info files\n", name);
>
> These drm_err could maybe be warn or notice, to reflect the fact driver is
> most likely completely functional? But only maybe since I haven't checked
> what we do for other sysfs failures. If rest are drm_err then I guess
> consistency trumps it.
yes, I agree with you and indeed they whould be treated as
warnings because the driver probes correctly if sysfs fails.
I will change this to drm_warn and fixx all the others. Thanks!
[...]
> > +static inline bool is_object_gt(struct kobject *kobj)
> > +{
> > + bool b = !strncmp(kobj->name, "gt", 2);
> > +
> > + GEM_BUG_ON(b && !isdigit(kobj->name[2]));
>
> 1)
> Not sure what is the point of this GEM_BUG_ON? Checking strncmp works feels
> like an overkill.
>
> 2)
> With the recent trend of "static inline considered harmful" perhaps consider
> moving it out of line.
OK
[...]
> > +static const struct attribute_group rc6_attr_group[] = {
> > + { .name = power_group_name, .attrs = rc6_attrs },
> > + { .attrs = rc6_attrs }
> > +};
> > +
> > +static const struct attribute_group rc6p_attr_group[] = {
> > + { .name = power_group_name, .attrs = rc6p_attrs },
> > + { .attrs = rc6p_attrs }
> > +};
> > +
> > +static const struct attribute_group media_rc6_attr_group[] = {
> > + { .name = power_group_name, .attrs = media_rc6_attrs },
> > + { .attrs = media_rc6_attrs }
> > +};
> > +
> > +static int __intel_gt_sysfs_create_group(struct kobject *kobj,
> > +const struct attribute_group *grp)
> > +{
> > + int i = is_object_gt(kobj);
>
> Is_object_gt returns a bool so can I be pedantic? :) Maybe just omit the
> local and solve it like that.
'i' is used also as an array index here, and callse merge/create
depending on what kind of object kobj is.
Maybe it's a bit of an ugly trick, but perhaps to mark the fact I
can do it like
i = !!is_object_gt(kobj);
> > +
> > + return i ? sysfs_create_group(kobj, [i]) :
> > + sysfs_merge_group(kobj, [i]);
> > +}
> > +
> > +static void intel_sysfs_rc6_init(struct intel_gt *gt, struct kobject *kobj)
> > +{
> > + int ret;
> > +
> > + if (!HAS_RC6(gt->i915))
> > + return;
> > +
> > + ret = __intel_gt_sysfs_create_group(kobj, rc6_attr_group);
> > + if (ret)
> > + drm_err(>i915->drm,
> > + "failed to create gt%u RC6 sysfs files\n", gt->info.id);
> > +
> > + if (HAS_RC6p(gt->i915)) {
> > + ret = __intel_gt_sysfs_create_group(kobj, rc6p_attr_group);
> > + if (ret)
> > + drm_err(>i915->drm,
> > + "failed to create gt%u RC6p sysfs files\n",
> > + gt->info.id);
> > + }
> > +
> > + if (IS_VALLEYVIEW(gt->i915) || IS_CHERRYVIEW(gt->i915)) {
> > + ret = __intel_gt_sysfs_create_group(kobj, media_rc6_attr_group);
> > + if (ret)
> > + drm_err(>i915->drm,
> > + "failed to create media %u RC6 sysfs files\n",
> > + gt->info.id);
> > + }
> > +}
[...]
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8480,6 +8480,7 @@ enum {
> > #define GEN6_AGGRESSIVE_TURBO (0 << 15)
> > #define GEN9_SW_REQ_UNSLICE_RATIO_SHIFT 23
> > #define GEN9_IGNORE_SLICE_RATIO (0 << 0)
> > +#define GEN12_SW_REQ_UNSLICE_RATIO_SHIFT 23
>
> Stray something?
I don't know how this ended up here... scary!
> Regards,
>
> Tvrtko
Thanks a lot for looking again into this!
Andi
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
On 17/01/2022 15:09, Andi Shyti wrote: The GT has its own properties and in sysfs they should be grouped in the 'gt/' directory. Create a 'gt/' directory in sysfs which will contain gt0...gtN directories related to each tile configured in the GPU. Move the power management files inside those directories. The previous power management files are kept in their original root directory to avoid breaking the ABI. They point to the tile '0' and a warning message is printed whenever accessed to. The deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2 flag in order to be generated. CONFIG_SYSFS_DEPRECATED_V2 idea was abandoned, no? This patch at least does not appear to contain it so please update the commit message to reflect current state. Adding Joonas to help address the question of how strict are userspace requirements for sysfs additions. Personally sysadmin use sounds fine to me, although it needs to be mentioned/documented as Matt requested, but I fear it may not be enough to upstream. Is Level0 at the stage where we can upstream for it I am also not sure. While I am here I also left some nits below (not full review). The new sysfs structure will have a similar layout for the 4 tile case: /sys/.../card0 ├── gt │ ├── gt0 │ │ ├── id │ │ ├── rc6_enable │ │ ├── rc6_residency_ms │ │ ├── rps_act_freq_mhz │ │ ├── rps_boost_freq_mhz │ │ ├── rps_cur_freq_mhz │ │ ├── rps_max_freq_mhz │ │ ├── rps_min_freq_mhz │ │ ├── rps_RP0_freq_mhz │ │ ├── rps_RP1_freq_mhz │ │ └── rps_RPn_freq_mhz . . . . . . │ └── gt3 │ ├── id │ ├── rc6_enable │ ├── rc6_residency_ms │ ├── rps_act_freq_mhz │ ├── rps_boost_freq_mhz │ ├── rps_cur_freq_mhz │ ├── rps_max_freq_mhz │ ├── rps_min_freq_mhz │ ├── rps_RP0_freq_mhz │ ├── rps_RP1_freq_mhz │ └── rps_RPn_freq_mhz ├── gt_act_freq_mhz -+ ├── gt_boost_freq_mhz | ├── gt_cur_freq_mhz|Original interface ├── gt_max_freq_mhz+─-> kept as existing ABI; ├── gt_min_freq_mhz|it points to gt0/ ├── gt_RP0_freq_mhz| └── gt_RP1_freq_mhz| └── gt_RPn_freq_mhz -+ As soon as multitile platforms will start being supported, this interface will allow to control the power (either manually or with tools) on each tile, instead of affecting only tile 0 and getting incomplete results. Signed-off-by: Andi Shyti Signed-off-by: Lucas De Marchi Cc: Matt Roper Cc: Sujaritha Sundaresan Cc: Tvrtko Ursulin Reviewed-by: Sujaritha Sundaresan --- drivers/gpu/drm/i915/Makefile | 4 +- drivers/gpu/drm/i915/gt/intel_gt.c| 2 + drivers/gpu/drm/i915/gt/sysfs_gt.c| 126 + drivers/gpu/drm/i915/gt/sysfs_gt.h| 44 +++ drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 393 ++ drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++ drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/i915_sysfs.c | 315 + drivers/gpu/drm/i915/i915_sysfs.h | 3 + 10 files changed, 600 insertions(+), 306 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index aa86ac33effc..5fd203c626fc 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -121,7 +121,9 @@ gt-y += \ gt/intel_timeline.o \ gt/intel_workarounds.o \ gt/shmem_utils.o \ - gt/sysfs_engines.o + gt/sysfs_engines.o \ + gt/sysfs_gt.o \ + gt/sysfs_gt_pm.o # autogenerated null render state gt-y += \ gt/gen6_renderstate.o \ diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index 17927da9e23e..2584c51c1c14 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -25,6 +25,7 @@ #include "intel_rps.h" #include "intel_uncore.h" #include "shmem_utils.h" +#include "sysfs_gt.h" #include "pxp/intel_pxp.h" static void @@ -453,6 +454,7 @@ void intel_gt_driver_register(struct intel_gt *gt) intel_rps_driver_register(>rps); intel_gt_debugfs_register(gt); + intel_gt_sysfs_register(gt); } static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size) diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c b/drivers/gpu/drm/i915/gt/sysfs_gt.c new file mode 100644 index
[Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create a 'gt/' directory in sysfs which will contain gt0...gtN
directories related to each tile configured in the GPU. Move the
power management files inside those directories.
The previous power management files are kept in their original
root directory to avoid breaking the ABI. They point to the tile
'0' and a warning message is printed whenever accessed to. The
deprecated interface needs for the CONFIG_SYSFS_DEPRECATED_V2
flag in order to be generated.
The new sysfs structure will have a similar layout for the 4 tile
case:
/sys/.../card0
├── gt
│ ├── gt0
│ │ ├── id
│ │ ├── rc6_enable
│ │ ├── rc6_residency_ms
│ │ ├── rps_act_freq_mhz
│ │ ├── rps_boost_freq_mhz
│ │ ├── rps_cur_freq_mhz
│ │ ├── rps_max_freq_mhz
│ │ ├── rps_min_freq_mhz
│ │ ├── rps_RP0_freq_mhz
│ │ ├── rps_RP1_freq_mhz
│ │ └── rps_RPn_freq_mhz
. .
. .
. .
│ └── gt3
│ ├── id
│ ├── rc6_enable
│ ├── rc6_residency_ms
│ ├── rps_act_freq_mhz
│ ├── rps_boost_freq_mhz
│ ├── rps_cur_freq_mhz
│ ├── rps_max_freq_mhz
│ ├── rps_min_freq_mhz
│ ├── rps_RP0_freq_mhz
│ ├── rps_RP1_freq_mhz
│ └── rps_RPn_freq_mhz
├── gt_act_freq_mhz -+
├── gt_boost_freq_mhz |
├── gt_cur_freq_mhz|Original interface
├── gt_max_freq_mhz+─-> kept as existing ABI;
├── gt_min_freq_mhz|it points to gt0/
├── gt_RP0_freq_mhz|
└── gt_RP1_freq_mhz|
└── gt_RPn_freq_mhz -+
As soon as multitile platforms will start being supported, this
interface will allow to control the power (either manually or
with tools) on each tile, instead of affecting only tile 0 and
getting incomplete results.
Signed-off-by: Andi Shyti
Signed-off-by: Lucas De Marchi
Cc: Matt Roper
Cc: Sujaritha Sundaresan
Cc: Tvrtko Ursulin
Reviewed-by: Sujaritha Sundaresan
---
drivers/gpu/drm/i915/Makefile | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +
drivers/gpu/drm/i915/gt/sysfs_gt.c| 126 +
drivers/gpu/drm/i915/gt/sysfs_gt.h| 44 +++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c | 393 ++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.h | 16 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/i915_sysfs.c | 315 +
drivers/gpu/drm/i915/i915_sysfs.h | 3 +
10 files changed, 600 insertions(+), 306 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index aa86ac33effc..5fd203c626fc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -121,7 +121,9 @@ gt-y += \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
- gt/sysfs_engines.o
+ gt/sysfs_engines.o \
+ gt/sysfs_gt.o \
+ gt/sysfs_gt_pm.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 17927da9e23e..2584c51c1c14 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -25,6 +25,7 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
+#include "sysfs_gt.h"
#include "pxp/intel_pxp.h"
static void
@@ -453,6 +454,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>rps);
intel_gt_debugfs_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c
b/drivers/gpu/drm/i915/gt/sysfs_gt.c
new file mode 100644
index ..46cf033a53ec
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+#include "sysfs_gt.h"
+#include "sysfs_gt_pm.h"
+
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+ const char *name)
+{
+ struct kobject *kobj = >kobj;
+
+ /*
+* We are interested at knowing from where the interface
+* has been
