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 a
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 combinations
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 + drive
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 +++ b/dr
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 guc_ctxt_registratio
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 { > > 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: cached
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 i
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 b3c9a9327f76..323b0
[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; + u32