Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
On 7/21/2022 2:29 AM, Tvrtko Ursulin wrote:
On 19/07/2022 16:29, Ceraolo Spurio, Daniele wrote:
On 7/19/2022 12:34 AM, Tvrtko Ursulin wrote:
On 18/07/2022 17:41, Ceraolo Spurio, Daniele wrote:
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70.
As this
is a quick fix, v69 has been re-introduced as the single
"fallback" guc
version in case v70 is not available on disk. All v69 specific
code has
been labeled as such for easy identification, and the same was
done for
all v70 functions for which there is a separate v69 version, to
avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in
dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow
for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Please check if I got this right:
* ADL-P was out of "force probe" starting from 5.17.
* GuC fw got bumped from v62 to v69 in 5.18.
Does this mean you would also need to handle v62 to avoid
regressing ADL-P from 5.17 to 5.18? I couldn't figure out when
ADL-P switched from execlists to GuC due a bit convoluted
supported/wanted/needed macros etc, so not entirely sure.
I haven't checked about previous GuC versions because the report
from Dave was on the 69->70 transition and about re-introducing v69
support, so I just focused on that. Let me dig on the versions and
on what would be needed to support all 3 revs (if it is required).
Secondly, my concern with the approach like in this patch is that
it would grow the i915 code base *if* there is no incentive to
keep the compatiblity breaking firware updates in check.
The grow of the i915 code is inevitable. Even without changes to
existing platforms, new features for new platforms will require new
GuC interfaces. Sometimes the GuC team also refactors an existing
interface so that it can include a new aspect of an existing
feature. We'll have to discuss with them how to minimize breakages
in such scenarios.
To think about in tandem with this is the question of whether many
more fallback versions need to be handled, even for platforms
which only use GuC to load HuC? Those would also regress in the
media encoding side of things, even if they don't use GuC
submission, right?
The only HuC-only platform is ADL-S and that went out of force
probe when we were on GuC 62, so definitely nothing older than that
will be needed.
I was referring to platforms where HuC is used for some encoding
types. List on
https://github.com/intel/media-driver/blob/master/docs/media_features.md#media-features-summary.
It is not entirely clear to me from that list - you are saying the
HuC is actually used only on ADL-S? I was going by the existence of
HuC firmware files only so might be wrong just as well.
Like GuC, HuC can be enabled via modparam on anything gen11+, but it
is only enabled by default on a subset of platforms, which are all
the platforms for which we enable GuC submission, plus ADL-S. Of
those, the only ones out of force probe are the ADL variants and
their derivatives, so they're the only ones we need to guarantee
backwards compatibility for.
Hm okay, I wasn't aware HuC is not an officially supported thing until
ADL-S. Does that mean there is a document somewhere telling users to
use i915.enable_guc=, maybe on the media driver site,
or somewhere, to get best encoding results on earlier platforms, or
media driver truly cannot use it before ADL-S? I am not saying it's a
problem if there is such guidance, since it is still an unsafe
modparam, just curious.
As far as I'm aware the media team did publish the information around
the enable_guc requirement for pre-ADL platforms, but I don't know where
it was published.
Daniele
See uc_expand_default_options() in intel_uc.c for further details.
Thanks, I was looking for this the other day briefly and failed to
find it. (Was defeated by the auto generated supported/wanted macros,
flags and the web of that.)
Regards,
Tvrtko
Daniele
Regards,
Tvrtko
If this is so, the approach from this patch would feel rushed in
my view.
It totally is, no argument there. As mentioned in the commit
message, the plan is to replace the whole thing with a more
flexible and cleaner mechanism, but we do need something for the
upcoming 5.19 release so there is no time to do this properly from
the get-go.
There is also the question of being able to automatically load the
latest _compatible_ (same major version) GuC fw found on disk. Aka
allowing a bugfix firmware update which does not require a kernel
update. In theory should be possible but we don't have that
implemented either, right?
We do not. Something like this was
Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
On 19/07/2022 16:29, Ceraolo Spurio, Daniele wrote:
On 7/19/2022 12:34 AM, Tvrtko Ursulin wrote:
On 18/07/2022 17:41, Ceraolo Spurio, Daniele wrote:
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As
this
is a quick fix, v69 has been re-introduced as the single "fallback"
guc
version in case v70 is not available on disk. All v69 specific code
has
been labeled as such for easy identification, and the same was done
for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in
dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Please check if I got this right:
* ADL-P was out of "force probe" starting from 5.17.
* GuC fw got bumped from v62 to v69 in 5.18.
Does this mean you would also need to handle v62 to avoid regressing
ADL-P from 5.17 to 5.18? I couldn't figure out when ADL-P switched
from execlists to GuC due a bit convoluted supported/wanted/needed
macros etc, so not entirely sure.
I haven't checked about previous GuC versions because the report from
Dave was on the 69->70 transition and about re-introducing v69
support, so I just focused on that. Let me dig on the versions and on
what would be needed to support all 3 revs (if it is required).
Secondly, my concern with the approach like in this patch is that it
would grow the i915 code base *if* there is no incentive to keep the
compatiblity breaking firware updates in check.
The grow of the i915 code is inevitable. Even without changes to
existing platforms, new features for new platforms will require new
GuC interfaces. Sometimes the GuC team also refactors an existing
interface so that it can include a new aspect of an existing feature.
We'll have to discuss with them how to minimize breakages in such
scenarios.
To think about in tandem with this is the question of whether many
more fallback versions need to be handled, even for platforms which
only use GuC to load HuC? Those would also regress in the media
encoding side of things, even if they don't use GuC submission, right?
The only HuC-only platform is ADL-S and that went out of force probe
when we were on GuC 62, so definitely nothing older than that will be
needed.
I was referring to platforms where HuC is used for some encoding
types. List on
https://github.com/intel/media-driver/blob/master/docs/media_features.md#media-features-summary.
It is not entirely clear to me from that list - you are saying the HuC
is actually used only on ADL-S? I was going by the existence of HuC
firmware files only so might be wrong just as well.
Like GuC, HuC can be enabled via modparam on anything gen11+, but it is
only enabled by default on a subset of platforms, which are all the
platforms for which we enable GuC submission, plus ADL-S. Of those, the
only ones out of force probe are the ADL variants and their derivatives,
so they're the only ones we need to guarantee backwards compatibility for.
Hm okay, I wasn't aware HuC is not an officially supported thing until
ADL-S. Does that mean there is a document somewhere telling users to use
i915.enable_guc=, maybe on the media driver site, or
somewhere, to get best encoding results on earlier platforms, or media
driver truly cannot use it before ADL-S? I am not saying it's a problem
if there is such guidance, since it is still an unsafe modparam, just
curious.
See uc_expand_default_options() in intel_uc.c for further details.
Thanks, I was looking for this the other day briefly and failed to find
it. (Was defeated by the auto generated supported/wanted macros, flags
and the web of that.)
Regards,
Tvrtko
Daniele
Regards,
Tvrtko
If this is so, the approach from this patch would feel rushed in my
view.
It totally is, no argument there. As mentioned in the commit message,
the plan is to replace the whole thing with a more flexible and
cleaner mechanism, but we do need something for the upcoming 5.19
release so there is no time to do this properly from the get-go.
There is also the question of being able to automatically load the
latest _compatible_ (same major version) GuC fw found on disk. Aka
allowing a bugfix firmware update which does not require a kernel
update. In theory should be possible but we don't have that
implemented either, right?
We do not. Something like this was actually shot down when GuC first
came around. We used to have simlinks for the GuC binary to be able
to drop in a replacement like you said, but there were concerns about
how to validate all the possible kernel:fw
Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
On 7/19/2022 12:34 AM, Tvrtko Ursulin wrote:
On 18/07/2022 17:41, Ceraolo Spurio, Daniele wrote:
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As
this
is a quick fix, v69 has been re-introduced as the single "fallback"
guc
version in case v70 is not available on disk. All v69 specific code
has
been labeled as such for easy identification, and the same was done
for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in
dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Please check if I got this right:
* ADL-P was out of "force probe" starting from 5.17.
* GuC fw got bumped from v62 to v69 in 5.18.
Does this mean you would also need to handle v62 to avoid regressing
ADL-P from 5.17 to 5.18? I couldn't figure out when ADL-P switched
from execlists to GuC due a bit convoluted supported/wanted/needed
macros etc, so not entirely sure.
I haven't checked about previous GuC versions because the report from
Dave was on the 69->70 transition and about re-introducing v69
support, so I just focused on that. Let me dig on the versions and on
what would be needed to support all 3 revs (if it is required).
Secondly, my concern with the approach like in this patch is that it
would grow the i915 code base *if* there is no incentive to keep the
compatiblity breaking firware updates in check.
The grow of the i915 code is inevitable. Even without changes to
existing platforms, new features for new platforms will require new
GuC interfaces. Sometimes the GuC team also refactors an existing
interface so that it can include a new aspect of an existing feature.
We'll have to discuss with them how to minimize breakages in such
scenarios.
To think about in tandem with this is the question of whether many
more fallback versions need to be handled, even for platforms which
only use GuC to load HuC? Those would also regress in the media
encoding side of things, even if they don't use GuC submission, right?
The only HuC-only platform is ADL-S and that went out of force probe
when we were on GuC 62, so definitely nothing older than that will be
needed.
I was referring to platforms where HuC is used for some encoding
types. List on
https://github.com/intel/media-driver/blob/master/docs/media_features.md#media-features-summary.
It is not entirely clear to me from that list - you are saying the HuC
is actually used only on ADL-S? I was going by the existence of HuC
firmware files only so might be wrong just as well.
Like GuC, HuC can be enabled via modparam on anything gen11+, but it is
only enabled by default on a subset of platforms, which are all the
platforms for which we enable GuC submission, plus ADL-S. Of those, the
only ones out of force probe are the ADL variants and their derivatives,
so they're the only ones we need to guarantee backwards compatibility for.
See uc_expand_default_options() in intel_uc.c for further details.
Daniele
Regards,
Tvrtko
If this is so, the approach from this patch would feel rushed in my
view.
It totally is, no argument there. As mentioned in the commit message,
the plan is to replace the whole thing with a more flexible and
cleaner mechanism, but we do need something for the upcoming 5.19
release so there is no time to do this properly from the get-go.
There is also the question of being able to automatically load the
latest _compatible_ (same major version) GuC fw found on disk. Aka
allowing a bugfix firmware update which does not require a kernel
update. In theory should be possible but we don't have that
implemented either, right?
We do not. Something like this was actually shot down when GuC first
came around. We used to have simlinks for the GuC binary to be able
to drop in a replacement like you said, but there were concerns about
how to validate all the possible kernel:fw combinations this could
cause, hence why in the end we went with the exact match model. Note
that at the time we didn't have a patch number for bugfix tracking in
GuC, so the decision made more sense back then than it does now.
We've already restarted the discussion internally.
Daniele
Regards,
Tvrtko
Link:
https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5 +
Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
On 18/07/2022 17:41, Ceraolo Spurio, Daniele wrote:
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Please check if I got this right:
* ADL-P was out of "force probe" starting from 5.17.
* GuC fw got bumped from v62 to v69 in 5.18.
Does this mean you would also need to handle v62 to avoid regressing
ADL-P from 5.17 to 5.18? I couldn't figure out when ADL-P switched
from execlists to GuC due a bit convoluted supported/wanted/needed
macros etc, so not entirely sure.
I haven't checked about previous GuC versions because the report from
Dave was on the 69->70 transition and about re-introducing v69 support,
so I just focused on that. Let me dig on the versions and on what would
be needed to support all 3 revs (if it is required).
Secondly, my concern with the approach like in this patch is that it
would grow the i915 code base *if* there is no incentive to keep the
compatiblity breaking firware updates in check.
The grow of the i915 code is inevitable. Even without changes to
existing platforms, new features for new platforms will require new GuC
interfaces. Sometimes the GuC team also refactors an existing interface
so that it can include a new aspect of an existing feature. We'll have
to discuss with them how to minimize breakages in such scenarios.
To think about in tandem with this is the question of whether many
more fallback versions need to be handled, even for platforms which
only use GuC to load HuC? Those would also regress in the media
encoding side of things, even if they don't use GuC submission, right?
The only HuC-only platform is ADL-S and that went out of force probe
when we were on GuC 62, so definitely nothing older than that will be
needed.
I was referring to platforms where HuC is used for some encoding types.
List on
https://github.com/intel/media-driver/blob/master/docs/media_features.md#media-features-summary.
It is not entirely clear to me from that list - you are saying the HuC
is actually used only on ADL-S? I was going by the existence of HuC
firmware files only so might be wrong just as well.
Regards,
Tvrtko
If this is so, the approach from this patch would feel rushed in my view.
It totally is, no argument there. As mentioned in the commit message,
the plan is to replace the whole thing with a more flexible and cleaner
mechanism, but we do need something for the upcoming 5.19 release so
there is no time to do this properly from the get-go.
There is also the question of being able to automatically load the
latest _compatible_ (same major version) GuC fw found on disk. Aka
allowing a bugfix firmware update which does not require a kernel
update. In theory should be possible but we don't have that
implemented either, right?
We do not. Something like this was actually shot down when GuC first
came around. We used to have simlinks for the GuC binary to be able to
drop in a replacement like you said, but there were concerns about how
to validate all the possible kernel:fw combinations this could cause,
hence why in the end we went with the exact match model. Note that at
the time we didn't have a patch number for bugfix tracking in GuC, so
the decision made more sense back then than it does now. We've already
restarted the discussion internally.
Daniele
Regards,
Tvrtko
Link:
https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++
Re: [PATCH] drm/i915/guc: support v69 in parallel to v70
On 7/18/2022 2:19 PM, John Harrison wrote:
On 7/15/2022 15:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Link:
https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
- /** @wqi_head: head pointer in work queue */
+ /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
- /** @wqi_tail: tail pointer in work queue */
+ /** @wqi_tail: cached tail pointer in work queue */
u16 wqi_tail;
+ /** @wq_head: pointer to the actual head in work queue */
+ u32 *wq_head;
+ /** @wq_tail: pointer to the actual head in work queue */
+ u32 *wq_tail;
+ /** @wq_status: pointer to the status in work queue */
+ u32 *wq_status;
+
/**
* @parent_page: page in context state (ce->state) used
* by parent for work queue, process descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..29ef8afc8c2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,6 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PRIORITY = 0x1005,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index d0d99f178f2d..a7acffbf15d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -170,6 +170,11 @@ struct intel_guc {
/** @ads_engine_usage_size: size of engine usage in the ADS */
u32 ads_engine_usage_size;
+ /** @lrc_desc_pool_v69: object allocated to hold the GuC LRC
descriptor pool */
+ struct i915_vma *lrc_desc_pool_v69;
+ /** @lrc_desc_pool_vaddr_v69: contents of the GuC LRC descriptor
pool */
+ void *lrc_desc_pool_vaddr_v69;
+
/**
* @context_lookup: used to resolve intel_context from guc_id,
if a
* context is present in this structure it is registered with
the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index b3c9a9327f76..323b055e5db9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -204,6 +204,20 @@ struct guc_wq_item {
u32 fence_id;
} __packed;
+struct guc_process_desc_v69 {
+ u32 stage_id;
+ u64 db_base_addr;
+ u32 head;
+ u32 tail;
+ u32 error_offset;
+ u64 wq_base_addr;
+ u32 wq_size_bytes;
+ u32 wq_status;
+ u32 engine_presence;
+ u32 priority;
+ u32 reserved[36];
+} __packed;
+
struct guc_sched_wq_desc {
u32 head;
u32 tail;
@@ -228,6 +242,37 @@ struct
Re: [PATCH] drm/i915/guc: support v69 in parallel to v70
On 7/15/2022 15:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
- /** @wqi_head: head pointer in work queue */
+ /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
- /** @wqi_tail: tail pointer in work queue */
+ /** @wqi_tail: cached tail pointer in work queue */
u16 wqi_tail;
+ /** @wq_head: pointer to the actual head in work queue
*/
+ u32 *wq_head;
+ /** @wq_tail: pointer to the actual head in work queue
*/
+ u32 *wq_tail;
+ /** @wq_status: pointer to the status in work queue */
+ u32 *wq_status;
+
/**
* @parent_page: page in context state (ce->state) used
* by parent for work queue, process descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..29ef8afc8c2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,6 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PRIORITY = 0x1005,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index d0d99f178f2d..a7acffbf15d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -170,6 +170,11 @@ struct intel_guc {
/** @ads_engine_usage_size: size of engine usage in the ADS */
u32 ads_engine_usage_size;
+ /** @lrc_desc_pool_v69: object allocated to hold the GuC LRC descriptor pool */
+ struct i915_vma *lrc_desc_pool_v69;
+ /** @lrc_desc_pool_vaddr_v69: contents of the GuC LRC descriptor pool */
+ void *lrc_desc_pool_vaddr_v69;
+
/**
* @context_lookup: used to resolve intel_context from guc_id, if a
* context is present in this structure it is registered with the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index b3c9a9327f76..323b055e5db9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -204,6 +204,20 @@ struct guc_wq_item {
u32 fence_id;
} __packed;
+struct guc_process_desc_v69 {
+ u32 stage_id;
+ u64 db_base_addr;
+ u32 head;
+ u32 tail;
+ u32 error_offset;
+ u64 wq_base_addr;
+ u32 wq_size_bytes;
+ u32 wq_status;
+
Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
On Mon, Jul 18, 2022 at 11:02:03AM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
> > This patch re-introduces support for GuC v69 in parallel to v70. As this
> > is a quick fix, v69 has been re-introduced as the single "fallback" guc
> > version in case v70 is not available on disk. All v69 specific code has
> > been labeled as such for easy identification, and the same was done for
> > all v70 functions for which there is a separate v69 version, to avoid
> > accidentally calling the wrong version via the unlabeled name.
> >
> > When the fallback mode kicks in, a drm_warn message is printed in dmesg
> > to warn the user of the required update.
> >
> > The plan is to follow this up with a more complex rework to allow for
> > multiple different GuC versions to be supported at the same time.
> >
> > Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
>
> Please check if I got this right:
>
> * ADL-P was out of "force probe" starting from 5.17.
> * GuC fw got bumped from v62 to v69 in 5.18.
the team had looked to get v62 right now, but that would be too disruptive
and risky for the 5.19.
For now we are going with this fallback to v69 to solve the 5.19 regression.
Then look to solve the v62 regressions with the -stable fixes as a next step.
Dave had agreed with this approach.
Thanks,
Rodrigo.
btw:
Acked-by: Rodrigo Vivi
>
> Does this mean you would also need to handle v62 to avoid regressing ADL-P
> from 5.17 to 5.18? I couldn't figure out when ADL-P switched from execlists
> to GuC due a bit convoluted supported/wanted/needed macros etc, so not
> entirely sure.
>
> Secondly, my concern with the approach like in this patch is that it would
> grow the i915 code base *if* there is no incentive to keep the compatiblity
> breaking firware updates in check.
>
> To think about in tandem with this is the question of whether many more
> fallback versions need to be handled, even for platforms which only use GuC
> to load HuC? Those would also regress in the media encoding side of things,
> even if they don't use GuC submission, right?
>
> If this is so, the approach from this patch would feel rushed in my view.
>
> There is also the question of being able to automatically load the latest
> _compatible_ (same major version) GuC fw found on disk. Aka allowing a
> bugfix firmware update which does not require a kernel update. In theory
> should be possible but we don't have that implemented either, right?
>
> Regards,
>
> Tvrtko
>
> > Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
> > Signed-off-by: Daniele Ceraolo Spurio
> > Cc: John Harrison
> > Cc: Matthew Brost
> > Cc: Matt Roper
> > Cc: Dave Airlie
> > ---
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
> > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
> > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
> > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
> > 7 files changed, 419 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index d2d75d9c0c8d..04eacae1aca5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -275,10 +275,17 @@ struct intel_context {
> > u8 child_index;
> > /** @guc: GuC specific members for parallel submission */
> > struct {
> > - /** @wqi_head: head pointer in work queue */
> > + /** @wqi_head: cached head pointer in work queue */
> > u16 wqi_head;
> > - /** @wqi_tail: tail pointer in work queue */
> > + /** @wqi_tail: cached tail pointer in work queue */
> > u16 wqi_tail;
> > + /** @wq_head: pointer to the actual head in work queue
> > */
> > + u32 *wq_head;
> > + /** @wq_tail: pointer to the actual head in work queue
> > */
> > + u32 *wq_tail;
> > + /** @wq_status: pointer to the status in work queue */
> > + u32 *wq_status;
> > +
> > /**
> > * @parent_page: page in context state (ce->state) used
> > * by parent for work queue, process descriptor
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > index 4ef9990ed7f8..29ef8afc8c2e 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > @@ -122,6 +122,9 @@ enum intel_guc_action {
> >
Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
On 7/18/2022 3:02 AM, Tvrtko Ursulin wrote:
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Please check if I got this right:
* ADL-P was out of "force probe" starting from 5.17.
* GuC fw got bumped from v62 to v69 in 5.18.
Does this mean you would also need to handle v62 to avoid regressing
ADL-P from 5.17 to 5.18? I couldn't figure out when ADL-P switched
from execlists to GuC due a bit convoluted supported/wanted/needed
macros etc, so not entirely sure.
I haven't checked about previous GuC versions because the report from
Dave was on the 69->70 transition and about re-introducing v69 support,
so I just focused on that. Let me dig on the versions and on what would
be needed to support all 3 revs (if it is required).
Secondly, my concern with the approach like in this patch is that it
would grow the i915 code base *if* there is no incentive to keep the
compatiblity breaking firware updates in check.
The grow of the i915 code is inevitable. Even without changes to
existing platforms, new features for new platforms will require new GuC
interfaces. Sometimes the GuC team also refactors an existing interface
so that it can include a new aspect of an existing feature. We'll have
to discuss with them how to minimize breakages in such scenarios.
To think about in tandem with this is the question of whether many
more fallback versions need to be handled, even for platforms which
only use GuC to load HuC? Those would also regress in the media
encoding side of things, even if they don't use GuC submission, right?
The only HuC-only platform is ADL-S and that went out of force probe
when we were on GuC 62, so definitely nothing older than that will be
needed.
If this is so, the approach from this patch would feel rushed in my view.
It totally is, no argument there. As mentioned in the commit message,
the plan is to replace the whole thing with a more flexible and cleaner
mechanism, but we do need something for the upcoming 5.19 release so
there is no time to do this properly from the get-go.
There is also the question of being able to automatically load the
latest _compatible_ (same major version) GuC fw found on disk. Aka
allowing a bugfix firmware update which does not require a kernel
update. In theory should be possible but we don't have that
implemented either, right?
We do not. Something like this was actually shot down when GuC first
came around. We used to have simlinks for the GuC binary to be able to
drop in a replacement like you said, but there were concerns about how
to validate all the possible kernel:fw combinations this could cause,
hence why in the end we went with the exact match model. Note that at
the time we didn't have a patch number for bugfix tracking in GuC, so
the decision made more sense back then than it does now. We've already
restarted the discussion internally.
Daniele
Regards,
Tvrtko
Link:
https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
- /** @wqi_head: head pointer in work queue */
+ /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
- /** @wqi_tail: tail pointer in work queue */
+ /** @wqi_tail:
Re: [Intel-gfx] [PATCH] drm/i915/guc: support v69 in parallel to v70
Hi,
On 15/07/2022 23:54, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Please check if I got this right:
* ADL-P was out of "force probe" starting from 5.17.
* GuC fw got bumped from v62 to v69 in 5.18.
Does this mean you would also need to handle v62 to avoid regressing
ADL-P from 5.17 to 5.18? I couldn't figure out when ADL-P switched from
execlists to GuC due a bit convoluted supported/wanted/needed macros
etc, so not entirely sure.
Secondly, my concern with the approach like in this patch is that it
would grow the i915 code base *if* there is no incentive to keep the
compatiblity breaking firware updates in check.
To think about in tandem with this is the question of whether many more
fallback versions need to be handled, even for platforms which only use
GuC to load HuC? Those would also regress in the media encoding side of
things, even if they don't use GuC submission, right?
If this is so, the approach from this patch would feel rushed in my view.
There is also the question of being able to automatically load the
latest _compatible_ (same major version) GuC fw found on disk. Aka
allowing a bugfix firmware update which does not require a kernel
update. In theory should be possible but we don't have that implemented
either, right?
Regards,
Tvrtko
Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
- /** @wqi_head: head pointer in work queue */
+ /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
- /** @wqi_tail: tail pointer in work queue */
+ /** @wqi_tail: cached tail pointer in work queue */
u16 wqi_tail;
+ /** @wq_head: pointer to the actual head in work queue
*/
+ u32 *wq_head;
+ /** @wq_tail: pointer to the actual head in work queue
*/
+ u32 *wq_tail;
+ /** @wq_status: pointer to the status in work queue */
+ u32 *wq_status;
+
/**
* @parent_page: page in context state (ce->state) used
* by parent for work queue, process descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..29ef8afc8c2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,6 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PRIORITY = 0x1005,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
Re: [PATCH] drm/i915/guc: support v69 in parallel to v70
On 7/15/2022 3:54 PM, Daniele Ceraolo Spurio wrote:
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
I've sent a slightly earlier version of this patch (cosmetic changes
only) to trybot with an hack to change the default GuC to v80 so that
the fallback would kick in:
https://patchwork.freedesktop.org/series/106390/
No regression seen due to the fallback. Note that for this trybot I've
reduced the fallback log from drm_warn to drm_notice to avoid CI failing
all the tests that reload i915.
Daniele
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
- /** @wqi_head: head pointer in work queue */
+ /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
- /** @wqi_tail: tail pointer in work queue */
+ /** @wqi_tail: cached tail pointer in work queue */
u16 wqi_tail;
+ /** @wq_head: pointer to the actual head in work queue
*/
+ u32 *wq_head;
+ /** @wq_tail: pointer to the actual head in work queue
*/
+ u32 *wq_tail;
+ /** @wq_status: pointer to the status in work queue */
+ u32 *wq_status;
+
/**
* @parent_page: page in context state (ce->state) used
* by parent for work queue, process descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..29ef8afc8c2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,6 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PRIORITY = 0x1005,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index d0d99f178f2d..a7acffbf15d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -170,6 +170,11 @@ struct intel_guc {
/** @ads_engine_usage_size: size of engine usage in the ADS */
u32 ads_engine_usage_size;
+ /** @lrc_desc_pool_v69: object allocated to hold the GuC LRC descriptor pool */
+ struct i915_vma *lrc_desc_pool_v69;
+ /** @lrc_desc_pool_vaddr_v69: contents of the GuC LRC descriptor pool */
+ void *lrc_desc_pool_vaddr_v69;
+
/**
* @context_lookup: used to resolve intel_context from guc_id, if a
* context is present in this structure it is registered with the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index
[PATCH] drm/i915/guc: support v69 in parallel to v70
This patch re-introduces support for GuC v69 in parallel to v70. As this
is a quick fix, v69 has been re-introduced as the single "fallback" guc
version in case v70 is not available on disk. All v69 specific code has
been labeled as such for easy identification, and the same was done for
all v70 functions for which there is a separate v69 version, to avoid
accidentally calling the wrong version via the unlabeled name.
When the fallback mode kicks in, a drm_warn message is printed in dmesg
to warn the user of the required update.
The plan is to follow this up with a more complex rework to allow for
multiple different GuC versions to be supported at the same time.
Fixes: 2584b3549f4c ("drm/i915/guc: Update to GuC version 70.1.1")
Link: https://lists.freedesktop.org/archives/intel-gfx/2022-July/301640.html
Signed-off-by: Daniele Ceraolo Spurio
Cc: John Harrison
Cc: Matthew Brost
Cc: Matt Roper
Cc: Dave Airlie
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 11 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 3 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 45 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 348 +++---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 57 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 7 +
7 files changed, 419 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index d2d75d9c0c8d..04eacae1aca5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -275,10 +275,17 @@ struct intel_context {
u8 child_index;
/** @guc: GuC specific members for parallel submission */
struct {
- /** @wqi_head: head pointer in work queue */
+ /** @wqi_head: cached head pointer in work queue */
u16 wqi_head;
- /** @wqi_tail: tail pointer in work queue */
+ /** @wqi_tail: cached tail pointer in work queue */
u16 wqi_tail;
+ /** @wq_head: pointer to the actual head in work queue
*/
+ u32 *wq_head;
+ /** @wq_tail: pointer to the actual head in work queue
*/
+ u32 *wq_tail;
+ /** @wq_status: pointer to the status in work queue */
+ u32 *wq_status;
+
/**
* @parent_page: page in context state (ce->state) used
* by parent for work queue, process descriptor
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..29ef8afc8c2e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -122,6 +122,9 @@ enum intel_guc_action {
INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PRIORITY = 0x1005,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+ INTEL_GUC_ACTION_V69_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_HOST2GUC_UPDATE_CONTEXT_POLICIES = 0x100B,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index d0d99f178f2d..a7acffbf15d1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -170,6 +170,11 @@ struct intel_guc {
/** @ads_engine_usage_size: size of engine usage in the ADS */
u32 ads_engine_usage_size;
+ /** @lrc_desc_pool_v69: object allocated to hold the GuC LRC descriptor
pool */
+ struct i915_vma *lrc_desc_pool_v69;
+ /** @lrc_desc_pool_vaddr_v69: contents of the GuC LRC descriptor pool */
+ void *lrc_desc_pool_vaddr_v69;
+
/**
* @context_lookup: used to resolve intel_context from guc_id, if a
* context is present in this structure it is registered with the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index b3c9a9327f76..323b055e5db9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -204,6 +204,20 @@ struct guc_wq_item {
u32 fence_id;
} __packed;
+struct guc_process_desc_v69 {
+ u32 stage_id;
+ u64 db_base_addr;
+ u32 head;
+ u32 tail;
+ u32 error_offset;
+ u64 wq_base_addr;
+ u32 wq_size_bytes;
+ u32 wq_status;
+ u32 engine_presence;
+ u32 priority;
+
