* Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 17:45 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 17:45 UTC (permalink / raw)
To: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> GuC ABI documentation is now ready to be included in i915.rst
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Michal - I noticed while putting this series together that there is
kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
think we should add the those here or in a new section (e.g. GuC CTBs)?
Let me know what you think and I can fix this up before this gets
merged.
With that, for this patch:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> Documentation/gpu/i915.rst | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..c7846b1d9293 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -518,6 +518,14 @@ GuC-based command submission
> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> :doc: GuC-based command submission
>
> +GuC ABI
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> +
> HuC
> ---
> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
@ 2021-06-07 17:45 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 17:45 UTC (permalink / raw)
To: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> GuC ABI documentation is now ready to be included in i915.rst
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Michal - I noticed while putting this series together that there is
kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
think we should add the those here or in a new section (e.g. GuC CTBs)?
Let me know what you think and I can fix this up before this gets
merged.
With that, for this patch:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> Documentation/gpu/i915.rst | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..c7846b1d9293 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -518,6 +518,14 @@ GuC-based command submission
> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> :doc: GuC-based command submission
>
> +GuC ABI
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> +
> HuC
> ---
> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 17:57 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 17:57 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
On Mon, Jun 07, 2021 at 11:03:52AM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> CTB pool is now maintained internally by the GuC as part of its
> "private data". No need to allocate separate buffer and pass it
> to GuC as yet another ADS.
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com> #v4
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 12 ------------
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +-----------
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 4fcbe4b921f9..6e26fe04ce92 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -26,8 +26,6 @@
> * +---------------------------------------+
> * | guc_clients_info |
> * +---------------------------------------+
> - * | guc_ct_pool_entry[size] |
> - * +---------------------------------------+
> * | padding |
> * +---------------------------------------+ <== 4K aligned
> * | private data |
> @@ -40,7 +38,6 @@ struct __guc_ads_blob {
> struct guc_policies policies;
> struct guc_gt_system_info system_info;
> struct guc_clients_info clients_info;
> - struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
> } __packed;
>
> static u32 guc_ads_private_data_size(struct intel_guc *guc)
> @@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies *policies)
> policies->is_valid = 1;
> }
>
> -static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
> -{
> - memset(pool, 0, num * sizeof(*pool));
> -}
> -
> static void guc_mapping_table_init(struct intel_gt *gt,
> struct guc_gt_system_info *system_info)
> {
> @@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
> base = intel_guc_ggtt_offset(guc, guc->ads_vma);
>
> /* Clients info */
> - guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
> -
> blob->clients_info.clients_num = 1;
> - blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
> - blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
>
> /* ADS */
> blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
> 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 251c3836bd2c..2266444d074f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -295,19 +295,9 @@ struct guc_gt_system_info {
> } __packed;
>
> /* Clients info */
> -struct guc_ct_pool_entry {
> - struct guc_ct_buffer_desc desc;
> - u32 reserved[7];
> -} __packed;
> -
> -#define GUC_CT_POOL_SIZE 2
> -
> struct guc_clients_info {
> u32 clients_num;
> - u32 reserved0[13];
> - u32 ct_pool_addr;
> - u32 ct_pool_count;
> - u32 reserved[4];
> + u32 reserved[19];
> } __packed;
>
> /* GuC Additional Data Struct */
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool
@ 2021-06-07 17:57 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 17:57 UTC (permalink / raw)
To: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 11:03:52AM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> CTB pool is now maintained internally by the GuC as part of its
> "private data". No need to allocate separate buffer and pass it
> to GuC as yet another ADS.
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com> #v4
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 12 ------------
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +-----------
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 4fcbe4b921f9..6e26fe04ce92 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -26,8 +26,6 @@
> * +---------------------------------------+
> * | guc_clients_info |
> * +---------------------------------------+
> - * | guc_ct_pool_entry[size] |
> - * +---------------------------------------+
> * | padding |
> * +---------------------------------------+ <== 4K aligned
> * | private data |
> @@ -40,7 +38,6 @@ struct __guc_ads_blob {
> struct guc_policies policies;
> struct guc_gt_system_info system_info;
> struct guc_clients_info clients_info;
> - struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
> } __packed;
>
> static u32 guc_ads_private_data_size(struct intel_guc *guc)
> @@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies *policies)
> policies->is_valid = 1;
> }
>
> -static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
> -{
> - memset(pool, 0, num * sizeof(*pool));
> -}
> -
> static void guc_mapping_table_init(struct intel_gt *gt,
> struct guc_gt_system_info *system_info)
> {
> @@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
> base = intel_guc_ggtt_offset(guc, guc->ads_vma);
>
> /* Clients info */
> - guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
> -
> blob->clients_info.clients_num = 1;
> - blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
> - blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
>
> /* ADS */
> blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
> 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 251c3836bd2c..2266444d074f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -295,19 +295,9 @@ struct guc_gt_system_info {
> } __packed;
>
> /* Clients info */
> -struct guc_ct_pool_entry {
> - struct guc_ct_buffer_desc desc;
> - u32 reserved[7];
> -} __packed;
> -
> -#define GUC_CT_POOL_SIZE 2
> -
> struct guc_clients_info {
> u32 clients_num;
> - u32 reserved0[13];
> - u32 ct_pool_addr;
> - u32 ct_pool_count;
> - u32 reserved[4];
> + u32 reserved[19];
> } __packed;
>
> /* GuC Additional Data Struct */
> --
> 2.28.0
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 00/13] Update firmware to v62.0.0
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. This is a destructive
change. e.g. Without all the patches in this series it will break the
i915 driver. As such, after we review all of these patches they will
squashed into a single patch for merging.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
[1] https://patchwork.freedesktop.org/series/89844/
John Harrison (3):
drm/i915/guc: Support per context scheduling policies
drm/i915/guc: Unified GuC log
drm/i915/guc: Update firmware to v62.0.0
Michal Wajdeczko (10):
drm/i915/guc: Introduce unified HXG messages
drm/i915/guc: Update MMIO based communication
drm/i915/guc: Update CTB response status definition
drm/i915/guc: Add flag for mark broken CTB
drm/i915/guc: New definition of the CTB descriptor
drm/i915/guc: New definition of the CTB registration action
drm/i915/guc: New CTB based communication
drm/i915/doc: Include GuC ABI documentation
drm/i915/guc: Kill guc_clients.ct_pool
drm/i915/guc: Kill ads.client_info
Documentation/gpu/i915.rst | 8 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++
.../gt/uc/abi/guc_communication_ctb_abi.h | 130 +++++--
.../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--
.../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++++++++++
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 107 ++++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 45 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +++++++++---------
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 75 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 +-
13 files changed, 750 insertions(+), 420 deletions(-)
--
2.28.0
^ permalink raw reply [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
As part of enabling GuC submission [1] we need to update to the latest
and greatest firmware. This series does that. This is a destructive
change. e.g. Without all the patches in this series it will break the
i915 driver. As such, after we review all of these patches they will
squashed into a single patch for merging.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
[1] https://patchwork.freedesktop.org/series/89844/
John Harrison (3):
drm/i915/guc: Support per context scheduling policies
drm/i915/guc: Unified GuC log
drm/i915/guc: Update firmware to v62.0.0
Michal Wajdeczko (10):
drm/i915/guc: Introduce unified HXG messages
drm/i915/guc: Update MMIO based communication
drm/i915/guc: Update CTB response status definition
drm/i915/guc: Add flag for mark broken CTB
drm/i915/guc: New definition of the CTB descriptor
drm/i915/guc: New definition of the CTB registration action
drm/i915/guc: New CTB based communication
drm/i915/doc: Include GuC ABI documentation
drm/i915/guc: Kill guc_clients.ct_pool
drm/i915/guc: Kill ads.client_info
Documentation/gpu/i915.rst | 8 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++
.../gt/uc/abi/guc_communication_ctb_abi.h | 130 +++++--
.../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--
.../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++++++++++
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 107 ++++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 45 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +++++++++---------
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 75 +---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 +-
13 files changed, 750 insertions(+), 420 deletions(-)
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
---
.../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++++++++++++++++++
1 file changed, 213 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
index 775e21f3058c..29ac823acd4c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
@@ -6,6 +6,219 @@
#ifndef _ABI_GUC_MESSAGES_ABI_H
#define _ABI_GUC_MESSAGES_ABI_H
+/**
+ * DOC: HXG Message
+ *
+ * All messages exchanged with GuC are defined using 32 bit dwords.
+ * First dword is treated as a message header. Remaining dwords are optional.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | | | |
+ * | 0 | 31 | **ORIGIN** - originator of the message |
+ * | | | - _`GUC_HXG_ORIGIN_HOST` = 0 |
+ * | | | - _`GUC_HXG_ORIGIN_GUC` = 1 |
+ * | | | |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | **TYPE** - message type |
+ * | | | - _`GUC_HXG_TYPE_REQUEST` = 0 |
+ * | | | - _`GUC_HXG_TYPE_EVENT` = 1 |
+ * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 |
+ * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5 |
+ * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 |
+ * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **AUX** - auxiliary data (depends on TYPE) |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **PAYLOAD** - optional payload (depends on TYPE) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_MSG_MIN_LEN 1u
+#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
+#define GUC_HXG_ORIGIN_HOST 0u
+#define GUC_HXG_ORIGIN_GUC 1u
+#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
+#define GUC_HXG_TYPE_REQUEST 0u
+#define GUC_HXG_TYPE_EVENT 1u
+#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
+#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u
+#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
+#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
+#define GUC_HXG_MSG_0_AUX (0xfffffff << 0)
+#define GUC_HXG_MSG_n_PAYLOAD (0xffffffff << 0)
+
+/**
+ * DOC: HXG Request
+ *
+ * The `HXG Request`_ message should be used to initiate synchronous activity
+ * for which confirmation or return data is expected.
+ *
+ * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
+ * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
+ * message as a intermediate reply.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | **DATA0** - request data (depends on ACTION) |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | **ACTION** - requested action code |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **DATAn** - optional data (depends on ACTION) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_REQUEST_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_REQUEST_MSG_0_DATA0 (0xfff << 16)
+#define GUC_HXG_REQUEST_MSG_0_ACTION (0xffff << 0)
+#define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
+
+/**
+ * DOC: HXG Event
+ *
+ * The `HXG Event`_ message should be used to initiate asynchronous activity
+ * that does not involves immediate confirmation nor data.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_EVENT_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | **DATA0** - event data (depends on ACTION) |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | **ACTION** - event action code |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **DATAn** - optional event data (depends on ACTION) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_EVENT_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_EVENT_MSG_0_DATA0 (0xfff << 16)
+#define GUC_HXG_EVENT_MSG_0_ACTION (0xffff << 0)
+#define GUC_HXG_EVENT_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
+
+/**
+ * DOC: HXG Busy
+ *
+ * The `HXG Busy`_ message may be used to acknowledge reception of the `HXG Request`_
+ * message if the recipient expects that it processing will be longer than default
+ * timeout.
+ *
+ * The @COUNTER field may be used as a progress indicator.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_BUSY_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **COUNTER** - progress indicator |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_BUSY_MSG_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_BUSY_MSG_0_COUNTER GUC_HXG_MSG_0_AUX
+
+/**
+ * DOC: HXG Retry
+ *
+ * The `HXG Retry`_ message should be used by recipient to indicate that the
+ * `HXG Request`_ message was dropped and it should be resent again.
+ *
+ * The @REASON field may be used to provide additional information.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_RETRY_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **REASON** - reason for retry |
+ * | | | - _`GUC_HXG_RETRY_REASON_UNSPECIFIED` = 0 |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_RETRY_MSG_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_RETRY_MSG_0_REASON GUC_HXG_MSG_0_AUX
+#define GUC_HXG_RETRY_REASON_UNSPECIFIED 0u
+
+/**
+ * DOC: HXG Failure
+ *
+ * The `HXG Failure`_ message shall be used as a reply to the `HXG Request`_
+ * message that could not be processed due to an error.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_FAILURE_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | **HINT** - additional error hint |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | **ERROR** - error/result code |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_FAILURE_MSG_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_FAILURE_MSG_0_HINT (0xfff << 16)
+#define GUC_HXG_FAILURE_MSG_0_ERROR (0xffff << 0)
+
+/**
+ * DOC: HXG Response
+ *
+ * The `HXG Response`_ message shall be used as a reply to the `HXG Request`_
+ * message that was successfully processed without an error.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **DATA0** - data (depends on ACTION from `HXG Request`_) |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **DATAn** - data (depends on ACTION from `HXG Request`_) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_RESPONSE_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_RESPONSE_MSG_0_DATA0 GUC_HXG_MSG_0_AUX
+#define GUC_HXG_RESPONSE_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
+
+/* deprecated */
#define INTEL_GUC_MSG_TYPE_SHIFT 28
#define INTEL_GUC_MSG_TYPE_MASK (0xF << INTEL_GUC_MSG_TYPE_SHIFT)
#define INTEL_GUC_MSG_DATA_SHIFT 16
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
New GuC firmware will unify format of MMIO and CTB H2G messages.
Introduce their definitions now to allow gradual transition of
our code to match new changes.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
---
.../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++++++++++++++++++
1 file changed, 213 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
index 775e21f3058c..29ac823acd4c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
@@ -6,6 +6,219 @@
#ifndef _ABI_GUC_MESSAGES_ABI_H
#define _ABI_GUC_MESSAGES_ABI_H
+/**
+ * DOC: HXG Message
+ *
+ * All messages exchanged with GuC are defined using 32 bit dwords.
+ * First dword is treated as a message header. Remaining dwords are optional.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | | | |
+ * | 0 | 31 | **ORIGIN** - originator of the message |
+ * | | | - _`GUC_HXG_ORIGIN_HOST` = 0 |
+ * | | | - _`GUC_HXG_ORIGIN_GUC` = 1 |
+ * | | | |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | **TYPE** - message type |
+ * | | | - _`GUC_HXG_TYPE_REQUEST` = 0 |
+ * | | | - _`GUC_HXG_TYPE_EVENT` = 1 |
+ * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 |
+ * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5 |
+ * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 |
+ * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **AUX** - auxiliary data (depends on TYPE) |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **PAYLOAD** - optional payload (depends on TYPE) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_MSG_MIN_LEN 1u
+#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
+#define GUC_HXG_ORIGIN_HOST 0u
+#define GUC_HXG_ORIGIN_GUC 1u
+#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
+#define GUC_HXG_TYPE_REQUEST 0u
+#define GUC_HXG_TYPE_EVENT 1u
+#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
+#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u
+#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
+#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
+#define GUC_HXG_MSG_0_AUX (0xfffffff << 0)
+#define GUC_HXG_MSG_n_PAYLOAD (0xffffffff << 0)
+
+/**
+ * DOC: HXG Request
+ *
+ * The `HXG Request`_ message should be used to initiate synchronous activity
+ * for which confirmation or return data is expected.
+ *
+ * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
+ * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
+ * message as a intermediate reply.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | **DATA0** - request data (depends on ACTION) |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | **ACTION** - requested action code |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **DATAn** - optional data (depends on ACTION) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_REQUEST_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_REQUEST_MSG_0_DATA0 (0xfff << 16)
+#define GUC_HXG_REQUEST_MSG_0_ACTION (0xffff << 0)
+#define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
+
+/**
+ * DOC: HXG Event
+ *
+ * The `HXG Event`_ message should be used to initiate asynchronous activity
+ * that does not involves immediate confirmation nor data.
+ *
+ * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_EVENT_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | **DATA0** - event data (depends on ACTION) |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | **ACTION** - event action code |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **DATAn** - optional event data (depends on ACTION) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_EVENT_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_EVENT_MSG_0_DATA0 (0xfff << 16)
+#define GUC_HXG_EVENT_MSG_0_ACTION (0xffff << 0)
+#define GUC_HXG_EVENT_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
+
+/**
+ * DOC: HXG Busy
+ *
+ * The `HXG Busy`_ message may be used to acknowledge reception of the `HXG Request`_
+ * message if the recipient expects that it processing will be longer than default
+ * timeout.
+ *
+ * The @COUNTER field may be used as a progress indicator.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_BUSY_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **COUNTER** - progress indicator |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_BUSY_MSG_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_BUSY_MSG_0_COUNTER GUC_HXG_MSG_0_AUX
+
+/**
+ * DOC: HXG Retry
+ *
+ * The `HXG Retry`_ message should be used by recipient to indicate that the
+ * `HXG Request`_ message was dropped and it should be resent again.
+ *
+ * The @REASON field may be used to provide additional information.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_RETRY_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **REASON** - reason for retry |
+ * | | | - _`GUC_HXG_RETRY_REASON_UNSPECIFIED` = 0 |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_RETRY_MSG_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_RETRY_MSG_0_REASON GUC_HXG_MSG_0_AUX
+#define GUC_HXG_RETRY_REASON_UNSPECIFIED 0u
+
+/**
+ * DOC: HXG Failure
+ *
+ * The `HXG Failure`_ message shall be used as a reply to the `HXG Request`_
+ * message that could not be processed due to an error.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_FAILURE_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | **HINT** - additional error hint |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | **ERROR** - error/result code |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_FAILURE_MSG_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_FAILURE_MSG_0_HINT (0xfff << 16)
+#define GUC_HXG_FAILURE_MSG_0_ERROR (0xffff << 0)
+
+/**
+ * DOC: HXG Response
+ *
+ * The `HXG Response`_ message shall be used as a reply to the `HXG Request`_
+ * message that was successfully processed without an error.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | **DATA0** - data (depends on ACTION from `HXG Request`_) |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | |
+ * +---+-------+ |
+ * |...| | **DATAn** - data (depends on ACTION from `HXG Request`_) |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_HXG_RESPONSE_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
+#define GUC_HXG_RESPONSE_MSG_0_DATA0 GUC_HXG_MSG_0_AUX
+#define GUC_HXG_RESPONSE_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
+
+/* deprecated */
#define INTEL_GUC_MSG_TYPE_SHIFT 28
#define INTEL_GUC_MSG_TYPE_MASK (0xF << INTEL_GUC_MSG_TYPE_SHIFT)
#define INTEL_GUC_MSG_DATA_SHIFT 16
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 02/13] drm/i915/guc: Update MMIO based communication
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.
Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.
GuC: 55.0.0
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
---
.../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++++++-------
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
2 files changed, 97 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index be066a62e9e0..3f9039e3ef9d 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -7,46 +7,43 @@
#define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
/**
- * DOC: MMIO based communication
+ * DOC: GuC MMIO based communication
*
- * The MMIO based communication between Host and GuC uses software scratch
- * registers, where first register holds data treated as message header,
- * and other registers are used to hold message payload.
+ * The MMIO based communication between Host and GuC relies on special
+ * hardware registers which format could be defined by the software
+ * (so called scratch registers).
*
- * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
- * but no H2G command takes more than 8 parameters and the GuC FW
- * itself uses an 8-element array to store the H2G message.
- *
- * +-----------+---------+---------+---------+
- * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
- * +-----------+---------+---------+---------+
- * | header | optional payload |
- * +======+====+=========+=========+=========+
- * | 31:28|type| | | |
- * +------+----+ | | |
- * | 27:16|data| | | |
- * +------+----+ | | |
- * | 15:0|code| | | |
- * +------+----+---------+---------+---------+
- *
- * The message header consists of:
- *
- * - **type**, indicates message type
- * - **code**, indicates message code, is specific for **type**
- * - **data**, indicates message data, optional, depends on **code**
+ * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
+ * messages, which maximum length depends on number of available scratch
+ * registers, is directly written into those scratch registers.
*
- * The following message **types** are supported:
+ * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
+ * but no H2G command takes more than 8 parameters and the GuC firmware
+ * itself uses an 8-element array to store the H2G message.
*
- * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
- * must be priovided in **code** field. Optional action specific parameters
- * can be provided in remaining payload registers or **data** field.
+ * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
+ * are, regardless on lower count, preffered over legacy ones.
*
- * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
- * action response status will be provided in **code** field. Optional
- * response data can be returned in remaining payload registers or **data**
- * field.
+ * The MMIO based communication is mainly used during driver initialization
+ * phase to setup the `CTB based communication`_ that will be used afterwards.
*/
#define GUC_MAX_MMIO_MSG_LEN 8
+/**
+ * DOC: MMIO HXG Message
+ *
+ * Format of the MMIO messages follows definitions of `HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+ | | |
+ * |...| | | Embedded `HXG Message`_ | |
+ * +---+-------+ | | |
+ * | n | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
#endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index f147cb389a20..b773567cb080 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
/*
* This function implements the MMIO based host to GuC interface.
*/
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
{
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
- u32 status;
+ u32 header;
int i;
int ret;
GEM_BUG_ON(!len);
GEM_BUG_ON(len > guc->send_regs.count);
- /* We expect only action code */
- GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
-
- /* If CT is available, we expect to use MMIO only during init/fini */
- GEM_BUG_ON(*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
- *action != INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) != GUC_HXG_ORIGIN_HOST);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) != GUC_HXG_TYPE_REQUEST);
mutex_lock(&guc->send_mutex);
intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
+retry:
for (i = 0; i < len; i++)
- intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
+ intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
@@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
*/
ret = __intel_wait_for_register_fw(uncore,
guc_send_reg(guc, 0),
- INTEL_GUC_MSG_TYPE_MASK,
- INTEL_GUC_MSG_TYPE_RESPONSE <<
- INTEL_GUC_MSG_TYPE_SHIFT,
- 10, 10, &status);
- /* If GuC explicitly returned an error, convert it to -EIO */
- if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
- ret = -EIO;
+ GUC_HXG_MSG_0_ORIGIN,
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
+ GUC_HXG_ORIGIN_GUC),
+ 10, 10, &header);
+ if (unlikely(ret)) {
+timeout:
+ drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
+ request[0], header);
+ goto out;
+ }
- if (ret) {
- DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
- action[0], ret, status);
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
+#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc, 0)); \
+ FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC || \
+ FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
+
+ ret = wait_for(done, 1000);
+ if (unlikely(ret))
+ goto timeout;
+ if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
+ GUC_HXG_ORIGIN_GUC))
+ goto proto;
+#undef done
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
+ u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
+
+ drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
+ request[0], reason);
+ goto retry;
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_RESPONSE_FAILURE) {
+ u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
+ u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
+
+ drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
+ request[0], error, hint);
+ ret = -ENXIO;
+ goto out;
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
+proto:
+ drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
+ request[0], header);
+ ret = -EPROTO;
goto out;
}
if (response_buf) {
- int count = min(response_buf_size, guc->send_regs.count - 1);
+ int count = min(response_buf_size, guc->send_regs.count);
- for (i = 0; i < count; i++)
+ GEM_BUG_ON(!count);
+
+ response_buf[0] = header;
+
+ for (i = 1; i < count; i++)
response_buf[i] = intel_uncore_read(uncore,
- guc_send_reg(guc, i + 1));
- }
+ guc_send_reg(guc, i));
- /* Use data from the GuC response as our return value */
- ret = INTEL_GUC_MSG_TO_DATA(status);
+ /* Use number of copied dwords as our return value */
+ ret = count;
+ } else {
+ /* Use data from the GuC response as our return value */
+ ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
+ }
out:
intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.
Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.
GuC: 55.0.0
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
---
.../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++++++-------
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
2 files changed, 97 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index be066a62e9e0..3f9039e3ef9d 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -7,46 +7,43 @@
#define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
/**
- * DOC: MMIO based communication
+ * DOC: GuC MMIO based communication
*
- * The MMIO based communication between Host and GuC uses software scratch
- * registers, where first register holds data treated as message header,
- * and other registers are used to hold message payload.
+ * The MMIO based communication between Host and GuC relies on special
+ * hardware registers which format could be defined by the software
+ * (so called scratch registers).
*
- * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
- * but no H2G command takes more than 8 parameters and the GuC FW
- * itself uses an 8-element array to store the H2G message.
- *
- * +-----------+---------+---------+---------+
- * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
- * +-----------+---------+---------+---------+
- * | header | optional payload |
- * +======+====+=========+=========+=========+
- * | 31:28|type| | | |
- * +------+----+ | | |
- * | 27:16|data| | | |
- * +------+----+ | | |
- * | 15:0|code| | | |
- * +------+----+---------+---------+---------+
- *
- * The message header consists of:
- *
- * - **type**, indicates message type
- * - **code**, indicates message code, is specific for **type**
- * - **data**, indicates message data, optional, depends on **code**
+ * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
+ * messages, which maximum length depends on number of available scratch
+ * registers, is directly written into those scratch registers.
*
- * The following message **types** are supported:
+ * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
+ * but no H2G command takes more than 8 parameters and the GuC firmware
+ * itself uses an 8-element array to store the H2G message.
*
- * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
- * must be priovided in **code** field. Optional action specific parameters
- * can be provided in remaining payload registers or **data** field.
+ * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
+ * are, regardless on lower count, preffered over legacy ones.
*
- * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
- * action response status will be provided in **code** field. Optional
- * response data can be returned in remaining payload registers or **data**
- * field.
+ * The MMIO based communication is mainly used during driver initialization
+ * phase to setup the `CTB based communication`_ that will be used afterwards.
*/
#define GUC_MAX_MMIO_MSG_LEN 8
+/**
+ * DOC: MMIO HXG Message
+ *
+ * Format of the MMIO messages follows definitions of `HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+ | | |
+ * |...| | | Embedded `HXG Message`_ | |
+ * +---+-------+ | | |
+ * | n | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
#endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index f147cb389a20..b773567cb080 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
/*
* This function implements the MMIO based host to GuC interface.
*/
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
{
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
- u32 status;
+ u32 header;
int i;
int ret;
GEM_BUG_ON(!len);
GEM_BUG_ON(len > guc->send_regs.count);
- /* We expect only action code */
- GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
-
- /* If CT is available, we expect to use MMIO only during init/fini */
- GEM_BUG_ON(*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
- *action != INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) != GUC_HXG_ORIGIN_HOST);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) != GUC_HXG_TYPE_REQUEST);
mutex_lock(&guc->send_mutex);
intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
+retry:
for (i = 0; i < len; i++)
- intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
+ intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
@@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
*/
ret = __intel_wait_for_register_fw(uncore,
guc_send_reg(guc, 0),
- INTEL_GUC_MSG_TYPE_MASK,
- INTEL_GUC_MSG_TYPE_RESPONSE <<
- INTEL_GUC_MSG_TYPE_SHIFT,
- 10, 10, &status);
- /* If GuC explicitly returned an error, convert it to -EIO */
- if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
- ret = -EIO;
+ GUC_HXG_MSG_0_ORIGIN,
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
+ GUC_HXG_ORIGIN_GUC),
+ 10, 10, &header);
+ if (unlikely(ret)) {
+timeout:
+ drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
+ request[0], header);
+ goto out;
+ }
- if (ret) {
- DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
- action[0], ret, status);
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
+#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc, 0)); \
+ FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC || \
+ FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
+
+ ret = wait_for(done, 1000);
+ if (unlikely(ret))
+ goto timeout;
+ if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
+ GUC_HXG_ORIGIN_GUC))
+ goto proto;
+#undef done
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
+ u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
+
+ drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
+ request[0], reason);
+ goto retry;
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_RESPONSE_FAILURE) {
+ u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
+ u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
+
+ drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
+ request[0], error, hint);
+ ret = -ENXIO;
+ goto out;
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
+proto:
+ drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
+ request[0], header);
+ ret = -EPROTO;
goto out;
}
if (response_buf) {
- int count = min(response_buf_size, guc->send_regs.count - 1);
+ int count = min(response_buf_size, guc->send_regs.count);
- for (i = 0; i < count; i++)
+ GEM_BUG_ON(!count);
+
+ response_buf[0] = header;
+
+ for (i = 1; i < count; i++)
response_buf[i] = intel_uncore_read(uncore,
- guc_send_reg(guc, i + 1));
- }
+ guc_send_reg(guc, i));
- /* Use data from the GuC response as our return value */
- ret = INTEL_GUC_MSG_TO_DATA(status);
+ /* Use number of copied dwords as our return value */
+ ret = count;
+ } else {
+ /* Use data from the GuC response as our return value */
+ ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
+ }
out:
intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 03/13] drm/i915/guc: Update CTB response status definition
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Format of the STATUS dword in CTB response message now follows
definition of the HXG header. Update our code and remove any
obsolete legacy definitions.
GuC: 55.0.0
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Acked-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 ++++++++------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -----------------
2 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 8f7b148fef58..3f7f48611487 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
* up to that length of time, then switch to a slower sleep-wait loop.
* No GuC command should ever take longer than 10ms.
*/
-#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+#define done \
+ (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+ GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, 10);
if (err)
err = wait_for(done, 10);
@@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
if (unlikely(err))
goto unlink;
- if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
err = -EIO;
goto unlink;
}
if (response_buf) {
/* There shall be no data in the status */
- WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
+ WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, request.status));
/* Return actual response len */
err = request.response_len;
} else {
/* There shall be no response payload */
WARN_ON(request.response_len);
/* Return data decoded from the status dword */
- err = INTEL_GUC_MSG_TO_DATA(*status);
+ err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
}
unlink:
@@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
status = response->msg[2];
datalen = len - 2;
- /* Format of the status follows RESPONSE message */
- if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+ /* Format of the status dword follows HXG header */
+ if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
return -EPROTO;
}
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 e9a9d85e2aa3..fb04e2211b79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
} __packed;
-#define __INTEL_GUC_MSG_GET(T, m) \
- (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
-#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
-#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
-#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
-
-#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
- (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
-#define INTEL_GUC_MSG_IS_REQUEST(m) __INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
-#define INTEL_GUC_MSG_IS_RESPONSE(m) __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
-
-#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
- (typecheck(u32, (m)) && \
- ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
- ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
- (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
-
/* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
enum intel_guc_recv_message {
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 03/13] drm/i915/guc: Update CTB response status definition
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Format of the STATUS dword in CTB response message now follows
definition of the HXG header. Update our code and remove any
obsolete legacy definitions.
GuC: 55.0.0
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Acked-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 ++++++++------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -----------------
2 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 8f7b148fef58..3f7f48611487 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
* up to that length of time, then switch to a slower sleep-wait loop.
* No GuC command should ever take longer than 10ms.
*/
-#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
+#define done \
+ (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
+ GUC_HXG_ORIGIN_GUC)
err = wait_for_us(done, 10);
if (err)
err = wait_for(done, 10);
@@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
if (unlikely(err))
goto unlink;
- if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
err = -EIO;
goto unlink;
}
if (response_buf) {
/* There shall be no data in the status */
- WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
+ WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, request.status));
/* Return actual response len */
err = request.response_len;
} else {
/* There shall be no response payload */
WARN_ON(request.response_len);
/* Return data decoded from the status dword */
- err = INTEL_GUC_MSG_TO_DATA(*status);
+ err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
}
unlink:
@@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
status = response->msg[2];
datalen = len - 2;
- /* Format of the status follows RESPONSE message */
- if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
+ /* Format of the status dword follows HXG header */
+ if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
return -EPROTO;
}
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 e9a9d85e2aa3..fb04e2211b79 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
} __packed;
-#define __INTEL_GUC_MSG_GET(T, m) \
- (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
-#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
-#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
-#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
-
-#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
- (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
-#define INTEL_GUC_MSG_IS_REQUEST(m) __INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
-#define INTEL_GUC_MSG_IS_RESPONSE(m) __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
-
-#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
- (typecheck(u32, (m)) && \
- ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
- ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
- (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
-
/* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
enum intel_guc_recv_message {
INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 04/13] drm/i915/guc: Support per context scheduling policies
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: John Harrison <John.C.Harrison@Intel.com>
GuC firmware v53.0.0 introduced per context scheduling policies. This
includes changes to some of the ADS structures which are required to
load the firmware even if not using GuC submission.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 26 +++--------------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 31 +++++----------------
2 files changed, 11 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 9abfbc6edbd6..4fcbe4b921f9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -59,30 +59,12 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
guc_ads_private_data_size(guc);
}
-static void guc_policy_init(struct guc_policy *policy)
-{
- policy->execution_quantum = POLICY_DEFAULT_EXECUTION_QUANTUM_US;
- policy->preemption_time = POLICY_DEFAULT_PREEMPTION_TIME_US;
- policy->fault_time = POLICY_DEFAULT_FAULT_TIME_US;
- policy->policy_flags = 0;
-}
-
static void guc_policies_init(struct guc_policies *policies)
{
- struct guc_policy *policy;
- u32 p, i;
-
- policies->dpc_promote_time = POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
- policies->max_num_work_items = POLICY_MAX_NUM_WI;
-
- for (p = 0; p < GUC_CLIENT_PRIORITY_NUM; p++) {
- for (i = 0; i < GUC_MAX_ENGINE_CLASSES; i++) {
- policy = &policies->policy[p][i];
-
- guc_policy_init(policy);
- }
- }
-
+ policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
+ policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
+ /* Disable automatic resets as not yet supported. */
+ policies->global_flags = GLOBAL_POLICY_DISABLE_ENGINE_RESET;
policies->is_valid = 1;
}
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 fb04e2211b79..251c3836bd2c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -247,32 +247,14 @@ struct guc_stage_desc {
/* Scheduling policy settings */
-/* Reset engine upon preempt failure */
-#define POLICY_RESET_ENGINE (1<<0)
-/* Preempt to idle on quantum expiry */
-#define POLICY_PREEMPT_TO_IDLE (1<<1)
-
-#define POLICY_MAX_NUM_WI 15
-#define POLICY_DEFAULT_DPC_PROMOTE_TIME_US 500000
-#define POLICY_DEFAULT_EXECUTION_QUANTUM_US 1000000
-#define POLICY_DEFAULT_PREEMPTION_TIME_US 500000
-#define POLICY_DEFAULT_FAULT_TIME_US 250000
-
-struct guc_policy {
- /* Time for one workload to execute. (in micro seconds) */
- u32 execution_quantum;
- /* Time to wait for a preemption request to completed before issuing a
- * reset. (in micro seconds). */
- u32 preemption_time;
- /* How much time to allow to run after the first fault is observed.
- * Then preempt afterwards. (in micro seconds) */
- u32 fault_time;
- u32 policy_flags;
- u32 reserved[8];
-} __packed;
+#define GLOBAL_POLICY_MAX_NUM_WI 15
+
+/* Don't reset an engine upon preemption failure */
+#define GLOBAL_POLICY_DISABLE_ENGINE_RESET BIT(0)
+
+#define GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US 500000
struct guc_policies {
- struct guc_policy policy[GUC_CLIENT_PRIORITY_NUM][GUC_MAX_ENGINE_CLASSES];
u32 submission_queue_depth[GUC_MAX_ENGINE_CLASSES];
/* In micro seconds. How much time to allow before DPC processing is
* called back via interrupt (to prevent DPC queue drain starving).
@@ -286,6 +268,7 @@ struct guc_policies {
* idle. */
u32 max_num_work_items;
+ u32 global_flags;
u32 reserved[4];
} __packed;
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 04/13] drm/i915/guc: Support per context scheduling policies
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: John Harrison <John.C.Harrison@Intel.com>
GuC firmware v53.0.0 introduced per context scheduling policies. This
includes changes to some of the ADS structures which are required to
load the firmware even if not using GuC submission.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 26 +++--------------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 31 +++++----------------
2 files changed, 11 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 9abfbc6edbd6..4fcbe4b921f9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -59,30 +59,12 @@ static u32 guc_ads_blob_size(struct intel_guc *guc)
guc_ads_private_data_size(guc);
}
-static void guc_policy_init(struct guc_policy *policy)
-{
- policy->execution_quantum = POLICY_DEFAULT_EXECUTION_QUANTUM_US;
- policy->preemption_time = POLICY_DEFAULT_PREEMPTION_TIME_US;
- policy->fault_time = POLICY_DEFAULT_FAULT_TIME_US;
- policy->policy_flags = 0;
-}
-
static void guc_policies_init(struct guc_policies *policies)
{
- struct guc_policy *policy;
- u32 p, i;
-
- policies->dpc_promote_time = POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
- policies->max_num_work_items = POLICY_MAX_NUM_WI;
-
- for (p = 0; p < GUC_CLIENT_PRIORITY_NUM; p++) {
- for (i = 0; i < GUC_MAX_ENGINE_CLASSES; i++) {
- policy = &policies->policy[p][i];
-
- guc_policy_init(policy);
- }
- }
-
+ policies->dpc_promote_time = GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US;
+ policies->max_num_work_items = GLOBAL_POLICY_MAX_NUM_WI;
+ /* Disable automatic resets as not yet supported. */
+ policies->global_flags = GLOBAL_POLICY_DISABLE_ENGINE_RESET;
policies->is_valid = 1;
}
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 fb04e2211b79..251c3836bd2c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -247,32 +247,14 @@ struct guc_stage_desc {
/* Scheduling policy settings */
-/* Reset engine upon preempt failure */
-#define POLICY_RESET_ENGINE (1<<0)
-/* Preempt to idle on quantum expiry */
-#define POLICY_PREEMPT_TO_IDLE (1<<1)
-
-#define POLICY_MAX_NUM_WI 15
-#define POLICY_DEFAULT_DPC_PROMOTE_TIME_US 500000
-#define POLICY_DEFAULT_EXECUTION_QUANTUM_US 1000000
-#define POLICY_DEFAULT_PREEMPTION_TIME_US 500000
-#define POLICY_DEFAULT_FAULT_TIME_US 250000
-
-struct guc_policy {
- /* Time for one workload to execute. (in micro seconds) */
- u32 execution_quantum;
- /* Time to wait for a preemption request to completed before issuing a
- * reset. (in micro seconds). */
- u32 preemption_time;
- /* How much time to allow to run after the first fault is observed.
- * Then preempt afterwards. (in micro seconds) */
- u32 fault_time;
- u32 policy_flags;
- u32 reserved[8];
-} __packed;
+#define GLOBAL_POLICY_MAX_NUM_WI 15
+
+/* Don't reset an engine upon preemption failure */
+#define GLOBAL_POLICY_DISABLE_ENGINE_RESET BIT(0)
+
+#define GLOBAL_POLICY_DEFAULT_DPC_PROMOTE_TIME_US 500000
struct guc_policies {
- struct guc_policy policy[GUC_CLIENT_PRIORITY_NUM][GUC_MAX_ENGINE_CLASSES];
u32 submission_queue_depth[GUC_MAX_ENGINE_CLASSES];
/* In micro seconds. How much time to allow before DPC processing is
* called back via interrupt (to prevent DPC queue drain starving).
@@ -286,6 +268,7 @@ struct guc_policies {
* idle. */
u32 max_num_work_items;
+ u32 global_flags;
u32 reserved[4];
} __packed;
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 05/13] drm/i915/guc: Add flag for mark broken CTB
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Once CTB descriptor is found in error state, either set by GuC
or us, there is no need continue checking descriptor any more,
we can rely on our internal flag.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++++++++++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3f7f48611487..63056ea0631e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -123,6 +123,7 @@ static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
{
+ ctb->broken = false;
guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
}
@@ -387,9 +388,12 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
- if (unlikely(desc->is_in_error))
+ if (unlikely(ctb->broken))
return -EPIPE;
+ if (unlikely(desc->is_in_error))
+ goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
(tail | head) >= size))
goto corrupted;
@@ -451,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct,
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+ ctb->broken = true;
return -EPIPE;
}
@@ -632,9 +637,12 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
unsigned int i;
u32 header;
- if (unlikely(desc->is_in_error))
+ if (unlikely(ctb->broken))
return -EPIPE;
+ if (unlikely(desc->is_in_error))
+ goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
(tail | head) >= size))
goto corrupted;
@@ -698,6 +706,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+ ctb->broken = true;
return -EPIPE;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index cb222f202301..7d3cd375d6a7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -32,12 +32,14 @@ struct intel_guc;
* @desc: pointer to the buffer descriptor
* @cmds: pointer to the commands buffer
* @size: size of the commands buffer
+ * @broken: flag to indicate if descriptor data is broken
*/
struct intel_guc_ct_buffer {
spinlock_t lock;
struct guc_ct_buffer_desc *desc;
u32 *cmds;
u32 size;
+ bool broken;
};
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 05/13] drm/i915/guc: Add flag for mark broken CTB
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Once CTB descriptor is found in error state, either set by GuC
or us, there is no need continue checking descriptor any more,
we can rely on our internal flag.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 13 +++++++++++--
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3f7f48611487..63056ea0631e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -123,6 +123,7 @@ static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
{
+ ctb->broken = false;
guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
}
@@ -387,9 +388,12 @@ static int ct_write(struct intel_guc_ct *ct,
u32 *cmds = ctb->cmds;
unsigned int i;
- if (unlikely(desc->is_in_error))
+ if (unlikely(ctb->broken))
return -EPIPE;
+ if (unlikely(desc->is_in_error))
+ goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
(tail | head) >= size))
goto corrupted;
@@ -451,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct,
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+ ctb->broken = true;
return -EPIPE;
}
@@ -632,9 +637,12 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
unsigned int i;
u32 header;
- if (unlikely(desc->is_in_error))
+ if (unlikely(ctb->broken))
return -EPIPE;
+ if (unlikely(desc->is_in_error))
+ goto corrupted;
+
if (unlikely(!IS_ALIGNED(head | tail, 4) ||
(tail | head) >= size))
goto corrupted;
@@ -698,6 +706,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
desc->addr, desc->head, desc->tail, desc->size);
desc->is_in_error = 1;
+ ctb->broken = true;
return -EPIPE;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index cb222f202301..7d3cd375d6a7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -32,12 +32,14 @@ struct intel_guc;
* @desc: pointer to the buffer descriptor
* @cmds: pointer to the commands buffer
* @size: size of the commands buffer
+ * @broken: flag to indicate if descriptor data is broken
*/
struct intel_guc_ct_buffer {
spinlock_t lock;
struct guc_ct_buffer_desc *desc;
u32 *cmds;
u32 size;
+ bool broken;
};
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.
Both HEAD and TAIL are now in dwords.
Add some ABI documentation and implement required changes.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++++++++++++++-----
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +++++++++----------
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
3 files changed, 85 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index d38935f47ecf..c2a069a78e01 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -7,6 +7,58 @@
#define _ABI_GUC_COMMUNICATION_CTB_ABI_H
#include <linux/types.h>
+#include <linux/build_bug.h>
+
+#include "guc_messages_abi.h"
+
+/**
+ * DOC: CT Buffer
+ *
+ * TBD
+ */
+
+/**
+ * DOC: CTB Descriptor
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:0 | **HEAD** - offset (in dwords) to the last dword that was |
+ * | | | read from the `CT Buffer`_. |
+ * | | | It can only be updated by the receiver. |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | **TAIL** - offset (in dwords) to the last dword that was |
+ * | | | written to the `CT Buffer`_. |
+ * | | | It can only be updated by the sender. |
+ * +---+-------+--------------------------------------------------------------+
+ * | 2 | 31:0 | **STATUS** - status of the CTB |
+ * | | | |
+ * | | | - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation) |
+ * | | | - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) |
+ * | | | - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message) |
+ * | | | - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified) |
+ * | | | - _`GUC_CTB_STATUS_NO_BACKCHANNEL` = 8 |
+ * | | | - _`GUC_CTB_STATUS_MALFORMED_MSG` = 16 |
+ * +---+-------+--------------------------------------------------------------+
+ * |...| | RESERVED = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ * | 15| 31:0 | RESERVED = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+struct guc_ct_buffer_desc {
+ u32 head;
+ u32 tail;
+ u32 status;
+#define GUC_CTB_STATUS_NO_ERROR 0
+#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
+#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
+#define GUC_CTB_STATUS_MISMATCH (1 << 2)
+#define GUC_CTB_STATUS_NO_BACKCHANNEL (1 << 3)
+#define GUC_CTB_STATUS_MALFORMED_MSG (1 << 4)
+ u32 reserved[13];
+} __packed;
+static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
/**
* DOC: CTB based communication
@@ -60,24 +112,6 @@
* - **flags**, holds various bits to control message handling
*/
-/*
- * Describes single command transport buffer.
- * Used by both guc-master and clients.
- */
-struct guc_ct_buffer_desc {
- u32 addr; /* gfx address */
- u64 host_private; /* host private data */
- u32 size; /* size in bytes */
- u32 head; /* offset updated by GuC*/
- u32 tail; /* offset updated by owner */
- u32 is_in_error; /* error indicator */
- u32 reserved1;
- u32 reserved2;
- u32 owner; /* id of the channel owner */
- u32 owner_sub_id; /* owner-defined field for extra tracking */
- u32 reserved[5];
-} __packed;
-
/* Type of command transport buffer */
#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 63056ea0631e..3241a477196f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -112,32 +112,28 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
}
}
-static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
- u32 cmds_addr, u32 size)
+static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
{
memset(desc, 0, sizeof(*desc));
- desc->addr = cmds_addr;
- desc->size = size;
- desc->owner = CTB_OWNER_HOST;
}
-static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
+static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
{
ctb->broken = false;
- guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
+ guc_ct_buffer_desc_init(ctb->desc);
}
static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
struct guc_ct_buffer_desc *desc,
- u32 *cmds, u32 size)
+ u32 *cmds, u32 size_in_bytes)
{
- GEM_BUG_ON(size % 4);
+ GEM_BUG_ON(size_in_bytes % 4);
ctb->desc = desc;
ctb->cmds = cmds;
- ctb->size = size;
+ ctb->size = size_in_bytes / 4;
- guc_ct_buffer_reset(ctb, 0);
+ guc_ct_buffer_reset(ctb);
}
static int guc_action_register_ct_buffer(struct intel_guc *guc,
@@ -279,10 +275,10 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* (re)initialize descriptors */
cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
- guc_ct_buffer_reset(&ct->ctbs.send, cmds);
+ guc_ct_buffer_reset(&ct->ctbs.send);
cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
- guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
+ guc_ct_buffer_reset(&ct->ctbs.recv);
/*
* Register both CT buffers starting with RECV buffer.
@@ -391,17 +387,15 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(ctb->broken))
return -EPIPE;
- if (unlikely(desc->is_in_error))
+ if (unlikely(desc->status))
goto corrupted;
- if (unlikely(!IS_ALIGNED(head | tail, 4) ||
- (tail | head) >= size))
+ if (unlikely((tail | head) >= size)) {
+ CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
+ head, tail, size);
+ desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
-
- /* later calculations will be done in dwords */
- head /= 4;
- tail /= 4;
- size /= 4;
+ }
/*
* tail == head condition indicates empty. GuC FW does not support
@@ -447,14 +441,14 @@ static int ct_write(struct intel_guc_ct *ct,
*/
write_barrier(ct);
- /* now update desc tail (back in bytes) */
- desc->tail = tail * 4;
+ /* now update descriptor */
+ WRITE_ONCE(desc->tail, tail);
+
return 0;
corrupted:
- CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
- desc->addr, desc->head, desc->tail, desc->size);
- desc->is_in_error = 1;
+ CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
+ desc->head, desc->tail, desc->status);
ctb->broken = true;
return -EPIPE;
}
@@ -640,17 +634,15 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
if (unlikely(ctb->broken))
return -EPIPE;
- if (unlikely(desc->is_in_error))
+ if (unlikely(desc->status))
goto corrupted;
- if (unlikely(!IS_ALIGNED(head | tail, 4) ||
- (tail | head) >= size))
+ if (unlikely((tail | head) >= size)) {
+ CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
+ head, tail, size);
+ desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
-
- /* later calculations will be done in dwords */
- head /= 4;
- tail /= 4;
- size /= 4;
+ }
/* tail == head condition indicates empty */
available = tail - head;
@@ -677,6 +669,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
size - head : available - 1), &cmds[head],
4 * (head + available - 1 > size ?
available - 1 - size + head : 0), &cmds[0]);
+ desc->status |= GUC_CTB_STATUS_UNDERFLOW;
goto corrupted;
}
@@ -699,13 +692,14 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
}
CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
- desc->head = head * 4;
+ /* now update descriptor */
+ WRITE_ONCE(desc->head, head);
+
return available - len;
corrupted:
- CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
- desc->addr, desc->head, desc->tail, desc->size);
- desc->is_in_error = 1;
+ CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
+ desc->head, desc->tail, desc->status);
ctb->broken = true;
return -EPIPE;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 7d3cd375d6a7..905202caaad3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -31,7 +31,7 @@ struct intel_guc;
* @lock: protects access to the commands buffer and buffer descriptor
* @desc: pointer to the buffer descriptor
* @cmds: pointer to the commands buffer
- * @size: size of the commands buffer
+ * @size: size of the commands buffer in dwords
* @broken: flag to indicate if descriptor data is broken
*/
struct intel_guc_ct_buffer {
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Definition of the CTB descriptor has changed, leaving only
minimal shared fields like HEAD/TAIL/STATUS.
Both HEAD and TAIL are now in dwords.
Add some ABI documentation and implement required changes.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++++++++++++++-----
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +++++++++----------
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
3 files changed, 85 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index d38935f47ecf..c2a069a78e01 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -7,6 +7,58 @@
#define _ABI_GUC_COMMUNICATION_CTB_ABI_H
#include <linux/types.h>
+#include <linux/build_bug.h>
+
+#include "guc_messages_abi.h"
+
+/**
+ * DOC: CT Buffer
+ *
+ * TBD
+ */
+
+/**
+ * DOC: CTB Descriptor
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:0 | **HEAD** - offset (in dwords) to the last dword that was |
+ * | | | read from the `CT Buffer`_. |
+ * | | | It can only be updated by the receiver. |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | **TAIL** - offset (in dwords) to the last dword that was |
+ * | | | written to the `CT Buffer`_. |
+ * | | | It can only be updated by the sender. |
+ * +---+-------+--------------------------------------------------------------+
+ * | 2 | 31:0 | **STATUS** - status of the CTB |
+ * | | | |
+ * | | | - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation) |
+ * | | | - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) |
+ * | | | - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message) |
+ * | | | - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified) |
+ * | | | - _`GUC_CTB_STATUS_NO_BACKCHANNEL` = 8 |
+ * | | | - _`GUC_CTB_STATUS_MALFORMED_MSG` = 16 |
+ * +---+-------+--------------------------------------------------------------+
+ * |...| | RESERVED = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ * | 15| 31:0 | RESERVED = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+struct guc_ct_buffer_desc {
+ u32 head;
+ u32 tail;
+ u32 status;
+#define GUC_CTB_STATUS_NO_ERROR 0
+#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
+#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
+#define GUC_CTB_STATUS_MISMATCH (1 << 2)
+#define GUC_CTB_STATUS_NO_BACKCHANNEL (1 << 3)
+#define GUC_CTB_STATUS_MALFORMED_MSG (1 << 4)
+ u32 reserved[13];
+} __packed;
+static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
/**
* DOC: CTB based communication
@@ -60,24 +112,6 @@
* - **flags**, holds various bits to control message handling
*/
-/*
- * Describes single command transport buffer.
- * Used by both guc-master and clients.
- */
-struct guc_ct_buffer_desc {
- u32 addr; /* gfx address */
- u64 host_private; /* host private data */
- u32 size; /* size in bytes */
- u32 head; /* offset updated by GuC*/
- u32 tail; /* offset updated by owner */
- u32 is_in_error; /* error indicator */
- u32 reserved1;
- u32 reserved2;
- u32 owner; /* id of the channel owner */
- u32 owner_sub_id; /* owner-defined field for extra tracking */
- u32 reserved[5];
-} __packed;
-
/* Type of command transport buffer */
#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 63056ea0631e..3241a477196f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -112,32 +112,28 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
}
}
-static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
- u32 cmds_addr, u32 size)
+static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
{
memset(desc, 0, sizeof(*desc));
- desc->addr = cmds_addr;
- desc->size = size;
- desc->owner = CTB_OWNER_HOST;
}
-static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
+static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
{
ctb->broken = false;
- guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
+ guc_ct_buffer_desc_init(ctb->desc);
}
static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
struct guc_ct_buffer_desc *desc,
- u32 *cmds, u32 size)
+ u32 *cmds, u32 size_in_bytes)
{
- GEM_BUG_ON(size % 4);
+ GEM_BUG_ON(size_in_bytes % 4);
ctb->desc = desc;
ctb->cmds = cmds;
- ctb->size = size;
+ ctb->size = size_in_bytes / 4;
- guc_ct_buffer_reset(ctb, 0);
+ guc_ct_buffer_reset(ctb);
}
static int guc_action_register_ct_buffer(struct intel_guc *guc,
@@ -279,10 +275,10 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* (re)initialize descriptors */
cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
- guc_ct_buffer_reset(&ct->ctbs.send, cmds);
+ guc_ct_buffer_reset(&ct->ctbs.send);
cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
- guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
+ guc_ct_buffer_reset(&ct->ctbs.recv);
/*
* Register both CT buffers starting with RECV buffer.
@@ -391,17 +387,15 @@ static int ct_write(struct intel_guc_ct *ct,
if (unlikely(ctb->broken))
return -EPIPE;
- if (unlikely(desc->is_in_error))
+ if (unlikely(desc->status))
goto corrupted;
- if (unlikely(!IS_ALIGNED(head | tail, 4) ||
- (tail | head) >= size))
+ if (unlikely((tail | head) >= size)) {
+ CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
+ head, tail, size);
+ desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
-
- /* later calculations will be done in dwords */
- head /= 4;
- tail /= 4;
- size /= 4;
+ }
/*
* tail == head condition indicates empty. GuC FW does not support
@@ -447,14 +441,14 @@ static int ct_write(struct intel_guc_ct *ct,
*/
write_barrier(ct);
- /* now update desc tail (back in bytes) */
- desc->tail = tail * 4;
+ /* now update descriptor */
+ WRITE_ONCE(desc->tail, tail);
+
return 0;
corrupted:
- CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
- desc->addr, desc->head, desc->tail, desc->size);
- desc->is_in_error = 1;
+ CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
+ desc->head, desc->tail, desc->status);
ctb->broken = true;
return -EPIPE;
}
@@ -640,17 +634,15 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
if (unlikely(ctb->broken))
return -EPIPE;
- if (unlikely(desc->is_in_error))
+ if (unlikely(desc->status))
goto corrupted;
- if (unlikely(!IS_ALIGNED(head | tail, 4) ||
- (tail | head) >= size))
+ if (unlikely((tail | head) >= size)) {
+ CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
+ head, tail, size);
+ desc->status |= GUC_CTB_STATUS_OVERFLOW;
goto corrupted;
-
- /* later calculations will be done in dwords */
- head /= 4;
- tail /= 4;
- size /= 4;
+ }
/* tail == head condition indicates empty */
available = tail - head;
@@ -677,6 +669,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
size - head : available - 1), &cmds[head],
4 * (head + available - 1 > size ?
available - 1 - size + head : 0), &cmds[0]);
+ desc->status |= GUC_CTB_STATUS_UNDERFLOW;
goto corrupted;
}
@@ -699,13 +692,14 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
}
CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
- desc->head = head * 4;
+ /* now update descriptor */
+ WRITE_ONCE(desc->head, head);
+
return available - len;
corrupted:
- CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
- desc->addr, desc->head, desc->tail, desc->size);
- desc->is_in_error = 1;
+ CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
+ desc->head, desc->tail, desc->status);
ctb->broken = true;
return -EPIPE;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 7d3cd375d6a7..905202caaad3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -31,7 +31,7 @@ struct intel_guc;
* @lock: protects access to the commands buffer and buffer descriptor
* @desc: pointer to the buffer descriptor
* @cmds: pointer to the commands buffer
- * @size: size of the commands buffer
+ * @size: size of the commands buffer in dwords
* @broken: flag to indicate if descriptor data is broken
*/
struct intel_guc_ct_buffer {
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
.../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
3 files changed, 152 insertions(+), 35 deletions(-)
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 90efef8a73e4..6426fc183692 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
@@ -6,6 +6,113 @@
#ifndef _ABI_GUC_ACTIONS_ABI_H
#define _ABI_GUC_ACTIONS_ABI_H
+/**
+ * DOC: HOST2GUC_REGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ setup.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | DATA0 = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 0x5200 |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:12 | RESERVED = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | **TYPE** - type for the `CT Buffer`_ |
+ * | | | |
+ * | | | - _`GUC_CTB_TYPE_HOST2GUC` = 0 |
+ * | | | - _`GUC_CTB_TYPE_GUC2HOST` = 1 |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1 |
+ * +---+-------+--------------------------------------------------------------+
+ * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_ |
+ * +---+-------+--------------------------------------------------------------+
+ * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ |
+ * +---+-------+--------------------------------------------------------------+
+*
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | DATA0 = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
+
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
+#define GUC_CTB_TYPE_HOST2GUC 0u
+#define GUC_CTB_TYPE_GUC2HOST 1u
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
+
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
+
+/**
+ * DOC: HOST2GUC_DEREGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ teardown.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | DATA0 = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` = 0x5201 |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:12 | RESERVED = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | **TYPE** - type of the `CT Buffer`_ |
+ * | | | |
+ * | | | see `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | RESERVED = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+*
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | DATA0 = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME 0x5201
+
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
+
+#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
+
+/* legacy definitions */
+
enum intel_guc_action {
INTEL_GUC_ACTION_DEFAULT = 0x0,
INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index c2a069a78e01..127b256a662c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
* - **flags**, holds various bits to control message handling
*/
-/* Type of command transport buffer */
-#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
-#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
-
/*
* Definition of the command transport message header (DW0)
*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3241a477196f..6a29be779cc9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
static inline const char *guc_ct_buffer_type_to_str(u32 type)
{
switch (type) {
- case INTEL_GUC_CT_BUFFER_TYPE_SEND:
+ case GUC_CTB_TYPE_HOST2GUC:
return "SEND";
- case INTEL_GUC_CT_BUFFER_TYPE_RECV:
+ case GUC_CTB_TYPE_GUC2HOST:
return "RECV";
default:
return "<invalid>";
@@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
guc_ct_buffer_reset(ctb);
}
-static int guc_action_register_ct_buffer(struct intel_guc *guc,
- u32 desc_addr,
- u32 type)
+static int guc_action_register_ct_buffer(struct intel_guc *guc, u32 type,
+ u32 desc_addr, u32 buff_addr, u32 size)
{
- u32 action[] = {
- INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
- desc_addr,
- sizeof(struct guc_ct_buffer_desc),
- type
+ u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
+ FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
+ FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_REGISTER_CTB),
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K - 1) |
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
};
- /* Can't use generic send(), CT registration must go over MMIO */
- return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
+ GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
+ GEM_BUG_ON(size % SZ_4K);
+
+ /* CT registration must go over MMIO */
+ return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
}
-static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
+static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
+ u32 desc_addr, u32 buff_addr, u32 size)
{
- int err = guc_action_register_ct_buffer(ct_to_guc(ct), desc_addr, type);
+ int err;
+ err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
+ desc_addr, buff_addr, size);
if (unlikely(err))
CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
guc_ct_buffer_type_to_str(type), err);
@@ -163,14 +171,17 @@ static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
static int guc_action_deregister_ct_buffer(struct intel_guc *guc, u32 type)
{
- u32 action[] = {
- INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
- CTB_OWNER_HOST,
- type
+ u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
+ FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
+ FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
+ FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
};
- /* Can't use generic send(), CT deregistration must go over MMIO */
- return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
+ GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
+
+ /* CT deregistration must go over MMIO */
+ return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
}
static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
@@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
int intel_guc_ct_enable(struct intel_guc_ct *ct)
{
struct intel_guc *guc = ct_to_guc(ct);
- u32 base, cmds;
+ u32 base, desc, cmds;
void *blob;
int err;
@@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
GEM_BUG_ON(blob != ct->ctbs.send.desc);
/* (re)initialize descriptors */
- cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
guc_ct_buffer_reset(&ct->ctbs.send);
-
- cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
guc_ct_buffer_reset(&ct->ctbs.recv);
/*
* Register both CT buffers starting with RECV buffer.
* Descriptors are in first half of the blob.
*/
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
- INTEL_GUC_CT_BUFFER_TYPE_RECV);
+ desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
+ cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
+ err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
+ desc, cmds, ct->ctbs.recv.size * 4);
+
if (unlikely(err))
goto err_out;
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
- INTEL_GUC_CT_BUFFER_TYPE_SEND);
+ desc = base + ptrdiff(ct->ctbs.send.desc, blob);
+ cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
+ err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
+ desc, cmds, ct->ctbs.send.size * 4);
+
if (unlikely(err))
goto err_deregister;
@@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
return 0;
err_deregister:
- ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
+ ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
err_out:
CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
return err;
@@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
ct->enabled = false;
if (intel_guc_is_fw_running(guc)) {
- ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
- ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
+ ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
+ ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
}
}
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Definition of the CTB registration action has changed.
Add some ABI documentation and implement required changes.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
.../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
3 files changed, 152 insertions(+), 35 deletions(-)
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 90efef8a73e4..6426fc183692 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
@@ -6,6 +6,113 @@
#ifndef _ABI_GUC_ACTIONS_ABI_H
#define _ABI_GUC_ACTIONS_ABI_H
+/**
+ * DOC: HOST2GUC_REGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ setup.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | DATA0 = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 0x5200 |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:12 | RESERVED = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | **TYPE** - type for the `CT Buffer`_ |
+ * | | | |
+ * | | | - _`GUC_CTB_TYPE_HOST2GUC` = 0 |
+ * | | | - _`GUC_CTB_TYPE_GUC2HOST` = 1 |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1 |
+ * +---+-------+--------------------------------------------------------------+
+ * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_ |
+ * +---+-------+--------------------------------------------------------------+
+ * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ |
+ * +---+-------+--------------------------------------------------------------+
+*
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | DATA0 = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
+
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
+#define GUC_CTB_TYPE_HOST2GUC 0u
+#define GUC_CTB_TYPE_GUC2HOST 1u
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
+
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
+
+/**
+ * DOC: HOST2GUC_DEREGISTER_CTB
+ *
+ * This message is used as part of the `CTB based communication`_ teardown.
+ *
+ * This message must be sent as `MMIO HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:16 | DATA0 = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` = 0x5201 |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:12 | RESERVED = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | **TYPE** - type of the `CT Buffer`_ |
+ * | | | |
+ * | | | see `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | RESERVED = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+*
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 27:0 | DATA0 = MBZ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME 0x5201
+
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
+#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
+
+#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
+#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
+
+/* legacy definitions */
+
enum intel_guc_action {
INTEL_GUC_ACTION_DEFAULT = 0x0,
INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index c2a069a78e01..127b256a662c 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
* - **flags**, holds various bits to control message handling
*/
-/* Type of command transport buffer */
-#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
-#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
-
/*
* Definition of the command transport message header (DW0)
*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 3241a477196f..6a29be779cc9 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
static inline const char *guc_ct_buffer_type_to_str(u32 type)
{
switch (type) {
- case INTEL_GUC_CT_BUFFER_TYPE_SEND:
+ case GUC_CTB_TYPE_HOST2GUC:
return "SEND";
- case INTEL_GUC_CT_BUFFER_TYPE_RECV:
+ case GUC_CTB_TYPE_GUC2HOST:
return "RECV";
default:
return "<invalid>";
@@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
guc_ct_buffer_reset(ctb);
}
-static int guc_action_register_ct_buffer(struct intel_guc *guc,
- u32 desc_addr,
- u32 type)
+static int guc_action_register_ct_buffer(struct intel_guc *guc, u32 type,
+ u32 desc_addr, u32 buff_addr, u32 size)
{
- u32 action[] = {
- INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
- desc_addr,
- sizeof(struct guc_ct_buffer_desc),
- type
+ u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
+ FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
+ FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_REGISTER_CTB),
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K - 1) |
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
+ FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
};
- /* Can't use generic send(), CT registration must go over MMIO */
- return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
+ GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
+ GEM_BUG_ON(size % SZ_4K);
+
+ /* CT registration must go over MMIO */
+ return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
}
-static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
+static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
+ u32 desc_addr, u32 buff_addr, u32 size)
{
- int err = guc_action_register_ct_buffer(ct_to_guc(ct), desc_addr, type);
+ int err;
+ err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
+ desc_addr, buff_addr, size);
if (unlikely(err))
CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
guc_ct_buffer_type_to_str(type), err);
@@ -163,14 +171,17 @@ static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
static int guc_action_deregister_ct_buffer(struct intel_guc *guc, u32 type)
{
- u32 action[] = {
- INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
- CTB_OWNER_HOST,
- type
+ u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
+ FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
+ FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
+ FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
};
- /* Can't use generic send(), CT deregistration must go over MMIO */
- return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
+ GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
+
+ /* CT deregistration must go over MMIO */
+ return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
}
static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
@@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
int intel_guc_ct_enable(struct intel_guc_ct *ct)
{
struct intel_guc *guc = ct_to_guc(ct);
- u32 base, cmds;
+ u32 base, desc, cmds;
void *blob;
int err;
@@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
GEM_BUG_ON(blob != ct->ctbs.send.desc);
/* (re)initialize descriptors */
- cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
guc_ct_buffer_reset(&ct->ctbs.send);
-
- cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
guc_ct_buffer_reset(&ct->ctbs.recv);
/*
* Register both CT buffers starting with RECV buffer.
* Descriptors are in first half of the blob.
*/
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
- INTEL_GUC_CT_BUFFER_TYPE_RECV);
+ desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
+ cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
+ err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
+ desc, cmds, ct->ctbs.recv.size * 4);
+
if (unlikely(err))
goto err_out;
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
- INTEL_GUC_CT_BUFFER_TYPE_SEND);
+ desc = base + ptrdiff(ct->ctbs.send.desc, blob);
+ cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
+ err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
+ desc, cmds, ct->ctbs.send.size * 4);
+
if (unlikely(err))
goto err_deregister;
@@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
return 0;
err_deregister:
- ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
+ ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
err_out:
CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
return err;
@@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
ct->enabled = false;
if (intel_guc_is_fw_running(guc)) {
- ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
- ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
+ ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
+ ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
}
}
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 08/13] drm/i915/guc: New CTB based communication
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Format of the CTB messages has changed:
- support for multiple formats
- message fence is now part of the header
- reuse of unified HXG message formats
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 56 +++++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++++++-----------
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
3 files changed, 135 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index 127b256a662c..92660726c094 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
} __packed;
static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
+/**
+ * DOC: CTB Message
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:16 | **FENCE** - message identifier |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:12 | **FORMAT** - format of the CTB message |
+ * | | | - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | **RESERVED** |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | **NUM_DWORDS** - length of the CTB message (w/o header) |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | optional (depends on FORMAT) |
+ * +---+-------+ |
+ * |...| | |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_CTB_MSG_MIN_LEN 1u
+#define GUC_CTB_MSG_MAX_LEN 256u
+#define GUC_CTB_MSG_0_FENCE (0xffff << 16)
+#define GUC_CTB_MSG_0_FORMAT (0xf << 12)
+#define GUC_CTB_FORMAT_HXG 0u
+#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
+#define GUC_CTB_MSG_0_NUM_DWORDS (0xff << 0)
+
+/**
+ * DOC: CTB HXG Message
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:16 | FENCE |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | RESERVED = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+ | | |
+ * |...| | | Embedded `HXG Message`_ | |
+ * +---+-------+ | | |
+ * | n | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_CTB_HXG_MSG_MIN_LEN (GUC_CTB_MSG_MIN_LEN + GUC_HXG_MSG_MIN_LEN)
+#define GUC_CTB_HXG_MSG_MAX_LEN GUC_CTB_MSG_MAX_LEN
+
/**
* DOC: CTB based communication
*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 6a29be779cc9..729f29bc2a57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
}
}
-/**
- * DOC: CTB Host to GuC request
- *
- * Format of the CTB Host to GuC request message is as follows::
- *
- * +------------+---------+---------+---------+---------+
- * | msg[0] | [1] | [2] | ... | [n-1] |
- * +------------+---------+---------+---------+---------+
- * | MESSAGE | MESSAGE PAYLOAD |
- * + HEADER +---------+---------+---------+---------+
- * | | 0 | 1 | ... | n |
- * +============+=========+=========+=========+=========+
- * | len >= 1 | FENCE | request specific data |
- * +------+-----+---------+---------+---------+---------+
- *
- * ^-----------------len-------------------^
- */
-
static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
@@ -395,6 +377,7 @@ static int ct_write(struct intel_guc_ct *ct,
u32 size = ctb->size;
u32 used;
u32 header;
+ u32 hxg;
u32 *cmds = ctb->cmds;
unsigned int i;
@@ -425,22 +408,24 @@ static int ct_write(struct intel_guc_ct *ct,
return -ENOSPC;
/*
- * Write the message. The format is the following:
- * DW0: header (including action code)
- * DW1: fence
- * DW2+: action data
+ * dw0: CT header (including fence)
+ * dw1: HXG header
*/
- header = (len << GUC_CT_MSG_LEN_SHIFT) |
- GUC_CT_MSG_SEND_STATUS |
- (action[0] << GUC_CT_MSG_ACTION_SHIFT);
+ header = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
+ FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
+ FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
+
+ hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
+ FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
+ GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
- CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
- 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
+ CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
+ tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
cmds[tail] = header;
tail = (tail + 1) % size;
- cmds[tail] = fence;
+ cmds[tail] = hxg;
tail = (tail + 1) % size;
for (i = 1; i < len; i++) {
@@ -598,21 +583,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
return ret;
}
-static inline unsigned int ct_header_get_len(u32 header)
-{
- return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
-}
-
-static inline unsigned int ct_header_get_action(u32 header)
-{
- return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
-}
-
-static inline bool ct_header_is_response(u32 header)
-{
- return !!(header & GUC_CT_MSG_IS_RESPONSE);
-}
-
static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
{
struct ct_incoming_msg *msg;
@@ -675,7 +645,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
head = (head + 1) % size;
/* message len with header */
- len = ct_header_get_len(header) + 1;
+ len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, header) + GUC_CTB_MSG_MIN_LEN;
if (unlikely(len > (u32)available)) {
CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
4, &header,
@@ -718,55 +688,24 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
return -EPIPE;
}
-/**
- * DOC: CTB GuC to Host response
- *
- * Format of the CTB GuC to Host response message is as follows::
- *
- * +------------+---------+---------+---------+---------+---------+
- * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
- * +------------+---------+---------+---------+---------+---------+
- * | MESSAGE | MESSAGE PAYLOAD |
- * + HEADER +---------+---------+---------+---------+---------+
- * | | 0 | 1 | 2 | ... | n |
- * +============+=========+=========+=========+=========+=========+
- * | len >= 2 | FENCE | STATUS | response specific data |
- * +------+-----+---------+---------+---------+---------+---------+
- *
- * ^-----------------------len-----------------------^
- */
-
static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *response)
{
- u32 header = response->msg[0];
- u32 len = ct_header_get_len(header);
- u32 fence;
- u32 status;
- u32 datalen;
+ u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
+ u32 fence = FIELD_GET(GUC_CTB_MSG_0_FENCE, response->msg[0]);
+ const u32 *hxg = &response->msg[GUC_CTB_MSG_MIN_LEN];
+ const u32 *data = &hxg[GUC_HXG_MSG_MIN_LEN];
+ u32 datalen = len - GUC_HXG_MSG_MIN_LEN;
struct ct_request *req;
unsigned long flags;
bool found = false;
int err = 0;
- GEM_BUG_ON(!ct_header_is_response(header));
+ GEM_BUG_ON(len < GUC_HXG_MSG_MIN_LEN);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]) != GUC_HXG_ORIGIN_GUC);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_SUCCESS &&
+ FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_FAILURE);
- /* Response payload shall at least include fence and status */
- if (unlikely(len < 2)) {
- CT_ERROR(ct, "Corrupted response (len %u)\n", len);
- return -EPROTO;
- }
-
- fence = response->msg[1];
- status = response->msg[2];
- datalen = len - 2;
-
- /* Format of the status dword follows HXG header */
- if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
- CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
- return -EPROTO;
- }
-
- CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
+ CT_DEBUG(ct, "response fence %u status %#x\n", fence, hxg[0]);
spin_lock_irqsave(&ct->requests.lock, flags);
list_for_each_entry(req, &ct->requests.pending, link) {
@@ -782,9 +721,9 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
err = -EMSGSIZE;
}
if (datalen)
- memcpy(req->response_buf, response->msg + 3, 4 * datalen);
+ memcpy(req->response_buf, data, 4 * datalen);
req->response_len = datalen;
- WRITE_ONCE(req->status, status);
+ WRITE_ONCE(req->status, hxg[0]);
found = true;
break;
}
@@ -805,14 +744,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
static int ct_process_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
{
struct intel_guc *guc = ct_to_guc(ct);
- u32 header, action, len;
+ const u32 *hxg;
const u32 *payload;
+ u32 hxg_len, action, len;
int ret;
- header = request->msg[0];
- payload = &request->msg[1];
- action = ct_header_get_action(header);
- len = ct_header_get_len(header);
+ hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
+ hxg_len = request->size - GUC_CTB_MSG_MIN_LEN;
+ payload = &hxg[GUC_HXG_MSG_MIN_LEN];
+ action = FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION, hxg[0]);
+ len = hxg_len - GUC_HXG_MSG_MIN_LEN;
CT_DEBUG(ct, "request %x %*ph\n", action, 4 * len, payload);
@@ -874,29 +815,12 @@ static void ct_incoming_request_worker_func(struct work_struct *w)
queue_work(system_unbound_wq, &ct->requests.worker);
}
-/**
- * DOC: CTB GuC to Host request
- *
- * Format of the CTB GuC to Host request message is as follows::
- *
- * +------------+---------+---------+---------+---------+---------+
- * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
- * +------------+---------+---------+---------+---------+---------+
- * | MESSAGE | MESSAGE PAYLOAD |
- * + HEADER +---------+---------+---------+---------+---------+
- * | | 0 | 1 | 2 | ... | n |
- * +============+=========+=========+=========+=========+=========+
- * | len | request specific data |
- * +------+-----+---------+---------+---------+---------+---------+
- *
- * ^-----------------------len-----------------------^
- */
-
-static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
+static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
{
+ const u32 *hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
unsigned long flags;
- GEM_BUG_ON(ct_header_is_response(request->msg[0]));
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_EVENT);
spin_lock_irqsave(&ct->requests.lock, flags);
list_add_tail(&request->link, &ct->requests.incoming);
@@ -906,15 +830,53 @@ static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *re
return 0;
}
-static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
+static int ct_handle_hxg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
{
- u32 header = msg->msg[0];
+ u32 origin, type;
+ u32 *hxg;
int err;
- if (ct_header_is_response(header))
+ if (unlikely(msg->size < GUC_CTB_HXG_MSG_MIN_LEN))
+ return -EBADMSG;
+
+ hxg = &msg->msg[GUC_CTB_MSG_MIN_LEN];
+
+ origin = FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]);
+ if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
+ err = -EPROTO;
+ goto failed;
+ }
+
+ type = FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]);
+ switch (type) {
+ case GUC_HXG_TYPE_EVENT:
+ err = ct_handle_event(ct, msg);
+ break;
+ case GUC_HXG_TYPE_RESPONSE_SUCCESS:
+ case GUC_HXG_TYPE_RESPONSE_FAILURE:
err = ct_handle_response(ct, msg);
+ break;
+ default:
+ err = -EOPNOTSUPP;
+ }
+
+ if (unlikely(err)) {
+failed:
+ CT_ERROR(ct, "Failed to handle HXG message (%pe) %*ph\n",
+ ERR_PTR(err), 4 * GUC_HXG_MSG_MIN_LEN, hxg);
+ }
+ return err;
+}
+
+static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
+{
+ u32 format = FIELD_GET(GUC_CTB_MSG_0_FORMAT, msg->msg[0]);
+ int err;
+
+ if (format == GUC_CTB_FORMAT_HXG)
+ err = ct_handle_hxg(ct, msg);
else
- err = ct_handle_request(ct, msg);
+ err = -EOPNOTSUPP;
if (unlikely(err)) {
CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 905202caaad3..1ae2dde6db93 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -61,7 +61,7 @@ struct intel_guc_ct {
struct tasklet_struct receive_tasklet;
struct {
- u32 last_fence; /* last fence used to send request */
+ u16 last_fence; /* last fence used to send request */
spinlock_t lock; /* protects pending requests list */
struct list_head pending; /* requests waiting for response */
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 08/13] drm/i915/guc: New CTB based communication
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
Format of the CTB messages has changed:
- support for multiple formats
- message fence is now part of the header
- reuse of unified HXG message formats
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 56 +++++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++++++-----------
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
3 files changed, 135 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
index 127b256a662c..92660726c094 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
@@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
} __packed;
static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
+/**
+ * DOC: CTB Message
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:16 | **FENCE** - message identifier |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:12 | **FORMAT** - format of the CTB message |
+ * | | | - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | **RESERVED** |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | **NUM_DWORDS** - length of the CTB message (w/o header) |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | optional (depends on FORMAT) |
+ * +---+-------+ |
+ * |...| | |
+ * +---+-------+ |
+ * | n | 31:0 | |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_CTB_MSG_MIN_LEN 1u
+#define GUC_CTB_MSG_MAX_LEN 256u
+#define GUC_CTB_MSG_0_FENCE (0xffff << 16)
+#define GUC_CTB_MSG_0_FORMAT (0xf << 12)
+#define GUC_CTB_FORMAT_HXG 0u
+#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
+#define GUC_CTB_MSG_0_NUM_DWORDS (0xff << 0)
+
+/**
+ * DOC: CTB HXG Message
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:16 | FENCE |
+ * | +-------+--------------------------------------------------------------+
+ * | | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 11:8 | RESERVED = MBZ |
+ * | +-------+--------------------------------------------------------------+
+ * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message |
+ * +---+-------+--------------------------------------------------------------+
+ * | 1 | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+ | | |
+ * |...| | | Embedded `HXG Message`_ | |
+ * +---+-------+ | | |
+ * | n | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+--------------------------------------------------------------+
+ */
+
+#define GUC_CTB_HXG_MSG_MIN_LEN (GUC_CTB_MSG_MIN_LEN + GUC_HXG_MSG_MIN_LEN)
+#define GUC_CTB_HXG_MSG_MAX_LEN GUC_CTB_MSG_MAX_LEN
+
/**
* DOC: CTB based communication
*
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 6a29be779cc9..729f29bc2a57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
}
}
-/**
- * DOC: CTB Host to GuC request
- *
- * Format of the CTB Host to GuC request message is as follows::
- *
- * +------------+---------+---------+---------+---------+
- * | msg[0] | [1] | [2] | ... | [n-1] |
- * +------------+---------+---------+---------+---------+
- * | MESSAGE | MESSAGE PAYLOAD |
- * + HEADER +---------+---------+---------+---------+
- * | | 0 | 1 | ... | n |
- * +============+=========+=========+=========+=========+
- * | len >= 1 | FENCE | request specific data |
- * +------+-----+---------+---------+---------+---------+
- *
- * ^-----------------len-------------------^
- */
-
static int ct_write(struct intel_guc_ct *ct,
const u32 *action,
u32 len /* in dwords */,
@@ -395,6 +377,7 @@ static int ct_write(struct intel_guc_ct *ct,
u32 size = ctb->size;
u32 used;
u32 header;
+ u32 hxg;
u32 *cmds = ctb->cmds;
unsigned int i;
@@ -425,22 +408,24 @@ static int ct_write(struct intel_guc_ct *ct,
return -ENOSPC;
/*
- * Write the message. The format is the following:
- * DW0: header (including action code)
- * DW1: fence
- * DW2+: action data
+ * dw0: CT header (including fence)
+ * dw1: HXG header
*/
- header = (len << GUC_CT_MSG_LEN_SHIFT) |
- GUC_CT_MSG_SEND_STATUS |
- (action[0] << GUC_CT_MSG_ACTION_SHIFT);
+ header = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
+ FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
+ FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
+
+ hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
+ FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
+ GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
- CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
- 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
+ CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
+ tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
cmds[tail] = header;
tail = (tail + 1) % size;
- cmds[tail] = fence;
+ cmds[tail] = hxg;
tail = (tail + 1) % size;
for (i = 1; i < len; i++) {
@@ -598,21 +583,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
return ret;
}
-static inline unsigned int ct_header_get_len(u32 header)
-{
- return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
-}
-
-static inline unsigned int ct_header_get_action(u32 header)
-{
- return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
-}
-
-static inline bool ct_header_is_response(u32 header)
-{
- return !!(header & GUC_CT_MSG_IS_RESPONSE);
-}
-
static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
{
struct ct_incoming_msg *msg;
@@ -675,7 +645,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
head = (head + 1) % size;
/* message len with header */
- len = ct_header_get_len(header) + 1;
+ len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, header) + GUC_CTB_MSG_MIN_LEN;
if (unlikely(len > (u32)available)) {
CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
4, &header,
@@ -718,55 +688,24 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
return -EPIPE;
}
-/**
- * DOC: CTB GuC to Host response
- *
- * Format of the CTB GuC to Host response message is as follows::
- *
- * +------------+---------+---------+---------+---------+---------+
- * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
- * +------------+---------+---------+---------+---------+---------+
- * | MESSAGE | MESSAGE PAYLOAD |
- * + HEADER +---------+---------+---------+---------+---------+
- * | | 0 | 1 | 2 | ... | n |
- * +============+=========+=========+=========+=========+=========+
- * | len >= 2 | FENCE | STATUS | response specific data |
- * +------+-----+---------+---------+---------+---------+---------+
- *
- * ^-----------------------len-----------------------^
- */
-
static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *response)
{
- u32 header = response->msg[0];
- u32 len = ct_header_get_len(header);
- u32 fence;
- u32 status;
- u32 datalen;
+ u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
+ u32 fence = FIELD_GET(GUC_CTB_MSG_0_FENCE, response->msg[0]);
+ const u32 *hxg = &response->msg[GUC_CTB_MSG_MIN_LEN];
+ const u32 *data = &hxg[GUC_HXG_MSG_MIN_LEN];
+ u32 datalen = len - GUC_HXG_MSG_MIN_LEN;
struct ct_request *req;
unsigned long flags;
bool found = false;
int err = 0;
- GEM_BUG_ON(!ct_header_is_response(header));
+ GEM_BUG_ON(len < GUC_HXG_MSG_MIN_LEN);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]) != GUC_HXG_ORIGIN_GUC);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_SUCCESS &&
+ FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_FAILURE);
- /* Response payload shall at least include fence and status */
- if (unlikely(len < 2)) {
- CT_ERROR(ct, "Corrupted response (len %u)\n", len);
- return -EPROTO;
- }
-
- fence = response->msg[1];
- status = response->msg[2];
- datalen = len - 2;
-
- /* Format of the status dword follows HXG header */
- if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
- CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
- return -EPROTO;
- }
-
- CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
+ CT_DEBUG(ct, "response fence %u status %#x\n", fence, hxg[0]);
spin_lock_irqsave(&ct->requests.lock, flags);
list_for_each_entry(req, &ct->requests.pending, link) {
@@ -782,9 +721,9 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
err = -EMSGSIZE;
}
if (datalen)
- memcpy(req->response_buf, response->msg + 3, 4 * datalen);
+ memcpy(req->response_buf, data, 4 * datalen);
req->response_len = datalen;
- WRITE_ONCE(req->status, status);
+ WRITE_ONCE(req->status, hxg[0]);
found = true;
break;
}
@@ -805,14 +744,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
static int ct_process_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
{
struct intel_guc *guc = ct_to_guc(ct);
- u32 header, action, len;
+ const u32 *hxg;
const u32 *payload;
+ u32 hxg_len, action, len;
int ret;
- header = request->msg[0];
- payload = &request->msg[1];
- action = ct_header_get_action(header);
- len = ct_header_get_len(header);
+ hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
+ hxg_len = request->size - GUC_CTB_MSG_MIN_LEN;
+ payload = &hxg[GUC_HXG_MSG_MIN_LEN];
+ action = FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION, hxg[0]);
+ len = hxg_len - GUC_HXG_MSG_MIN_LEN;
CT_DEBUG(ct, "request %x %*ph\n", action, 4 * len, payload);
@@ -874,29 +815,12 @@ static void ct_incoming_request_worker_func(struct work_struct *w)
queue_work(system_unbound_wq, &ct->requests.worker);
}
-/**
- * DOC: CTB GuC to Host request
- *
- * Format of the CTB GuC to Host request message is as follows::
- *
- * +------------+---------+---------+---------+---------+---------+
- * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
- * +------------+---------+---------+---------+---------+---------+
- * | MESSAGE | MESSAGE PAYLOAD |
- * + HEADER +---------+---------+---------+---------+---------+
- * | | 0 | 1 | 2 | ... | n |
- * +============+=========+=========+=========+=========+=========+
- * | len | request specific data |
- * +------+-----+---------+---------+---------+---------+---------+
- *
- * ^-----------------------len-----------------------^
- */
-
-static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
+static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
{
+ const u32 *hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
unsigned long flags;
- GEM_BUG_ON(ct_header_is_response(request->msg[0]));
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_EVENT);
spin_lock_irqsave(&ct->requests.lock, flags);
list_add_tail(&request->link, &ct->requests.incoming);
@@ -906,15 +830,53 @@ static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *re
return 0;
}
-static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
+static int ct_handle_hxg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
{
- u32 header = msg->msg[0];
+ u32 origin, type;
+ u32 *hxg;
int err;
- if (ct_header_is_response(header))
+ if (unlikely(msg->size < GUC_CTB_HXG_MSG_MIN_LEN))
+ return -EBADMSG;
+
+ hxg = &msg->msg[GUC_CTB_MSG_MIN_LEN];
+
+ origin = FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]);
+ if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
+ err = -EPROTO;
+ goto failed;
+ }
+
+ type = FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]);
+ switch (type) {
+ case GUC_HXG_TYPE_EVENT:
+ err = ct_handle_event(ct, msg);
+ break;
+ case GUC_HXG_TYPE_RESPONSE_SUCCESS:
+ case GUC_HXG_TYPE_RESPONSE_FAILURE:
err = ct_handle_response(ct, msg);
+ break;
+ default:
+ err = -EOPNOTSUPP;
+ }
+
+ if (unlikely(err)) {
+failed:
+ CT_ERROR(ct, "Failed to handle HXG message (%pe) %*ph\n",
+ ERR_PTR(err), 4 * GUC_HXG_MSG_MIN_LEN, hxg);
+ }
+ return err;
+}
+
+static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
+{
+ u32 format = FIELD_GET(GUC_CTB_MSG_0_FORMAT, msg->msg[0]);
+ int err;
+
+ if (format == GUC_CTB_FORMAT_HXG)
+ err = ct_handle_hxg(ct, msg);
else
- err = ct_handle_request(ct, msg);
+ err = -EOPNOTSUPP;
if (unlikely(err)) {
CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 905202caaad3..1ae2dde6db93 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -61,7 +61,7 @@ struct intel_guc_ct {
struct tasklet_struct receive_tasklet;
struct {
- u32 last_fence; /* last fence used to send request */
+ u16 last_fence; /* last fence used to send request */
spinlock_t lock; /* protects pending requests list */
struct list_head pending; /* requests waiting for response */
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
GuC ABI documentation is now ready to be included in i915.rst
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
Documentation/gpu/i915.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..c7846b1d9293 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -518,6 +518,14 @@ GuC-based command submission
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
:doc: GuC-based command submission
+GuC ABI
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+
HuC
---
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
GuC ABI documentation is now ready to be included in i915.rst
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
Documentation/gpu/i915.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..c7846b1d9293 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -518,6 +518,14 @@ GuC-based command submission
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
:doc: GuC-based command submission
+GuC ABI
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
+.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+
HuC
---
.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
CTB pool is now maintained internally by the GuC as part of its
"private data". No need to allocate separate buffer and pass it
to GuC as yet another ADS.
Signed-off-by: Matthew Brost <matthew.brost@intel.com> #v4
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 12 ------------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +-----------
2 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 4fcbe4b921f9..6e26fe04ce92 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -26,8 +26,6 @@
* +---------------------------------------+
* | guc_clients_info |
* +---------------------------------------+
- * | guc_ct_pool_entry[size] |
- * +---------------------------------------+
* | padding |
* +---------------------------------------+ <== 4K aligned
* | private data |
@@ -40,7 +38,6 @@ struct __guc_ads_blob {
struct guc_policies policies;
struct guc_gt_system_info system_info;
struct guc_clients_info clients_info;
- struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
} __packed;
static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies *policies)
policies->is_valid = 1;
}
-static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
-{
- memset(pool, 0, num * sizeof(*pool));
-}
-
static void guc_mapping_table_init(struct intel_gt *gt,
struct guc_gt_system_info *system_info)
{
@@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
/* Clients info */
- guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
-
blob->clients_info.clients_num = 1;
- blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
- blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
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 251c3836bd2c..2266444d074f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -295,19 +295,9 @@ struct guc_gt_system_info {
} __packed;
/* Clients info */
-struct guc_ct_pool_entry {
- struct guc_ct_buffer_desc desc;
- u32 reserved[7];
-} __packed;
-
-#define GUC_CT_POOL_SIZE 2
-
struct guc_clients_info {
u32 clients_num;
- u32 reserved0[13];
- u32 ct_pool_addr;
- u32 ct_pool_count;
- u32 reserved[4];
+ u32 reserved[19];
} __packed;
/* GuC Additional Data Struct */
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
CTB pool is now maintained internally by the GuC as part of its
"private data". No need to allocate separate buffer and pass it
to GuC as yet another ADS.
Signed-off-by: Matthew Brost <matthew.brost@intel.com> #v4
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 12 ------------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 12 +-----------
2 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 4fcbe4b921f9..6e26fe04ce92 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -26,8 +26,6 @@
* +---------------------------------------+
* | guc_clients_info |
* +---------------------------------------+
- * | guc_ct_pool_entry[size] |
- * +---------------------------------------+
* | padding |
* +---------------------------------------+ <== 4K aligned
* | private data |
@@ -40,7 +38,6 @@ struct __guc_ads_blob {
struct guc_policies policies;
struct guc_gt_system_info system_info;
struct guc_clients_info clients_info;
- struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE];
} __packed;
static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -68,11 +65,6 @@ static void guc_policies_init(struct guc_policies *policies)
policies->is_valid = 1;
}
-static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num)
-{
- memset(pool, 0, num * sizeof(*pool));
-}
-
static void guc_mapping_table_init(struct intel_gt *gt,
struct guc_gt_system_info *system_info)
{
@@ -161,11 +153,7 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
/* Clients info */
- guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool));
-
blob->clients_info.clients_num = 1;
- blob->clients_info.ct_pool_addr = base + ptr_offset(blob, ct_pool);
- blob->clients_info.ct_pool_count = ARRAY_SIZE(blob->ct_pool);
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
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 251c3836bd2c..2266444d074f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -295,19 +295,9 @@ struct guc_gt_system_info {
} __packed;
/* Clients info */
-struct guc_ct_pool_entry {
- struct guc_ct_buffer_desc desc;
- u32 reserved[7];
-} __packed;
-
-#define GUC_CT_POOL_SIZE 2
-
struct guc_clients_info {
u32 clients_num;
- u32 reserved0[13];
- u32 ct_pool_addr;
- u32 ct_pool_count;
- u32 reserved[4];
+ u32 reserved[19];
} __packed;
/* GuC Additional Data Struct */
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 11/13] drm/i915/guc: Kill ads.client_info
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
New GuC does not require it any more.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 -------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +-------
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 6e26fe04ce92..b82145652d57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -24,8 +24,6 @@
* +---------------------------------------+
* | guc_gt_system_info |
* +---------------------------------------+
- * | guc_clients_info |
- * +---------------------------------------+
* | padding |
* +---------------------------------------+ <== 4K aligned
* | private data |
@@ -37,7 +35,6 @@ struct __guc_ads_blob {
struct guc_ads ads;
struct guc_policies policies;
struct guc_gt_system_info system_info;
- struct guc_clients_info clients_info;
} __packed;
static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -152,13 +149,9 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
- /* Clients info */
- blob->clients_info.clients_num = 1;
-
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
- blob->ads.clients_info = base + ptr_offset(blob, clients_info);
/* Private Data */
blob->ads.private_data = base + guc_ads_private_data_offset(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 2266444d074f..f2df5c11c11d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -294,19 +294,13 @@ struct guc_gt_system_info {
u32 generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_MAX];
} __packed;
-/* Clients info */
-struct guc_clients_info {
- u32 clients_num;
- u32 reserved[19];
-} __packed;
-
/* GuC Additional Data Struct */
struct guc_ads {
struct guc_mmio_reg_set reg_state_list[GUC_MAX_ENGINE_CLASSES][GUC_MAX_INSTANCES_PER_CLASS];
u32 reserved0;
u32 scheduler_policies;
u32 gt_system_info;
- u32 clients_info;
+ u32 reserved1;
u32 control_data;
u32 golden_context_lrca[GUC_MAX_ENGINE_CLASSES];
u32 eng_state_size[GUC_MAX_ENGINE_CLASSES];
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 11/13] drm/i915/guc: Kill ads.client_info
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
New GuC does not require it any more.
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 7 -------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +-------
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 6e26fe04ce92..b82145652d57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -24,8 +24,6 @@
* +---------------------------------------+
* | guc_gt_system_info |
* +---------------------------------------+
- * | guc_clients_info |
- * +---------------------------------------+
* | padding |
* +---------------------------------------+ <== 4K aligned
* | private data |
@@ -37,7 +35,6 @@ struct __guc_ads_blob {
struct guc_ads ads;
struct guc_policies policies;
struct guc_gt_system_info system_info;
- struct guc_clients_info clients_info;
} __packed;
static u32 guc_ads_private_data_size(struct intel_guc *guc)
@@ -152,13 +149,9 @@ static void __guc_ads_init(struct intel_guc *guc)
base = intel_guc_ggtt_offset(guc, guc->ads_vma);
- /* Clients info */
- blob->clients_info.clients_num = 1;
-
/* ADS */
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
blob->ads.gt_system_info = base + ptr_offset(blob, system_info);
- blob->ads.clients_info = base + ptr_offset(blob, clients_info);
/* Private Data */
blob->ads.private_data = base + guc_ads_private_data_offset(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 2266444d074f..f2df5c11c11d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -294,19 +294,13 @@ struct guc_gt_system_info {
u32 generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_MAX];
} __packed;
-/* Clients info */
-struct guc_clients_info {
- u32 clients_num;
- u32 reserved[19];
-} __packed;
-
/* GuC Additional Data Struct */
struct guc_ads {
struct guc_mmio_reg_set reg_state_list[GUC_MAX_ENGINE_CLASSES][GUC_MAX_INSTANCES_PER_CLASS];
u32 reserved0;
u32 scheduler_policies;
u32 gt_system_info;
- u32 clients_info;
+ u32 reserved1;
u32 control_data;
u32 golden_context_lrca[GUC_MAX_ENGINE_CLASSES];
u32 eng_state_size[GUC_MAX_ENGINE_CLASSES];
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 12/13] drm/i915/guc: Unified GuC log
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: John Harrison <John.C.Harrison@Intel.com>
GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
the option for it to be larger.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 15 ++++-------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 9 +++----
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +++++++--------------
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 ++---
4 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index b773567cb080..6661dcb02239 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
- BUILD_BUG_ON(!DPC_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
- BUILD_BUG_ON(!ISR_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
+ BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
(GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
- BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
- (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
- BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
- (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
+ BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
+ (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
flags = GUC_LOG_VALID |
GUC_LOG_NOTIFY_ON_HALF_FULL |
FLAG |
((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
- ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
- ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
+ ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
(offset << GUC_LOG_BUF_ADDR_SHIFT);
#undef UNIT
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 f2df5c11c11d..617ec601648d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -81,10 +81,8 @@
#define GUC_LOG_ALLOC_IN_MEGABYTE (1 << 3)
#define GUC_LOG_CRASH_SHIFT 4
#define GUC_LOG_CRASH_MASK (0x3 << GUC_LOG_CRASH_SHIFT)
-#define GUC_LOG_DPC_SHIFT 6
-#define GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
-#define GUC_LOG_ISR_SHIFT 9
-#define GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
+#define GUC_LOG_DEBUG_SHIFT 6
+#define GUC_LOG_DEBUG_MASK (0xF << GUC_LOG_DEBUG_SHIFT)
#define GUC_LOG_BUF_ADDR_SHIFT 12
#define GUC_CTL_WA 1
@@ -311,8 +309,7 @@ struct guc_ads {
/* GuC logging structures */
enum guc_log_buffer_type {
- GUC_ISR_LOG_BUFFER,
- GUC_DPC_LOG_BUFFER,
+ GUC_DEBUG_LOG_BUFFER,
GUC_CRASH_DUMP_LOG_BUFFER,
GUC_MAX_LOG_BUFFER
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index c36d5eb5bbb9..ac0931f0374b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
{
switch (type) {
- case GUC_ISR_LOG_BUFFER:
- return ISR_BUFFER_SIZE;
- case GUC_DPC_LOG_BUFFER:
- return DPC_BUFFER_SIZE;
+ case GUC_DEBUG_LOG_BUFFER:
+ return DEBUG_BUFFER_SIZE;
case GUC_CRASH_DUMP_LOG_BUFFER:
return CRASH_BUFFER_SIZE;
default:
@@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log *log)
src_data += PAGE_SIZE;
dst_data += PAGE_SIZE;
- for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+ for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
/*
* Make a copy of the state structure, inside GuC log buffer
* (which is uncached mapped), on the stack to avoid reading
@@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
* +===============================+ 00B
* | Crash dump state header |
* +-------------------------------+ 32B
- * | DPC state header |
+ * | Debug state header |
* +-------------------------------+ 64B
- * | ISR state header |
- * +-------------------------------+ 96B
* | |
* +===============================+ PAGE_SIZE (4KB)
* | Crash Dump logs |
* +===============================+ + CRASH_SIZE
- * | DPC logs |
- * +===============================+ + DPC_SIZE
- * | ISR logs |
- * +===============================+ + ISR_SIZE
+ * | Debug logs |
+ * +===============================+ + DEBUG_SIZE
*/
- guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DPC_BUFFER_SIZE +
- ISR_BUFFER_SIZE;
+ guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE;
vma = intel_guc_allocate_vma(guc, guc_log_size);
if (IS_ERR(vma)) {
@@ -675,10 +668,8 @@ static const char *
stringify_guc_log_type(enum guc_log_buffer_type type)
{
switch (type) {
- case GUC_ISR_LOG_BUFFER:
- return "ISR";
- case GUC_DPC_LOG_BUFFER:
- return "DPC";
+ case GUC_DEBUG_LOG_BUFFER:
+ return "DEBUG";
case GUC_CRASH_DUMP_LOG_BUFFER:
return "CRASH";
default:
@@ -708,7 +699,7 @@ void intel_guc_log_info(struct intel_guc_log *log, struct drm_printer *p)
drm_printf(p, "\tRelay full count: %u\n", log->relay.full_count);
- for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+ for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
drm_printf(p, "\t%s:\tflush count %10u, overflow count %10u\n",
stringify_guc_log_type(type),
log->stats[type].flush,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index 11fccd0b2294..ac1ee1d5ce10 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -17,12 +17,10 @@ struct intel_guc;
#ifdef CONFIG_DRM_I915_DEBUG_GUC
#define CRASH_BUFFER_SIZE SZ_2M
-#define DPC_BUFFER_SIZE SZ_8M
-#define ISR_BUFFER_SIZE SZ_8M
+#define DEBUG_BUFFER_SIZE SZ_16M
#else
#define CRASH_BUFFER_SIZE SZ_8K
-#define DPC_BUFFER_SIZE SZ_32K
-#define ISR_BUFFER_SIZE SZ_32K
+#define DEBUG_BUFFER_SIZE SZ_64K
#endif
/*
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 12/13] drm/i915/guc: Unified GuC log
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: John Harrison <John.C.Harrison@Intel.com>
GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
the option for it to be larger.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 15 ++++-------
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 9 +++----
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +++++++--------------
drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 ++---
4 files changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index b773567cb080..6661dcb02239 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
- BUILD_BUG_ON(!DPC_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
- BUILD_BUG_ON(!ISR_BUFFER_SIZE);
- BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
+ BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
+ BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
(GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
- BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
- (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
- BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
- (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
+ BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
+ (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
flags = GUC_LOG_VALID |
GUC_LOG_NOTIFY_ON_HALF_FULL |
FLAG |
((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
- ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
- ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
+ ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
(offset << GUC_LOG_BUF_ADDR_SHIFT);
#undef UNIT
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 f2df5c11c11d..617ec601648d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -81,10 +81,8 @@
#define GUC_LOG_ALLOC_IN_MEGABYTE (1 << 3)
#define GUC_LOG_CRASH_SHIFT 4
#define GUC_LOG_CRASH_MASK (0x3 << GUC_LOG_CRASH_SHIFT)
-#define GUC_LOG_DPC_SHIFT 6
-#define GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
-#define GUC_LOG_ISR_SHIFT 9
-#define GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
+#define GUC_LOG_DEBUG_SHIFT 6
+#define GUC_LOG_DEBUG_MASK (0xF << GUC_LOG_DEBUG_SHIFT)
#define GUC_LOG_BUF_ADDR_SHIFT 12
#define GUC_CTL_WA 1
@@ -311,8 +309,7 @@ struct guc_ads {
/* GuC logging structures */
enum guc_log_buffer_type {
- GUC_ISR_LOG_BUFFER,
- GUC_DPC_LOG_BUFFER,
+ GUC_DEBUG_LOG_BUFFER,
GUC_CRASH_DUMP_LOG_BUFFER,
GUC_MAX_LOG_BUFFER
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index c36d5eb5bbb9..ac0931f0374b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
{
switch (type) {
- case GUC_ISR_LOG_BUFFER:
- return ISR_BUFFER_SIZE;
- case GUC_DPC_LOG_BUFFER:
- return DPC_BUFFER_SIZE;
+ case GUC_DEBUG_LOG_BUFFER:
+ return DEBUG_BUFFER_SIZE;
case GUC_CRASH_DUMP_LOG_BUFFER:
return CRASH_BUFFER_SIZE;
default:
@@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log *log)
src_data += PAGE_SIZE;
dst_data += PAGE_SIZE;
- for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+ for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
/*
* Make a copy of the state structure, inside GuC log buffer
* (which is uncached mapped), on the stack to avoid reading
@@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
* +===============================+ 00B
* | Crash dump state header |
* +-------------------------------+ 32B
- * | DPC state header |
+ * | Debug state header |
* +-------------------------------+ 64B
- * | ISR state header |
- * +-------------------------------+ 96B
* | |
* +===============================+ PAGE_SIZE (4KB)
* | Crash Dump logs |
* +===============================+ + CRASH_SIZE
- * | DPC logs |
- * +===============================+ + DPC_SIZE
- * | ISR logs |
- * +===============================+ + ISR_SIZE
+ * | Debug logs |
+ * +===============================+ + DEBUG_SIZE
*/
- guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DPC_BUFFER_SIZE +
- ISR_BUFFER_SIZE;
+ guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE;
vma = intel_guc_allocate_vma(guc, guc_log_size);
if (IS_ERR(vma)) {
@@ -675,10 +668,8 @@ static const char *
stringify_guc_log_type(enum guc_log_buffer_type type)
{
switch (type) {
- case GUC_ISR_LOG_BUFFER:
- return "ISR";
- case GUC_DPC_LOG_BUFFER:
- return "DPC";
+ case GUC_DEBUG_LOG_BUFFER:
+ return "DEBUG";
case GUC_CRASH_DUMP_LOG_BUFFER:
return "CRASH";
default:
@@ -708,7 +699,7 @@ void intel_guc_log_info(struct intel_guc_log *log, struct drm_printer *p)
drm_printf(p, "\tRelay full count: %u\n", log->relay.full_count);
- for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+ for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
drm_printf(p, "\t%s:\tflush count %10u, overflow count %10u\n",
stringify_guc_log_type(type),
log->stats[type].flush,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
index 11fccd0b2294..ac1ee1d5ce10 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
@@ -17,12 +17,10 @@ struct intel_guc;
#ifdef CONFIG_DRM_I915_DEBUG_GUC
#define CRASH_BUFFER_SIZE SZ_2M
-#define DPC_BUFFER_SIZE SZ_8M
-#define ISR_BUFFER_SIZE SZ_8M
+#define DEBUG_BUFFER_SIZE SZ_16M
#else
#define CRASH_BUFFER_SIZE SZ_8K
-#define DPC_BUFFER_SIZE SZ_32K
-#define ISR_BUFFER_SIZE SZ_32K
+#define DEBUG_BUFFER_SIZE SZ_64K
#endif
/*
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:03 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 ++++++++++++------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index df647c9a8d56..9f23e9de3237 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
* firmware as TGL.
*/
#define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
- fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
- fw_def(ROCKETLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
- fw_def(TIGERLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
- fw_def(JASPERLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
- fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
- fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl, 9, 0, 0)) \
- fw_def(COMETLAKE, 5, guc_def(cml, 49, 0, 1), huc_def(cml, 4, 0, 0)) \
- fw_def(COMETLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
- fw_def(COFFEELAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
- fw_def(GEMINILAKE, 0, guc_def(glk, 49, 0, 1), huc_def(glk, 4, 0, 0)) \
- fw_def(KABYLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
- fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt, 2, 0, 0)) \
- fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl, 2, 0, 0))
+ fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
+ fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
+ fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
+ fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE, 5, guc_def(cml, 62, 0, 0), huc_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, guc_def(glk, 62, 0, 0), huc_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl, 2, 0, 0))
#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
"i915/" \
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0
@ 2021-06-07 18:03 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
From: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 ++++++++++++------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index df647c9a8d56..9f23e9de3237 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
* firmware as TGL.
*/
#define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
- fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
- fw_def(ROCKETLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
- fw_def(TIGERLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
- fw_def(JASPERLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
- fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
- fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl, 9, 0, 0)) \
- fw_def(COMETLAKE, 5, guc_def(cml, 49, 0, 1), huc_def(cml, 4, 0, 0)) \
- fw_def(COMETLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
- fw_def(COFFEELAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
- fw_def(GEMINILAKE, 0, guc_def(glk, 49, 0, 1), huc_def(glk, 4, 0, 0)) \
- fw_def(KABYLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
- fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt, 2, 0, 0)) \
- fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl, 2, 0, 0))
+ fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
+ fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
+ fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
+ fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
+ fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
+ fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl, 9, 0, 0)) \
+ fw_def(COMETLAKE, 5, guc_def(cml, 62, 0, 0), huc_def(cml, 4, 0, 0)) \
+ fw_def(COMETLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
+ fw_def(COFFEELAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
+ fw_def(GEMINILAKE, 0, guc_def(glk, 62, 0, 0), huc_def(glk, 4, 0, 0)) \
+ fw_def(KABYLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
+ fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt, 2, 0, 0)) \
+ fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl, 2, 0, 0))
#define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
"i915/" \
--
2.28.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
` (13 preceding siblings ...)
(?)
@ 2021-06-07 18:05 ` Patchwork
-1 siblings, 0 replies; 87+ messages in thread
From: Patchwork @ 2021-06-07 18:05 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
== Series Details ==
Series: Update firmware to v62.0.0
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5735522498b2 drm/i915/guc: Introduce unified HXG messages
067ec8d0b970 drm/i915/guc: Update MMIO based communication
c3c36fc8703e drm/i915/guc: Update CTB response status definition
4239eebfa25e drm/i915/guc: Support per context scheduling policies
fed4d47fabb2 drm/i915/guc: Add flag for mark broken CTB
98f39fdfdab9 drm/i915/guc: New definition of the CTB descriptor
f8e5520d648c drm/i915/guc: New definition of the CTB registration action
-:55: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line
#55: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h:40:
+ * +---+-------+--------------------------------------------------------------+
+*
-:56: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line
#56: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h:41:
+*
+ * +---+-------+--------------------------------------------------------------+
-:75: CHECK:CAMELCASE: Avoid CamelCase: <GUC_HXG_REQUEST_MSG_n_DATAn>
#75: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h:60:
+#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
-:107: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line
#107: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h:92:
+ * +---+-------+--------------------------------------------------------------+
+*
-:108: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line
#108: FILE: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h:93:
+*
+ * +---+-------+--------------------------------------------------------------+
total: 0 errors, 4 warnings, 1 checks, 261 lines checked
fe305e722d41 drm/i915/guc: New CTB based communication
4143260c8c99 drm/i915/doc: Include GuC ABI documentation
65b657159e48 drm/i915/guc: Kill guc_clients.ct_pool
1fcb4faa9a92 drm/i915/guc: Kill ads.client_info
14d7602095b1 drm/i915/guc: Unified GuC log
1998c178877b drm/i915/guc: Update firmware to v62.0.0
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
total: 0 errors, 1 warnings, 0 checks, 32 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 12/13] drm/i915/guc: Unified GuC log
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 18:05 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:05 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
On Mon, Jun 07, 2021 at 11:03:54AM -0700, Matthew Brost wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
> the option for it to be larger.
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 15 ++++-------
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 9 +++----
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +++++++--------------
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 ++---
> 4 files changed, 20 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index b773567cb080..6661dcb02239 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
>
> BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
> - BUILD_BUG_ON(!DPC_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
> - BUILD_BUG_ON(!ISR_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
> + BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> + BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
>
> BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
> (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
> - BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
> - (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
> - BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
> - (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
> + BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
> + (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
>
> flags = GUC_LOG_VALID |
> GUC_LOG_NOTIFY_ON_HALF_FULL |
> FLAG |
> ((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
> - ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
> - ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
> + ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
> (offset << GUC_LOG_BUF_ADDR_SHIFT);
>
> #undef UNIT
> 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 f2df5c11c11d..617ec601648d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -81,10 +81,8 @@
> #define GUC_LOG_ALLOC_IN_MEGABYTE (1 << 3)
> #define GUC_LOG_CRASH_SHIFT 4
> #define GUC_LOG_CRASH_MASK (0x3 << GUC_LOG_CRASH_SHIFT)
> -#define GUC_LOG_DPC_SHIFT 6
> -#define GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
> -#define GUC_LOG_ISR_SHIFT 9
> -#define GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
> +#define GUC_LOG_DEBUG_SHIFT 6
> +#define GUC_LOG_DEBUG_MASK (0xF << GUC_LOG_DEBUG_SHIFT)
> #define GUC_LOG_BUF_ADDR_SHIFT 12
>
> #define GUC_CTL_WA 1
> @@ -311,8 +309,7 @@ struct guc_ads {
> /* GuC logging structures */
>
> enum guc_log_buffer_type {
> - GUC_ISR_LOG_BUFFER,
> - GUC_DPC_LOG_BUFFER,
> + GUC_DEBUG_LOG_BUFFER,
> GUC_CRASH_DUMP_LOG_BUFFER,
> GUC_MAX_LOG_BUFFER
> };
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index c36d5eb5bbb9..ac0931f0374b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
> static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
> {
> switch (type) {
> - case GUC_ISR_LOG_BUFFER:
> - return ISR_BUFFER_SIZE;
> - case GUC_DPC_LOG_BUFFER:
> - return DPC_BUFFER_SIZE;
> + case GUC_DEBUG_LOG_BUFFER:
> + return DEBUG_BUFFER_SIZE;
> case GUC_CRASH_DUMP_LOG_BUFFER:
> return CRASH_BUFFER_SIZE;
> default:
> @@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log *log)
> src_data += PAGE_SIZE;
> dst_data += PAGE_SIZE;
>
> - for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> + for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> /*
> * Make a copy of the state structure, inside GuC log buffer
> * (which is uncached mapped), on the stack to avoid reading
> @@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
> * +===============================+ 00B
> * | Crash dump state header |
> * +-------------------------------+ 32B
> - * | DPC state header |
> + * | Debug state header |
> * +-------------------------------+ 64B
> - * | ISR state header |
> - * +-------------------------------+ 96B
> * | |
> * +===============================+ PAGE_SIZE (4KB)
> * | Crash Dump logs |
> * +===============================+ + CRASH_SIZE
> - * | DPC logs |
> - * +===============================+ + DPC_SIZE
> - * | ISR logs |
> - * +===============================+ + ISR_SIZE
> + * | Debug logs |
> + * +===============================+ + DEBUG_SIZE
> */
> - guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DPC_BUFFER_SIZE +
> - ISR_BUFFER_SIZE;
> + guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE;
>
> vma = intel_guc_allocate_vma(guc, guc_log_size);
> if (IS_ERR(vma)) {
> @@ -675,10 +668,8 @@ static const char *
> stringify_guc_log_type(enum guc_log_buffer_type type)
> {
> switch (type) {
> - case GUC_ISR_LOG_BUFFER:
> - return "ISR";
> - case GUC_DPC_LOG_BUFFER:
> - return "DPC";
> + case GUC_DEBUG_LOG_BUFFER:
> + return "DEBUG";
> case GUC_CRASH_DUMP_LOG_BUFFER:
> return "CRASH";
> default:
> @@ -708,7 +699,7 @@ void intel_guc_log_info(struct intel_guc_log *log, struct drm_printer *p)
>
> drm_printf(p, "\tRelay full count: %u\n", log->relay.full_count);
>
> - for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> + for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> drm_printf(p, "\t%s:\tflush count %10u, overflow count %10u\n",
> stringify_guc_log_type(type),
> log->stats[type].flush,
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
> index 11fccd0b2294..ac1ee1d5ce10 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
> @@ -17,12 +17,10 @@ struct intel_guc;
>
> #ifdef CONFIG_DRM_I915_DEBUG_GUC
> #define CRASH_BUFFER_SIZE SZ_2M
> -#define DPC_BUFFER_SIZE SZ_8M
> -#define ISR_BUFFER_SIZE SZ_8M
> +#define DEBUG_BUFFER_SIZE SZ_16M
> #else
> #define CRASH_BUFFER_SIZE SZ_8K
> -#define DPC_BUFFER_SIZE SZ_32K
> -#define ISR_BUFFER_SIZE SZ_32K
> +#define DEBUG_BUFFER_SIZE SZ_64K
> #endif
>
> /*
> --
> 2.28.0
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 12/13] drm/i915/guc: Unified GuC log
@ 2021-06-07 18:05 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 18:05 UTC (permalink / raw)
To: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 11:03:54AM -0700, Matthew Brost wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> GuC v57 unified the 'DPC' and 'ISR' buffers into a single buffer with
> the option for it to be larger.
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 15 ++++-------
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 9 +++----
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +++++++--------------
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 ++---
> 4 files changed, 20 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index b773567cb080..6661dcb02239 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -219,24 +219,19 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
>
> BUILD_BUG_ON(!CRASH_BUFFER_SIZE);
> BUILD_BUG_ON(!IS_ALIGNED(CRASH_BUFFER_SIZE, UNIT));
> - BUILD_BUG_ON(!DPC_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(DPC_BUFFER_SIZE, UNIT));
> - BUILD_BUG_ON(!ISR_BUFFER_SIZE);
> - BUILD_BUG_ON(!IS_ALIGNED(ISR_BUFFER_SIZE, UNIT));
> + BUILD_BUG_ON(!DEBUG_BUFFER_SIZE);
> + BUILD_BUG_ON(!IS_ALIGNED(DEBUG_BUFFER_SIZE, UNIT));
>
> BUILD_BUG_ON((CRASH_BUFFER_SIZE / UNIT - 1) >
> (GUC_LOG_CRASH_MASK >> GUC_LOG_CRASH_SHIFT));
> - BUILD_BUG_ON((DPC_BUFFER_SIZE / UNIT - 1) >
> - (GUC_LOG_DPC_MASK >> GUC_LOG_DPC_SHIFT));
> - BUILD_BUG_ON((ISR_BUFFER_SIZE / UNIT - 1) >
> - (GUC_LOG_ISR_MASK >> GUC_LOG_ISR_SHIFT));
> + BUILD_BUG_ON((DEBUG_BUFFER_SIZE / UNIT - 1) >
> + (GUC_LOG_DEBUG_MASK >> GUC_LOG_DEBUG_SHIFT));
>
> flags = GUC_LOG_VALID |
> GUC_LOG_NOTIFY_ON_HALF_FULL |
> FLAG |
> ((CRASH_BUFFER_SIZE / UNIT - 1) << GUC_LOG_CRASH_SHIFT) |
> - ((DPC_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DPC_SHIFT) |
> - ((ISR_BUFFER_SIZE / UNIT - 1) << GUC_LOG_ISR_SHIFT) |
> + ((DEBUG_BUFFER_SIZE / UNIT - 1) << GUC_LOG_DEBUG_SHIFT) |
> (offset << GUC_LOG_BUF_ADDR_SHIFT);
>
> #undef UNIT
> 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 f2df5c11c11d..617ec601648d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -81,10 +81,8 @@
> #define GUC_LOG_ALLOC_IN_MEGABYTE (1 << 3)
> #define GUC_LOG_CRASH_SHIFT 4
> #define GUC_LOG_CRASH_MASK (0x3 << GUC_LOG_CRASH_SHIFT)
> -#define GUC_LOG_DPC_SHIFT 6
> -#define GUC_LOG_DPC_MASK (0x7 << GUC_LOG_DPC_SHIFT)
> -#define GUC_LOG_ISR_SHIFT 9
> -#define GUC_LOG_ISR_MASK (0x7 << GUC_LOG_ISR_SHIFT)
> +#define GUC_LOG_DEBUG_SHIFT 6
> +#define GUC_LOG_DEBUG_MASK (0xF << GUC_LOG_DEBUG_SHIFT)
> #define GUC_LOG_BUF_ADDR_SHIFT 12
>
> #define GUC_CTL_WA 1
> @@ -311,8 +309,7 @@ struct guc_ads {
> /* GuC logging structures */
>
> enum guc_log_buffer_type {
> - GUC_ISR_LOG_BUFFER,
> - GUC_DPC_LOG_BUFFER,
> + GUC_DEBUG_LOG_BUFFER,
> GUC_CRASH_DUMP_LOG_BUFFER,
> GUC_MAX_LOG_BUFFER
> };
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> index c36d5eb5bbb9..ac0931f0374b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> @@ -197,10 +197,8 @@ static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
> static unsigned int guc_get_log_buffer_size(enum guc_log_buffer_type type)
> {
> switch (type) {
> - case GUC_ISR_LOG_BUFFER:
> - return ISR_BUFFER_SIZE;
> - case GUC_DPC_LOG_BUFFER:
> - return DPC_BUFFER_SIZE;
> + case GUC_DEBUG_LOG_BUFFER:
> + return DEBUG_BUFFER_SIZE;
> case GUC_CRASH_DUMP_LOG_BUFFER:
> return CRASH_BUFFER_SIZE;
> default:
> @@ -245,7 +243,7 @@ static void guc_read_update_log_buffer(struct intel_guc_log *log)
> src_data += PAGE_SIZE;
> dst_data += PAGE_SIZE;
>
> - for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> + for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> /*
> * Make a copy of the state structure, inside GuC log buffer
> * (which is uncached mapped), on the stack to avoid reading
> @@ -463,21 +461,16 @@ int intel_guc_log_create(struct intel_guc_log *log)
> * +===============================+ 00B
> * | Crash dump state header |
> * +-------------------------------+ 32B
> - * | DPC state header |
> + * | Debug state header |
> * +-------------------------------+ 64B
> - * | ISR state header |
> - * +-------------------------------+ 96B
> * | |
> * +===============================+ PAGE_SIZE (4KB)
> * | Crash Dump logs |
> * +===============================+ + CRASH_SIZE
> - * | DPC logs |
> - * +===============================+ + DPC_SIZE
> - * | ISR logs |
> - * +===============================+ + ISR_SIZE
> + * | Debug logs |
> + * +===============================+ + DEBUG_SIZE
> */
> - guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DPC_BUFFER_SIZE +
> - ISR_BUFFER_SIZE;
> + guc_log_size = PAGE_SIZE + CRASH_BUFFER_SIZE + DEBUG_BUFFER_SIZE;
>
> vma = intel_guc_allocate_vma(guc, guc_log_size);
> if (IS_ERR(vma)) {
> @@ -675,10 +668,8 @@ static const char *
> stringify_guc_log_type(enum guc_log_buffer_type type)
> {
> switch (type) {
> - case GUC_ISR_LOG_BUFFER:
> - return "ISR";
> - case GUC_DPC_LOG_BUFFER:
> - return "DPC";
> + case GUC_DEBUG_LOG_BUFFER:
> + return "DEBUG";
> case GUC_CRASH_DUMP_LOG_BUFFER:
> return "CRASH";
> default:
> @@ -708,7 +699,7 @@ void intel_guc_log_info(struct intel_guc_log *log, struct drm_printer *p)
>
> drm_printf(p, "\tRelay full count: %u\n", log->relay.full_count);
>
> - for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> + for (type = GUC_DEBUG_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
> drm_printf(p, "\t%s:\tflush count %10u, overflow count %10u\n",
> stringify_guc_log_type(type),
> log->stats[type].flush,
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
> index 11fccd0b2294..ac1ee1d5ce10 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.h
> @@ -17,12 +17,10 @@ struct intel_guc;
>
> #ifdef CONFIG_DRM_I915_DEBUG_GUC
> #define CRASH_BUFFER_SIZE SZ_2M
> -#define DPC_BUFFER_SIZE SZ_8M
> -#define ISR_BUFFER_SIZE SZ_8M
> +#define DEBUG_BUFFER_SIZE SZ_16M
> #else
> #define CRASH_BUFFER_SIZE SZ_8K
> -#define DPC_BUFFER_SIZE SZ_32K
> -#define ISR_BUFFER_SIZE SZ_32K
> +#define DEBUG_BUFFER_SIZE SZ_64K
> #endif
>
> /*
> --
> 2.28.0
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
` (14 preceding siblings ...)
(?)
@ 2021-06-07 18:06 ` Patchwork
-1 siblings, 0 replies; 87+ messages in thread
From: Patchwork @ 2021-06-07 18:06 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
== Series Details ==
Series: Update firmware to v62.0.0
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: expected struct i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: got void [noderef] __iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces)
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
` (15 preceding siblings ...)
(?)
@ 2021-06-07 18:34 ` Patchwork
-1 siblings, 0 replies; 87+ messages in thread
From: Patchwork @ 2021-06-07 18:34 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 9579 bytes --]
== Series Details ==
Series: Update firmware to v62.0.0
URL : https://patchwork.freedesktop.org/series/91106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10187 -> Patchwork_20298
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/index.html
Known issues
------------
Here are the changes found in Patchwork_20298 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
* igt@gem_tiled_blits@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +3 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@gem_tiled_blits@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#2782] / [i915#3462] / [i915#794])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886] / [i915#2291])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [PASS][5] -> [INCOMPLETE][6] ([i915#2782])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][9] ([i915#1436] / [i915#3363])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-soraka: [INCOMPLETE][10] ([i915#155]) -> [PASS][11]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-kbl-soraka/igt@gem_exec_suspend@basic-s0.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-soraka/igt@gem_exec_suspend@basic-s0.html
* igt@i915_selftest@live@gt_pm:
- fi-cml-s: [DMESG-FAIL][12] ([i915#2291]) -> [PASS][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-cml-s/igt@i915_selftest@live@gt_pm.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-cml-s/igt@i915_selftest@live@gt_pm.html
#### Warnings ####
* igt@i915_selftest@live@execlists:
- fi-cml-s: [INCOMPLETE][14] ([i915#3462]) -> [DMESG-FAIL][15] ([i915#3462])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-cml-s/igt@i915_selftest@live@execlists.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-cml-s/igt@i915_selftest@live@execlists.html
* igt@runner@aborted:
- fi-kbl-x1275: [FAIL][16] ([i915#1436] / [i915#3363]) -> [FAIL][17] ([i915#1436] / [i915#2426] / [i915#3363])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-kbl-x1275/igt@runner@aborted.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-x1275/igt@runner@aborted.html
- fi-cfl-8700k: [FAIL][18] ([i915#3363]) -> [FAIL][19] ([i915#2426] / [i915#3363])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-cfl-8700k/igt@runner@aborted.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-cfl-8700k/igt@runner@aborted.html
- fi-glk-dsi: [FAIL][20] ([i915#3363] / [k.org#202321]) -> [FAIL][21] ([i915#2426] / [i915#3363] / [k.org#202321])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-glk-dsi/igt@runner@aborted.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-glk-dsi/igt@runner@aborted.html
- fi-kbl-7500u: [FAIL][22] ([i915#1436] / [i915#3363]) -> [FAIL][23] ([i915#1436] / [i915#2426] / [i915#3363])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-kbl-7500u/igt@runner@aborted.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-7500u/igt@runner@aborted.html
- fi-cfl-guc: [FAIL][24] ([i915#3363]) -> [FAIL][25] ([i915#2426] / [i915#3363])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-cfl-guc/igt@runner@aborted.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-cfl-guc/igt@runner@aborted.html
- fi-kbl-7567u: [FAIL][26] ([i915#1436] / [i915#3363]) -> [FAIL][27] ([i915#1436] / [i915#2426] / [i915#3363])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-kbl-7567u/igt@runner@aborted.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-kbl-7567u/igt@runner@aborted.html
- fi-skl-guc: [FAIL][28] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][29] ([i915#1436] / [i915#3363])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-skl-guc/igt@runner@aborted.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-skl-guc/igt@runner@aborted.html
- fi-skl-6700k2: [FAIL][30] ([i915#1436] / [i915#2426] / [i915#3363]) -> [FAIL][31] ([i915#1436] / [i915#3363])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/fi-skl-6700k2/igt@runner@aborted.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/fi-skl-6700k2/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#794]: https://gitlab.freedesktop.org/drm/intel/issues/794
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (49 -> 42)
------------------------------
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-1
Build changes
-------------
* Linux: CI_DRM_10187 -> Patchwork_20298
CI-20190529: 20190529
CI_DRM_10187: 30bc4ca43fe0e01c64e5311342993f73a91eda64 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6099: adb9ee4ed7206725cfe3589bf49f47f9dcf661f2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_20298: 1998c178877bb7460aa73a8e0163a4b633d3cd7f @ git://anongit.freedesktop.org/gfx-ci/linux
== Kernel 32bit build ==
Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/Patchwork_20298/build_32bit.log
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready (#1)
MODPOST modules-only.symvers
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:150: recipe for target 'modules-only.symvers' failed
make[1]: *** [modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
Makefile:1759: recipe for target 'modules' failed
make: *** [modules] Error 2
== Linux commits ==
1998c178877b drm/i915/guc: Update firmware to v62.0.0
14d7602095b1 drm/i915/guc: Unified GuC log
1fcb4faa9a92 drm/i915/guc: Kill ads.client_info
65b657159e48 drm/i915/guc: Kill guc_clients.ct_pool
4143260c8c99 drm/i915/doc: Include GuC ABI documentation
fe305e722d41 drm/i915/guc: New CTB based communication
f8e5520d648c drm/i915/guc: New definition of the CTB registration action
98f39fdfdab9 drm/i915/guc: New definition of the CTB descriptor
fed4d47fabb2 drm/i915/guc: Add flag for mark broken CTB
4239eebfa25e drm/i915/guc: Support per context scheduling policies
c3c36fc8703e drm/i915/guc: Update CTB response status definition
067ec8d0b970 drm/i915/guc: Update MMIO based communication
5735522498b2 drm/i915/guc: Introduce unified HXG messages
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/index.html
[-- Attachment #1.2: Type: text/html, Size: 13521 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BUILD: warning for Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
` (16 preceding siblings ...)
(?)
@ 2021-06-07 18:34 ` Patchwork
-1 siblings, 0 replies; 87+ messages in thread
From: Patchwork @ 2021-06-07 18:34 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
== Series Details ==
Series: Update firmware to v62.0.0
URL : https://patchwork.freedesktop.org/series/91106/
State : warning
== Summary ==
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready (#1)
MODPOST modules-only.symvers
ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:150: recipe for target 'modules-only.symvers' failed
make[1]: *** [modules-only.symvers] Error 1
make[1]: *** Deleting file 'modules-only.symvers'
Makefile:1759: recipe for target 'modules' failed
make: *** [modules] Error 2
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/build_32bit.log
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 19:17 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 19:17 UTC (permalink / raw)
To: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 11:03:55AM -0700, Matthew Brost wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 ++++++++++++------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index df647c9a8d56..9f23e9de3237 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
> * firmware as TGL.
> */
> #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
> - fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
> - fw_def(ROCKETLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
> - fw_def(TIGERLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
> - fw_def(JASPERLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
> - fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
> - fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl, 9, 0, 0)) \
> - fw_def(COMETLAKE, 5, guc_def(cml, 49, 0, 1), huc_def(cml, 4, 0, 0)) \
> - fw_def(COMETLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
> - fw_def(COFFEELAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
> - fw_def(GEMINILAKE, 0, guc_def(glk, 49, 0, 1), huc_def(glk, 4, 0, 0)) \
> - fw_def(KABYLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
> - fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt, 2, 0, 0)) \
> - fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl, 2, 0, 0))
> + fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
> + fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
> + fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
> + fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
> + fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
> + fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl, 9, 0, 0)) \
> + fw_def(COMETLAKE, 5, guc_def(cml, 62, 0, 0), huc_def(cml, 4, 0, 0)) \
> + fw_def(COMETLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
> + fw_def(COFFEELAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
> + fw_def(GEMINILAKE, 0, guc_def(glk, 62, 0, 0), huc_def(glk, 4, 0, 0)) \
> + fw_def(KABYLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
> + fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt, 2, 0, 0)) \
> + fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl, 2, 0, 0))
>
> #define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
> "i915/" \
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0
@ 2021-06-07 19:17 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 19:17 UTC (permalink / raw)
To: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 11:03:55AM -0700, Matthew Brost wrote:
> From: John Harrison <John.C.Harrison@Intel.com>
>
> Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 ++++++++++++------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index df647c9a8d56..9f23e9de3237 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -48,19 +48,19 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
> * firmware as TGL.
> */
> #define INTEL_UC_FIRMWARE_DEFS(fw_def, guc_def, huc_def) \
> - fw_def(ALDERLAKE_S, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
> - fw_def(ROCKETLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
> - fw_def(TIGERLAKE, 0, guc_def(tgl, 49, 0, 1), huc_def(tgl, 7, 5, 0)) \
> - fw_def(JASPERLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
> - fw_def(ELKHARTLAKE, 0, guc_def(ehl, 49, 0, 1), huc_def(ehl, 9, 0, 0)) \
> - fw_def(ICELAKE, 0, guc_def(icl, 49, 0, 1), huc_def(icl, 9, 0, 0)) \
> - fw_def(COMETLAKE, 5, guc_def(cml, 49, 0, 1), huc_def(cml, 4, 0, 0)) \
> - fw_def(COMETLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
> - fw_def(COFFEELAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
> - fw_def(GEMINILAKE, 0, guc_def(glk, 49, 0, 1), huc_def(glk, 4, 0, 0)) \
> - fw_def(KABYLAKE, 0, guc_def(kbl, 49, 0, 1), huc_def(kbl, 4, 0, 0)) \
> - fw_def(BROXTON, 0, guc_def(bxt, 49, 0, 1), huc_def(bxt, 2, 0, 0)) \
> - fw_def(SKYLAKE, 0, guc_def(skl, 49, 0, 1), huc_def(skl, 2, 0, 0))
> + fw_def(ALDERLAKE_S, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
> + fw_def(ROCKETLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
> + fw_def(TIGERLAKE, 0, guc_def(tgl, 62, 0, 0), huc_def(tgl, 7, 5, 0)) \
> + fw_def(JASPERLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
> + fw_def(ELKHARTLAKE, 0, guc_def(ehl, 62, 0, 0), huc_def(ehl, 9, 0, 0)) \
> + fw_def(ICELAKE, 0, guc_def(icl, 62, 0, 0), huc_def(icl, 9, 0, 0)) \
> + fw_def(COMETLAKE, 5, guc_def(cml, 62, 0, 0), huc_def(cml, 4, 0, 0)) \
> + fw_def(COMETLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
> + fw_def(COFFEELAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
> + fw_def(GEMINILAKE, 0, guc_def(glk, 62, 0, 0), huc_def(glk, 4, 0, 0)) \
> + fw_def(KABYLAKE, 0, guc_def(kbl, 62, 0, 0), huc_def(kbl, 4, 0, 0)) \
> + fw_def(BROXTON, 0, guc_def(bxt, 62, 0, 0), huc_def(bxt, 2, 0, 0)) \
> + fw_def(SKYLAKE, 0, guc_def(skl, 62, 0, 0), huc_def(skl, 2, 0, 0))
>
> #define __MAKE_UC_FW_PATH(prefix_, name_, major_, minor_, patch_) \
> "i915/" \
> --
> 2.28.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
2021-06-07 19:38 ` Michal Wajdeczko
@ 2021-06-07 19:35 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 19:35 UTC (permalink / raw)
To: Michal Wajdeczko; +Cc: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 09:38:58PM +0200, Michal Wajdeczko wrote:
>
>
> On 07.06.2021 19:45, Matthew Brost wrote:
> > On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
> >> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>
> >> GuC ABI documentation is now ready to be included in i915.rst
> >>
> >> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> >
> > Michal - I noticed while putting this series together that there is
> > kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
> > think we should add the those here or in a new section (e.g. GuC CTBs)?
> >
> > Let me know what you think and I can fix this up before this gets
> > merged.
>
> What's in intel_guc_ct.* is implementation detail, that should be placed
> in separate section, while this patch adds pure ABI definitions that
> deserve its own dedicated section.
>
Sounds good. Will fix that in the next rev.
> Btw, this patch does not need to be squashed with others, as it is about
> updating .rst only and is not breaking anything. Same for patch 1/13
> that introduces new definitions in new .h file.
>
Agree. What I said in the cover letter isn't 100% correct as some of
patches probably don't have to be squashed. Next rev I'll go through
patch by patch and figure that part out.
Matt
> Michal
>
> >
> > With that, for this patch:
> >
> > Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> >
> >> ---
> >> Documentation/gpu/i915.rst | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> >> index 42ce0196930a..c7846b1d9293 100644
> >> --- a/Documentation/gpu/i915.rst
> >> +++ b/Documentation/gpu/i915.rst
> >> @@ -518,6 +518,14 @@ GuC-based command submission
> >> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> >> :doc: GuC-based command submission
> >>
> >> +GuC ABI
> >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >> +
> >> HuC
> >> ---
> >> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
> >> --
> >> 2.28.0
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
@ 2021-06-07 19:35 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-07 19:35 UTC (permalink / raw)
To: Michal Wajdeczko; +Cc: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 09:38:58PM +0200, Michal Wajdeczko wrote:
>
>
> On 07.06.2021 19:45, Matthew Brost wrote:
> > On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
> >> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>
> >> GuC ABI documentation is now ready to be included in i915.rst
> >>
> >> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> >
> > Michal - I noticed while putting this series together that there is
> > kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
> > think we should add the those here or in a new section (e.g. GuC CTBs)?
> >
> > Let me know what you think and I can fix this up before this gets
> > merged.
>
> What's in intel_guc_ct.* is implementation detail, that should be placed
> in separate section, while this patch adds pure ABI definitions that
> deserve its own dedicated section.
>
Sounds good. Will fix that in the next rev.
> Btw, this patch does not need to be squashed with others, as it is about
> updating .rst only and is not breaking anything. Same for patch 1/13
> that introduces new definitions in new .h file.
>
Agree. What I said in the cover letter isn't 100% correct as some of
patches probably don't have to be squashed. Next rev I'll go through
patch by patch and figure that part out.
Matt
> Michal
>
> >
> > With that, for this patch:
> >
> > Reviewed-by: Matthew Brost <matthew.brost@intel.com>
> >
> >> ---
> >> Documentation/gpu/i915.rst | 8 ++++++++
> >> 1 file changed, 8 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> >> index 42ce0196930a..c7846b1d9293 100644
> >> --- a/Documentation/gpu/i915.rst
> >> +++ b/Documentation/gpu/i915.rst
> >> @@ -518,6 +518,14 @@ GuC-based command submission
> >> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> >> :doc: GuC-based command submission
> >>
> >> +GuC ABI
> >> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> +
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> >> +
> >> HuC
> >> ---
> >> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
> >> --
> >> 2.28.0
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
2021-06-07 17:45 ` Matthew Brost
@ 2021-06-07 19:38 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-07 19:38 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 07.06.2021 19:45, Matthew Brost wrote:
> On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> GuC ABI documentation is now ready to be included in i915.rst
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
>
> Michal - I noticed while putting this series together that there is
> kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
> think we should add the those here or in a new section (e.g. GuC CTBs)?
>
> Let me know what you think and I can fix this up before this gets
> merged.
What's in intel_guc_ct.* is implementation detail, that should be placed
in separate section, while this patch adds pure ABI definitions that
deserve its own dedicated section.
Btw, this patch does not need to be squashed with others, as it is about
updating .rst only and is not breaking anything. Same for patch 1/13
that introduces new definitions in new .h file.
Michal
>
> With that, for this patch:
>
> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
>
>> ---
>> Documentation/gpu/i915.rst | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
>> index 42ce0196930a..c7846b1d9293 100644
>> --- a/Documentation/gpu/i915.rst
>> +++ b/Documentation/gpu/i915.rst
>> @@ -518,6 +518,14 @@ GuC-based command submission
>> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> :doc: GuC-based command submission
>>
>> +GuC ABI
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> +
>> HuC
>> ---
>> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> --
>> 2.28.0
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation
@ 2021-06-07 19:38 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-07 19:38 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 07.06.2021 19:45, Matthew Brost wrote:
> On Mon, Jun 07, 2021 at 11:03:51AM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> GuC ABI documentation is now ready to be included in i915.rst
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
>
> Michal - I noticed while putting this series together that there is
> kernel doc in intel_guc_ct.* but this isn't inclued in i915.rst. Do you
> think we should add the those here or in a new section (e.g. GuC CTBs)?
>
> Let me know what you think and I can fix this up before this gets
> merged.
What's in intel_guc_ct.* is implementation detail, that should be placed
in separate section, while this patch adds pure ABI definitions that
deserve its own dedicated section.
Btw, this patch does not need to be squashed with others, as it is about
updating .rst only and is not breaking anything. Same for patch 1/13
that introduces new definitions in new .h file.
Michal
>
> With that, for this patch:
>
> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
>
>> ---
>> Documentation/gpu/i915.rst | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
>> index 42ce0196930a..c7846b1d9293 100644
>> --- a/Documentation/gpu/i915.rst
>> +++ b/Documentation/gpu/i915.rst
>> @@ -518,6 +518,14 @@ GuC-based command submission
>> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>> :doc: GuC-based command submission
>>
>> +GuC ABI
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
>> +
>> HuC
>> ---
>> .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc.c
>> --
>> 2.28.0
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 00/13] Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 22:19 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-07 22:19 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> As part of enabling GuC submission [1] we need to update to the latest
> and greatest firmware. This series does that. This is a destructive
> change. e.g. Without all the patches in this series it will break the
> i915 driver. As such, after we review all of these patches they will
> squashed into a single patch for merging.
Can you resubmit with an added HAX patch for enable_guc=2 after the
first round of review? none of the machines in CI seems to have
attempted to load the guc, not even cfl-guc and kbl-guc. If all the
reviews are good maybe just resubmit the squashed patch and the
enablement with a CI tag, so we can merge once we get the results.
Daniele
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>
> [1] https://patchwork.freedesktop.org/series/89844/
>
> John Harrison (3):
> drm/i915/guc: Support per context scheduling policies
> drm/i915/guc: Unified GuC log
> drm/i915/guc: Update firmware to v62.0.0
>
> Michal Wajdeczko (10):
> drm/i915/guc: Introduce unified HXG messages
> drm/i915/guc: Update MMIO based communication
> drm/i915/guc: Update CTB response status definition
> drm/i915/guc: Add flag for mark broken CTB
> drm/i915/guc: New definition of the CTB descriptor
> drm/i915/guc: New definition of the CTB registration action
> drm/i915/guc: New CTB based communication
> drm/i915/doc: Include GuC ABI documentation
> drm/i915/guc: Kill guc_clients.ct_pool
> drm/i915/guc: Kill ads.client_info
>
> Documentation/gpu/i915.rst | 8 +
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++
> .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +++++--
> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--
> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++++++++++
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 107 ++++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 45 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +++++++++---------
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 75 +---
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 +-
> 13 files changed, 750 insertions(+), 420 deletions(-)
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0
@ 2021-06-07 22:19 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-07 22:19 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> As part of enabling GuC submission [1] we need to update to the latest
> and greatest firmware. This series does that. This is a destructive
> change. e.g. Without all the patches in this series it will break the
> i915 driver. As such, after we review all of these patches they will
> squashed into a single patch for merging.
Can you resubmit with an added HAX patch for enable_guc=2 after the
first round of review? none of the machines in CI seems to have
attempted to load the guc, not even cfl-guc and kbl-guc. If all the
reviews are good maybe just resubmit the squashed patch and the
enablement with a CI tag, so we can merge once we get the results.
Daniele
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>
> [1] https://patchwork.freedesktop.org/series/89844/
>
> John Harrison (3):
> drm/i915/guc: Support per context scheduling policies
> drm/i915/guc: Unified GuC log
> drm/i915/guc: Update firmware to v62.0.0
>
> Michal Wajdeczko (10):
> drm/i915/guc: Introduce unified HXG messages
> drm/i915/guc: Update MMIO based communication
> drm/i915/guc: Update CTB response status definition
> drm/i915/guc: Add flag for mark broken CTB
> drm/i915/guc: New definition of the CTB descriptor
> drm/i915/guc: New definition of the CTB registration action
> drm/i915/guc: New CTB based communication
> drm/i915/doc: Include GuC ABI documentation
> drm/i915/guc: Kill guc_clients.ct_pool
> drm/i915/guc: Kill ads.client_info
>
> Documentation/gpu/i915.rst | 8 +
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++
> .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +++++--
> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--
> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++++++++++
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 107 ++++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 45 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +++++++++---------
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 75 +---
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 +-
> 13 files changed, 750 insertions(+), 420 deletions(-)
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 22:46 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-07 22:46 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> New GuC firmware will unify format of MMIO and CTB H2G messages.
> Introduce their definitions now to allow gradual transition of
> our code to match new changes.
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++++++++++++++++++
> 1 file changed, 213 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> index 775e21f3058c..29ac823acd4c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> @@ -6,6 +6,219 @@
> #ifndef _ABI_GUC_MESSAGES_ABI_H
> #define _ABI_GUC_MESSAGES_ABI_H
>
> +/**
> + * DOC: HXG Message
> + *
> + * All messages exchanged with GuC are defined using 32 bit dwords.
> + * First dword is treated as a message header. Remaining dwords are optional.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | | | |
> + * | 0 | 31 | **ORIGIN** - originator of the message |
> + * | | | - _`GUC_HXG_ORIGIN_HOST` = 0 |
> + * | | | - _`GUC_HXG_ORIGIN_GUC` = 1 |
> + * | | | |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | **TYPE** - message type |
> + * | | | - _`GUC_HXG_TYPE_REQUEST` = 0 |
> + * | | | - _`GUC_HXG_TYPE_EVENT` = 1 |
> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 |
> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5 |
> + * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 |
> + * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **AUX** - auxiliary data (depends on TYPE) |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **PAYLOAD** - optional payload (depends on TYPE) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_MSG_MIN_LEN 1u
> +#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
Any reason not to use BIT(31) here? same below with other bits and with
GENMASK for masks.
> +#define GUC_HXG_ORIGIN_HOST 0u
> +#define GUC_HXG_ORIGIN_GUC 1u
> +#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
I think the masks could use a _MASK postfix
> +#define GUC_HXG_TYPE_REQUEST 0u
> +#define GUC_HXG_TYPE_EVENT 1u
> +#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
> +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u
> +#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
> +#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
> +#define GUC_HXG_MSG_0_AUX (0xfffffff << 0)
> +#define GUC_HXG_MSG_n_PAYLOAD (0xffffffff << 0)
Is a mask that covers the whole u32 really needed? Even for future
proofing, I find it very unlikely that we'll ever have a case where the
payload is not an entire dword.
> +
> +/**
> + * DOC: HXG Request
> + *
> + * The `HXG Request`_ message should be used to initiate synchronous activity
> + * for which confirmation or return data is expected.
> + *
> + * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
> + * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
> + * message as a intermediate reply.
> + *
> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | **DATA0** - request data (depends on ACTION) |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | **ACTION** - requested action code |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **DATAn** - optional data (depends on ACTION) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_REQUEST_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_REQUEST_MSG_0_DATA0 (0xfff << 16)
> +#define GUC_HXG_REQUEST_MSG_0_ACTION (0xffff << 0)
> +#define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
> +
> +/**
> + * DOC: HXG Event
> + *
> + * The `HXG Event`_ message should be used to initiate asynchronous activity
> + * that does not involves immediate confirmation nor data.
> + *
> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_EVENT_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | **DATA0** - event data (depends on ACTION) |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | **ACTION** - event action code |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **DATAn** - optional event data (depends on ACTION) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_EVENT_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_EVENT_MSG_0_DATA0 (0xfff << 16)
> +#define GUC_HXG_EVENT_MSG_0_ACTION (0xffff << 0)
> +#define GUC_HXG_EVENT_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
> +
> +/**
> + * DOC: HXG Busy
> + *
> + * The `HXG Busy`_ message may be used to acknowledge reception of the `HXG Request`_
> + * message if the recipient expects that it processing will be longer than default
> + * timeout.
> + *
> + * The @COUNTER field may be used as a progress indicator.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_BUSY_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **COUNTER** - progress indicator |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_BUSY_MSG_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_BUSY_MSG_0_COUNTER GUC_HXG_MSG_0_AUX
> +
> +/**
> + * DOC: HXG Retry
> + *
> + * The `HXG Retry`_ message should be used by recipient to indicate that the
> + * `HXG Request`_ message was dropped and it should be resent again.
> + *
> + * The @REASON field may be used to provide additional information.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_RETRY_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **REASON** - reason for retry |
> + * | | | - _`GUC_HXG_RETRY_REASON_UNSPECIFIED` = 0 |
AFAICS in the specs for 62.0.0 this field is actually a MBZ. Where does
the "reason" classification come from?
Apart from this, all the defines match the specs.
Daniele
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_RETRY_MSG_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_RETRY_MSG_0_REASON GUC_HXG_MSG_0_AUX
> +#define GUC_HXG_RETRY_REASON_UNSPECIFIED 0u
> +
> +/**
> + * DOC: HXG Failure
> + *
> + * The `HXG Failure`_ message shall be used as a reply to the `HXG Request`_
> + * message that could not be processed due to an error.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_FAILURE_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | **HINT** - additional error hint |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | **ERROR** - error/result code |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_FAILURE_MSG_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_FAILURE_MSG_0_HINT (0xfff << 16)
> +#define GUC_HXG_FAILURE_MSG_0_ERROR (0xffff << 0)
> +
> +/**
> + * DOC: HXG Response
> + *
> + * The `HXG Response`_ message shall be used as a reply to the `HXG Request`_
> + * message that was successfully processed without an error.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **DATA0** - data (depends on ACTION from `HXG Request`_) |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **DATAn** - data (depends on ACTION from `HXG Request`_) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_RESPONSE_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_RESPONSE_MSG_0_DATA0 GUC_HXG_MSG_0_AUX
> +#define GUC_HXG_RESPONSE_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
> +
> +/* deprecated */
> #define INTEL_GUC_MSG_TYPE_SHIFT 28
> #define INTEL_GUC_MSG_TYPE_MASK (0xF << INTEL_GUC_MSG_TYPE_SHIFT)
> #define INTEL_GUC_MSG_DATA_SHIFT 16
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
@ 2021-06-07 22:46 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-07 22:46 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> New GuC firmware will unify format of MMIO and CTB H2G messages.
> Introduce their definitions now to allow gradual transition of
> our code to match new changes.
>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++++++++++++++++++
> 1 file changed, 213 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> index 775e21f3058c..29ac823acd4c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> @@ -6,6 +6,219 @@
> #ifndef _ABI_GUC_MESSAGES_ABI_H
> #define _ABI_GUC_MESSAGES_ABI_H
>
> +/**
> + * DOC: HXG Message
> + *
> + * All messages exchanged with GuC are defined using 32 bit dwords.
> + * First dword is treated as a message header. Remaining dwords are optional.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | | | |
> + * | 0 | 31 | **ORIGIN** - originator of the message |
> + * | | | - _`GUC_HXG_ORIGIN_HOST` = 0 |
> + * | | | - _`GUC_HXG_ORIGIN_GUC` = 1 |
> + * | | | |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | **TYPE** - message type |
> + * | | | - _`GUC_HXG_TYPE_REQUEST` = 0 |
> + * | | | - _`GUC_HXG_TYPE_EVENT` = 1 |
> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = 3 |
> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = 5 |
> + * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = 6 |
> + * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = 7 |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **AUX** - auxiliary data (depends on TYPE) |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **PAYLOAD** - optional payload (depends on TYPE) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_MSG_MIN_LEN 1u
> +#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
Any reason not to use BIT(31) here? same below with other bits and with
GENMASK for masks.
> +#define GUC_HXG_ORIGIN_HOST 0u
> +#define GUC_HXG_ORIGIN_GUC 1u
> +#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
I think the masks could use a _MASK postfix
> +#define GUC_HXG_TYPE_REQUEST 0u
> +#define GUC_HXG_TYPE_EVENT 1u
> +#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
> +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u
> +#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
> +#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
> +#define GUC_HXG_MSG_0_AUX (0xfffffff << 0)
> +#define GUC_HXG_MSG_n_PAYLOAD (0xffffffff << 0)
Is a mask that covers the whole u32 really needed? Even for future
proofing, I find it very unlikely that we'll ever have a case where the
payload is not an entire dword.
> +
> +/**
> + * DOC: HXG Request
> + *
> + * The `HXG Request`_ message should be used to initiate synchronous activity
> + * for which confirmation or return data is expected.
> + *
> + * The recipient of this message shall use `HXG Response`_, `HXG Failure`_
> + * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
> + * message as a intermediate reply.
> + *
> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | **DATA0** - request data (depends on ACTION) |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | **ACTION** - requested action code |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **DATAn** - optional data (depends on ACTION) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_REQUEST_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_REQUEST_MSG_0_DATA0 (0xfff << 16)
> +#define GUC_HXG_REQUEST_MSG_0_ACTION (0xffff << 0)
> +#define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
> +
> +/**
> + * DOC: HXG Event
> + *
> + * The `HXG Event`_ message should be used to initiate asynchronous activity
> + * that does not involves immediate confirmation nor data.
> + *
> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_EVENT_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | **DATA0** - event data (depends on ACTION) |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | **ACTION** - event action code |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **DATAn** - optional event data (depends on ACTION) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_EVENT_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_EVENT_MSG_0_DATA0 (0xfff << 16)
> +#define GUC_HXG_EVENT_MSG_0_ACTION (0xffff << 0)
> +#define GUC_HXG_EVENT_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
> +
> +/**
> + * DOC: HXG Busy
> + *
> + * The `HXG Busy`_ message may be used to acknowledge reception of the `HXG Request`_
> + * message if the recipient expects that it processing will be longer than default
> + * timeout.
> + *
> + * The @COUNTER field may be used as a progress indicator.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_BUSY_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **COUNTER** - progress indicator |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_BUSY_MSG_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_BUSY_MSG_0_COUNTER GUC_HXG_MSG_0_AUX
> +
> +/**
> + * DOC: HXG Retry
> + *
> + * The `HXG Retry`_ message should be used by recipient to indicate that the
> + * `HXG Request`_ message was dropped and it should be resent again.
> + *
> + * The @REASON field may be used to provide additional information.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_NO_RESPONSE_RETRY_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **REASON** - reason for retry |
> + * | | | - _`GUC_HXG_RETRY_REASON_UNSPECIFIED` = 0 |
AFAICS in the specs for 62.0.0 this field is actually a MBZ. Where does
the "reason" classification come from?
Apart from this, all the defines match the specs.
Daniele
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_RETRY_MSG_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_RETRY_MSG_0_REASON GUC_HXG_MSG_0_AUX
> +#define GUC_HXG_RETRY_REASON_UNSPECIFIED 0u
> +
> +/**
> + * DOC: HXG Failure
> + *
> + * The `HXG Failure`_ message shall be used as a reply to the `HXG Request`_
> + * message that could not be processed due to an error.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_FAILURE_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | **HINT** - additional error hint |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | **ERROR** - error/result code |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_FAILURE_MSG_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_FAILURE_MSG_0_HINT (0xfff << 16)
> +#define GUC_HXG_FAILURE_MSG_0_ERROR (0xffff << 0)
> +
> +/**
> + * DOC: HXG Response
> + *
> + * The `HXG Response`_ message shall be used as a reply to the `HXG Request`_
> + * message that was successfully processed without an error.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | **DATA0** - data (depends on ACTION from `HXG Request`_) |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | |
> + * +---+-------+ |
> + * |...| | **DATAn** - data (depends on ACTION from `HXG Request`_) |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_HXG_RESPONSE_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
> +#define GUC_HXG_RESPONSE_MSG_0_DATA0 GUC_HXG_MSG_0_AUX
> +#define GUC_HXG_RESPONSE_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
> +
> +/* deprecated */
> #define INTEL_GUC_MSG_TYPE_SHIFT 28
> #define INTEL_GUC_MSG_TYPE_MASK (0xF << INTEL_GUC_MSG_TYPE_SHIFT)
> #define INTEL_GUC_MSG_DATA_SHIFT 16
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 02/13] drm/i915/guc: Update MMIO based communication
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-07 23:06 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-07 23:06 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> The MMIO based Host-to-GuC communication protocol has been
> updated to use unified HXG messages.
>
> Update our intel_guc_send_mmio() function by correctly handle
> BUSY, RETRY and FAILURE replies. Also update our documentation.
>
> GuC: 55.0.0
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
> ---
> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++++++-------
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
> 2 files changed, 97 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> index be066a62e9e0..3f9039e3ef9d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> @@ -7,46 +7,43 @@
> #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
>
> /**
> - * DOC: MMIO based communication
> + * DOC: GuC MMIO based communication
> *
> - * The MMIO based communication between Host and GuC uses software scratch
> - * registers, where first register holds data treated as message header,
> - * and other registers are used to hold message payload.
> + * The MMIO based communication between Host and GuC relies on special
> + * hardware registers which format could be defined by the software
> + * (so called scratch registers).
> *
> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
> - * but no H2G command takes more than 8 parameters and the GuC FW
> - * itself uses an 8-element array to store the H2G message.
> - *
> - * +-----------+---------+---------+---------+
> - * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
> - * +-----------+---------+---------+---------+
> - * | header | optional payload |
> - * +======+====+=========+=========+=========+
> - * | 31:28|type| | | |
> - * +------+----+ | | |
> - * | 27:16|data| | | |
> - * +------+----+ | | |
> - * | 15:0|code| | | |
> - * +------+----+---------+---------+---------+
> - *
> - * The message header consists of:
> - *
> - * - **type**, indicates message type
> - * - **code**, indicates message code, is specific for **type**
> - * - **data**, indicates message data, optional, depends on **code**
> + * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
> + * messages, which maximum length depends on number of available scratch
> + * registers, is directly written into those scratch registers.
> *
> - * The following message **types** are supported:
> + * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
> + * but no H2G command takes more than 8 parameters and the GuC firmware
> + * itself uses an 8-element array to store the H2G message.
Is this statement still true? I believe no MMIO H2G is over 4 DWs (given
the limitation of the new gen11+ scratch regs), while CTB messages can
be longer than 8 DWs.
> *
> - * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
> - * must be priovided in **code** field. Optional action specific parameters
> - * can be provided in remaining payload registers or **data** field.
> + * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
> + * are, regardless on lower count, preffered over legacy ones.
typo: preffered -> preferred
> *
> - * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
> - * action response status will be provided in **code** field. Optional
> - * response data can be returned in remaining payload registers or **data**
> - * field.
> + * The MMIO based communication is mainly used during driver initialization
> + * phase to setup the `CTB based communication`_ that will be used afterwards.
> */
>
> #define GUC_MAX_MMIO_MSG_LEN 8
See comment above. Reduce this to 4?
>
> +/**
> + * DOC: MMIO HXG Message
> + *
> + * Format of the MMIO messages follows definitions of `HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+ | | |
> + * |...| | | Embedded `HXG Message`_ | |
> + * +---+-------+ | | |
> + * | n | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index f147cb389a20..b773567cb080 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
> /*
> * This function implements the MMIO based host to GuC interface.
> */
> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
> u32 *response_buf, u32 response_buf_size)
> {
> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
> - u32 status;
> + u32 header;
> int i;
> int ret;
>
> GEM_BUG_ON(!len);
> GEM_BUG_ON(len > guc->send_regs.count);
>
> - /* We expect only action code */
> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
> -
> - /* If CT is available, we expect to use MMIO only during init/fini */
> - GEM_BUG_ON(*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
> - *action != INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) != GUC_HXG_ORIGIN_HOST);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) != GUC_HXG_TYPE_REQUEST);
>
> mutex_lock(&guc->send_mutex);
> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>
> +retry:
> for (i = 0; i < len; i++)
> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>
> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>
> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
> */
> ret = __intel_wait_for_register_fw(uncore,
> guc_send_reg(guc, 0),
> - INTEL_GUC_MSG_TYPE_MASK,
> - INTEL_GUC_MSG_TYPE_RESPONSE <<
> - INTEL_GUC_MSG_TYPE_SHIFT,
> - 10, 10, &status);
> - /* If GuC explicitly returned an error, convert it to -EIO */
> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
> - ret = -EIO;
> + GUC_HXG_MSG_0_ORIGIN,
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
> + GUC_HXG_ORIGIN_GUC),
> + 10, 10, &header);
> + if (unlikely(ret)) {
> +timeout:
> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
> + request[0], header);
> + goto out;
> + }
>
> - if (ret) {
> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
> - action[0], ret, status);
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc, 0)); \
> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC || \
> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
> +
> + ret = wait_for(done, 1000);
> + if (unlikely(ret))
> + goto timeout;
> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
> + GUC_HXG_ORIGIN_GUC))
> + goto proto;
> +#undef done
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
> +
> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
> + request[0], reason);
> + goto retry;
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_RESPONSE_FAILURE) {
> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
> +
> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
> + request[0], error, hint);
> + ret = -ENXIO;
> + goto out;
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
> +proto:
> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
> + request[0], header);
> + ret = -EPROTO;
> goto out;
> }
>
> if (response_buf) {
> - int count = min(response_buf_size, guc->send_regs.count - 1);
> + int count = min(response_buf_size, guc->send_regs.count);
>
> - for (i = 0; i < count; i++)
> + GEM_BUG_ON(!count);
> +
> + response_buf[0] = header;
> +
> + for (i = 1; i < count; i++)
> response_buf[i] = intel_uncore_read(uncore,
> - guc_send_reg(guc, i + 1));
> - }
> + guc_send_reg(guc, i));
This could use a note in the commit message to remark that we have no
users for the returned data yet and therefore nothing will break if we
change what we return through it.
Apart from the nits, the logic looks good to me.
Daniele
>
> - /* Use data from the GuC response as our return value */
> - ret = INTEL_GUC_MSG_TO_DATA(status);
> + /* Use number of copied dwords as our return value */
> + ret = count;
> + } else {
> + /* Use data from the GuC response as our return value */
> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
> + }
>
> out:
> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication
@ 2021-06-07 23:06 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-07 23:06 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> The MMIO based Host-to-GuC communication protocol has been
> updated to use unified HXG messages.
>
> Update our intel_guc_send_mmio() function by correctly handle
> BUSY, RETRY and FAILURE replies. Also update our documentation.
>
> GuC: 55.0.0
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
> ---
> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++++++-------
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
> 2 files changed, 97 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> index be066a62e9e0..3f9039e3ef9d 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> @@ -7,46 +7,43 @@
> #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
>
> /**
> - * DOC: MMIO based communication
> + * DOC: GuC MMIO based communication
> *
> - * The MMIO based communication between Host and GuC uses software scratch
> - * registers, where first register holds data treated as message header,
> - * and other registers are used to hold message payload.
> + * The MMIO based communication between Host and GuC relies on special
> + * hardware registers which format could be defined by the software
> + * (so called scratch registers).
> *
> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
> - * but no H2G command takes more than 8 parameters and the GuC FW
> - * itself uses an 8-element array to store the H2G message.
> - *
> - * +-----------+---------+---------+---------+
> - * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
> - * +-----------+---------+---------+---------+
> - * | header | optional payload |
> - * +======+====+=========+=========+=========+
> - * | 31:28|type| | | |
> - * +------+----+ | | |
> - * | 27:16|data| | | |
> - * +------+----+ | | |
> - * | 15:0|code| | | |
> - * +------+----+---------+---------+---------+
> - *
> - * The message header consists of:
> - *
> - * - **type**, indicates message type
> - * - **code**, indicates message code, is specific for **type**
> - * - **data**, indicates message data, optional, depends on **code**
> + * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
> + * messages, which maximum length depends on number of available scratch
> + * registers, is directly written into those scratch registers.
> *
> - * The following message **types** are supported:
> + * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
> + * but no H2G command takes more than 8 parameters and the GuC firmware
> + * itself uses an 8-element array to store the H2G message.
Is this statement still true? I believe no MMIO H2G is over 4 DWs (given
the limitation of the new gen11+ scratch regs), while CTB messages can
be longer than 8 DWs.
> *
> - * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
> - * must be priovided in **code** field. Optional action specific parameters
> - * can be provided in remaining payload registers or **data** field.
> + * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
> + * are, regardless on lower count, preffered over legacy ones.
typo: preffered -> preferred
> *
> - * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
> - * action response status will be provided in **code** field. Optional
> - * response data can be returned in remaining payload registers or **data**
> - * field.
> + * The MMIO based communication is mainly used during driver initialization
> + * phase to setup the `CTB based communication`_ that will be used afterwards.
> */
>
> #define GUC_MAX_MMIO_MSG_LEN 8
See comment above. Reduce this to 4?
>
> +/**
> + * DOC: MMIO HXG Message
> + *
> + * Format of the MMIO messages follows definitions of `HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+ | | |
> + * |...| | | Embedded `HXG Message`_ | |
> + * +---+-------+ | | |
> + * | n | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index f147cb389a20..b773567cb080 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
> /*
> * This function implements the MMIO based host to GuC interface.
> */
> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
> u32 *response_buf, u32 response_buf_size)
> {
> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
> - u32 status;
> + u32 header;
> int i;
> int ret;
>
> GEM_BUG_ON(!len);
> GEM_BUG_ON(len > guc->send_regs.count);
>
> - /* We expect only action code */
> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
> -
> - /* If CT is available, we expect to use MMIO only during init/fini */
> - GEM_BUG_ON(*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
> - *action != INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) != GUC_HXG_ORIGIN_HOST);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) != GUC_HXG_TYPE_REQUEST);
>
> mutex_lock(&guc->send_mutex);
> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>
> +retry:
> for (i = 0; i < len; i++)
> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>
> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>
> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
> */
> ret = __intel_wait_for_register_fw(uncore,
> guc_send_reg(guc, 0),
> - INTEL_GUC_MSG_TYPE_MASK,
> - INTEL_GUC_MSG_TYPE_RESPONSE <<
> - INTEL_GUC_MSG_TYPE_SHIFT,
> - 10, 10, &status);
> - /* If GuC explicitly returned an error, convert it to -EIO */
> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
> - ret = -EIO;
> + GUC_HXG_MSG_0_ORIGIN,
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
> + GUC_HXG_ORIGIN_GUC),
> + 10, 10, &header);
> + if (unlikely(ret)) {
> +timeout:
> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
> + request[0], header);
> + goto out;
> + }
>
> - if (ret) {
> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
> - action[0], ret, status);
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc, 0)); \
> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC || \
> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
> +
> + ret = wait_for(done, 1000);
> + if (unlikely(ret))
> + goto timeout;
> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
> + GUC_HXG_ORIGIN_GUC))
> + goto proto;
> +#undef done
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
> +
> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
> + request[0], reason);
> + goto retry;
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_RESPONSE_FAILURE) {
> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
> +
> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
> + request[0], error, hint);
> + ret = -ENXIO;
> + goto out;
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
> +proto:
> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
> + request[0], header);
> + ret = -EPROTO;
> goto out;
> }
>
> if (response_buf) {
> - int count = min(response_buf_size, guc->send_regs.count - 1);
> + int count = min(response_buf_size, guc->send_regs.count);
>
> - for (i = 0; i < count; i++)
> + GEM_BUG_ON(!count);
> +
> + response_buf[0] = header;
> +
> + for (i = 1; i < count; i++)
> response_buf[i] = intel_uncore_read(uncore,
> - guc_send_reg(guc, i + 1));
> - }
> + guc_send_reg(guc, i));
This could use a note in the commit message to remark that we have no
users for the returned data yet and therefore nothing will break if we
change what we return through it.
Apart from the nits, the logic looks good to me.
Daniele
>
> - /* Use data from the GuC response as our return value */
> - ret = INTEL_GUC_MSG_TO_DATA(status);
> + /* Use number of copied dwords as our return value */
> + ret = count;
> + } else {
> + /* Use data from the GuC response as our return value */
> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
> + }
>
> out:
> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 03/13] drm/i915/guc: Update CTB response status definition
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-08 0:05 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 0:05 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Format of the STATUS dword in CTB response message now follows
> definition of the HXG header. Update our code and remove any
> obsolete legacy definitions.
This is kind of hard to review on its own against the specs, because
there are larger changes to the CTB flows which AFAICS are part of patch
8. If what you wanted to do here was a simple replacement of defines to
keep the later patch simpler, then, considering all patches are going to
be squashed anyway:
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
One suggestion below.
>
> GuC: 55.0.0
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Acked-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 ++++++++------
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -----------------
> 2 files changed, 8 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 8f7b148fef58..3f7f48611487 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> * up to that length of time, then switch to a slower sleep-wait loop.
> * No GuC command should ever take longer than 10ms.
> */
> -#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
> +#define done \
> + (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + GUC_HXG_ORIGIN_GUC)
> err = wait_for_us(done, 10);
> if (err)
> err = wait_for(done, 10);
> @@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
> if (unlikely(err))
> goto unlink;
>
> - if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
> err = -EIO;
> goto unlink;
> }
>
> if (response_buf) {
> /* There shall be no data in the status */
> - WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
> + WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, request.status));
> /* Return actual response len */
> err = request.response_len;
> } else {
> /* There shall be no response payload */
> WARN_ON(request.response_len);
> /* Return data decoded from the status dword */
> - err = INTEL_GUC_MSG_TO_DATA(*status);
> + err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
Given that the same FIELD_GET() are repeated multiple times, IMO we
could've kept some helper macros, something like:
INTEL_GUC_HXG_RESPONSE_TO_DATA(hxg) \
FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, hxg)
INTEL_GUC_HXG_ORIGIN_IS_GUC(hxg) \
(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg) == GUC_HXG_ORIGIN_GUC)
INTEL_GUC_HXG_TYPE(hxg) \
FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg)
Which could be useful in the mmio code as well.
Not sure how this changes in patch 8 though, I might put some more
comments on that patch.
Daniele
> }
>
> unlink:
> @@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> status = response->msg[2];
> datalen = len - 2;
>
> - /* Format of the status follows RESPONSE message */
> - if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
> + /* Format of the status dword follows HXG header */
> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
> CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
> return -EPROTO;
> }
> 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 e9a9d85e2aa3..fb04e2211b79 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
> struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
> } __packed;
>
> -#define __INTEL_GUC_MSG_GET(T, m) \
> - (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
> -#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
> -#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
> -#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
> -
> -#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
> - (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
> -#define INTEL_GUC_MSG_IS_REQUEST(m) __INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
> -#define INTEL_GUC_MSG_IS_RESPONSE(m) __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
> -
> -#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
> - (typecheck(u32, (m)) && \
> - ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
> - ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
> - (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
> -
> /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
> enum intel_guc_recv_message {
> INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 03/13] drm/i915/guc: Update CTB response status definition
@ 2021-06-08 0:05 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 0:05 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Format of the STATUS dword in CTB response message now follows
> definition of the HXG header. Update our code and remove any
> obsolete legacy definitions.
This is kind of hard to review on its own against the specs, because
there are larger changes to the CTB flows which AFAICS are part of patch
8. If what you wanted to do here was a simple replacement of defines to
keep the later patch simpler, then, considering all patches are going to
be squashed anyway:
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
One suggestion below.
>
> GuC: 55.0.0
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Acked-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 ++++++++------
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -----------------
> 2 files changed, 8 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 8f7b148fef58..3f7f48611487 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> * up to that length of time, then switch to a slower sleep-wait loop.
> * No GuC command should ever take longer than 10ms.
> */
> -#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
> +#define done \
> + (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
> + GUC_HXG_ORIGIN_GUC)
> err = wait_for_us(done, 10);
> if (err)
> err = wait_for(done, 10);
> @@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
> if (unlikely(err))
> goto unlink;
>
> - if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
> err = -EIO;
> goto unlink;
> }
>
> if (response_buf) {
> /* There shall be no data in the status */
> - WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
> + WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, request.status));
> /* Return actual response len */
> err = request.response_len;
> } else {
> /* There shall be no response payload */
> WARN_ON(request.response_len);
> /* Return data decoded from the status dword */
> - err = INTEL_GUC_MSG_TO_DATA(*status);
> + err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
Given that the same FIELD_GET() are repeated multiple times, IMO we
could've kept some helper macros, something like:
INTEL_GUC_HXG_RESPONSE_TO_DATA(hxg) \
FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, hxg)
INTEL_GUC_HXG_ORIGIN_IS_GUC(hxg) \
(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg) == GUC_HXG_ORIGIN_GUC)
INTEL_GUC_HXG_TYPE(hxg) \
FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg)
Which could be useful in the mmio code as well.
Not sure how this changes in patch 8 though, I might put some more
comments on that patch.
Daniele
> }
>
> unlink:
> @@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> status = response->msg[2];
> datalen = len - 2;
>
> - /* Format of the status follows RESPONSE message */
> - if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
> + /* Format of the status dword follows HXG header */
> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
> CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
> return -EPROTO;
> }
> 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 e9a9d85e2aa3..fb04e2211b79 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
> struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
> } __packed;
>
> -#define __INTEL_GUC_MSG_GET(T, m) \
> - (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ## _SHIFT)
> -#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
> -#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
> -#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
> -
> -#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
> - (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
> -#define INTEL_GUC_MSG_IS_REQUEST(m) __INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
> -#define INTEL_GUC_MSG_IS_RESPONSE(m) __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
> -
> -#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
> - (typecheck(u32, (m)) && \
> - ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
> - ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
> - (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
> -
> /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
> enum intel_guc_recv_message {
> INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-08 0:59 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 0:59 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Definition of the CTB descriptor has changed, leaving only
> minimal shared fields like HEAD/TAIL/STATUS.
>
> Both HEAD and TAIL are now in dwords.
>
> Add some ABI documentation and implement required changes.
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> ---
> .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++++++++++++++-----
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +++++++++----------
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
> 3 files changed, 85 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index d38935f47ecf..c2a069a78e01 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -7,6 +7,58 @@
> #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
>
> #include <linux/types.h>
> +#include <linux/build_bug.h>
> +
> +#include "guc_messages_abi.h"
> +
> +/**
> + * DOC: CT Buffer
> + *
> + * TBD
What's the plan with this TBD here?
> + */
> +
> +/**
> + * DOC: CTB Descriptor
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:0 | **HEAD** - offset (in dwords) to the last dword that was |
> + * | | | read from the `CT Buffer`_. |
> + * | | | It can only be updated by the receiver. |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | **TAIL** - offset (in dwords) to the last dword that was |
> + * | | | written to the `CT Buffer`_. |
> + * | | | It can only be updated by the sender. |
> + * +---+-------+--------------------------------------------------------------+
> + * | 2 | 31:0 | **STATUS** - status of the CTB |
> + * | | | |
> + * | | | - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation) |
> + * | | | - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) |
> + * | | | - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message) |
> + * | | | - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified) |
> + * | | | - _`GUC_CTB_STATUS_NO_BACKCHANNEL` = 8 |
> + * | | | - _`GUC_CTB_STATUS_MALFORMED_MSG` = 16 |
I don't see the last 2 error (8 & 16) in the 62.0.0 specs. Where is the
reference for them?
> + * +---+-------+--------------------------------------------------------------+
> + * |...| | RESERVED = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + * | 15| 31:0 | RESERVED = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +struct guc_ct_buffer_desc {
> + u32 head;
> + u32 tail;
> + u32 status;
> +#define GUC_CTB_STATUS_NO_ERROR 0
> +#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
> +#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
> +#define GUC_CTB_STATUS_MISMATCH (1 << 2)
> +#define GUC_CTB_STATUS_NO_BACKCHANNEL (1 << 3)
> +#define GUC_CTB_STATUS_MALFORMED_MSG (1 << 4)
use BIT() ?
> + u32 reserved[13];
> +} __packed;
> +static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>
> /**
> * DOC: CTB based communication
> @@ -60,24 +112,6 @@
> * - **flags**, holds various bits to control message handling
> */
>
> -/*
> - * Describes single command transport buffer.
> - * Used by both guc-master and clients.
> - */
> -struct guc_ct_buffer_desc {
> - u32 addr; /* gfx address */
> - u64 host_private; /* host private data */
> - u32 size; /* size in bytes */
> - u32 head; /* offset updated by GuC*/
> - u32 tail; /* offset updated by owner */
> - u32 is_in_error; /* error indicator */
> - u32 reserved1;
> - u32 reserved2;
> - u32 owner; /* id of the channel owner */
> - u32 owner_sub_id; /* owner-defined field for extra tracking */
> - u32 reserved[5];
> -} __packed;
> -
> /* Type of command transport buffer */
> #define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> #define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 63056ea0631e..3241a477196f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -112,32 +112,28 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
> }
> }
>
> -static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
> - u32 cmds_addr, u32 size)
> +static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
this function is called from only 1 place and only does a memset now, so
IMO we can just drop it and inline the memset.
The logic below matches the specs.
Daniele
> {
> memset(desc, 0, sizeof(*desc));
> - desc->addr = cmds_addr;
> - desc->size = size;
> - desc->owner = CTB_OWNER_HOST;
> }
>
> -static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
> +static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> {
> ctb->broken = false;
> - guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
> + guc_ct_buffer_desc_init(ctb->desc);
> }
>
> static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
> struct guc_ct_buffer_desc *desc,
> - u32 *cmds, u32 size)
> + u32 *cmds, u32 size_in_bytes)
> {
> - GEM_BUG_ON(size % 4);
> + GEM_BUG_ON(size_in_bytes % 4);
>
> ctb->desc = desc;
> ctb->cmds = cmds;
> - ctb->size = size;
> + ctb->size = size_in_bytes / 4;
>
> - guc_ct_buffer_reset(ctb, 0);
> + guc_ct_buffer_reset(ctb);
> }
>
> static int guc_action_register_ct_buffer(struct intel_guc *guc,
> @@ -279,10 +275,10 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>
> /* (re)initialize descriptors */
> cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> - guc_ct_buffer_reset(&ct->ctbs.send, cmds);
> + guc_ct_buffer_reset(&ct->ctbs.send);
>
> cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> - guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
> + guc_ct_buffer_reset(&ct->ctbs.recv);
>
> /*
> * Register both CT buffers starting with RECV buffer.
> @@ -391,17 +387,15 @@ static int ct_write(struct intel_guc_ct *ct,
> if (unlikely(ctb->broken))
> return -EPIPE;
>
> - if (unlikely(desc->is_in_error))
> + if (unlikely(desc->status))
> goto corrupted;
>
> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
> - (tail | head) >= size))
> + if (unlikely((tail | head) >= size)) {
> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> + head, tail, size);
> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
> goto corrupted;
> -
> - /* later calculations will be done in dwords */
> - head /= 4;
> - tail /= 4;
> - size /= 4;
> + }
>
> /*
> * tail == head condition indicates empty. GuC FW does not support
> @@ -447,14 +441,14 @@ static int ct_write(struct intel_guc_ct *ct,
> */
> write_barrier(ct);
>
> - /* now update desc tail (back in bytes) */
> - desc->tail = tail * 4;
> + /* now update descriptor */
> + WRITE_ONCE(desc->tail, tail);
> +
> return 0;
>
> corrupted:
> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
> - desc->addr, desc->head, desc->tail, desc->size);
> - desc->is_in_error = 1;
> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
> + desc->head, desc->tail, desc->status);
> ctb->broken = true;
> return -EPIPE;
> }
> @@ -640,17 +634,15 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> if (unlikely(ctb->broken))
> return -EPIPE;
>
> - if (unlikely(desc->is_in_error))
> + if (unlikely(desc->status))
> goto corrupted;
>
> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
> - (tail | head) >= size))
> + if (unlikely((tail | head) >= size)) {
> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> + head, tail, size);
> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
> goto corrupted;
> -
> - /* later calculations will be done in dwords */
> - head /= 4;
> - tail /= 4;
> - size /= 4;
> + }
>
> /* tail == head condition indicates empty */
> available = tail - head;
> @@ -677,6 +669,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> size - head : available - 1), &cmds[head],
> 4 * (head + available - 1 > size ?
> available - 1 - size + head : 0), &cmds[0]);
> + desc->status |= GUC_CTB_STATUS_UNDERFLOW;
> goto corrupted;
> }
>
> @@ -699,13 +692,14 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> }
> CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
>
> - desc->head = head * 4;
> + /* now update descriptor */
> + WRITE_ONCE(desc->head, head);
> +
> return available - len;
>
> corrupted:
> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
> - desc->addr, desc->head, desc->tail, desc->size);
> - desc->is_in_error = 1;
> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
> + desc->head, desc->tail, desc->status);
> ctb->broken = true;
> return -EPIPE;
> }
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> index 7d3cd375d6a7..905202caaad3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> @@ -31,7 +31,7 @@ struct intel_guc;
> * @lock: protects access to the commands buffer and buffer descriptor
> * @desc: pointer to the buffer descriptor
> * @cmds: pointer to the commands buffer
> - * @size: size of the commands buffer
> + * @size: size of the commands buffer in dwords
> * @broken: flag to indicate if descriptor data is broken
> */
> struct intel_guc_ct_buffer {
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor
@ 2021-06-08 0:59 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 0:59 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Definition of the CTB descriptor has changed, leaving only
> minimal shared fields like HEAD/TAIL/STATUS.
>
> Both HEAD and TAIL are now in dwords.
>
> Add some ABI documentation and implement required changes.
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> ---
> .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++++++++++++++-----
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +++++++++----------
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
> 3 files changed, 85 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index d38935f47ecf..c2a069a78e01 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -7,6 +7,58 @@
> #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
>
> #include <linux/types.h>
> +#include <linux/build_bug.h>
> +
> +#include "guc_messages_abi.h"
> +
> +/**
> + * DOC: CT Buffer
> + *
> + * TBD
What's the plan with this TBD here?
> + */
> +
> +/**
> + * DOC: CTB Descriptor
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:0 | **HEAD** - offset (in dwords) to the last dword that was |
> + * | | | read from the `CT Buffer`_. |
> + * | | | It can only be updated by the receiver. |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | **TAIL** - offset (in dwords) to the last dword that was |
> + * | | | written to the `CT Buffer`_. |
> + * | | | It can only be updated by the sender. |
> + * +---+-------+--------------------------------------------------------------+
> + * | 2 | 31:0 | **STATUS** - status of the CTB |
> + * | | | |
> + * | | | - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal operation) |
> + * | | | - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too large) |
> + * | | | - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated message) |
> + * | | | - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail modified) |
> + * | | | - _`GUC_CTB_STATUS_NO_BACKCHANNEL` = 8 |
> + * | | | - _`GUC_CTB_STATUS_MALFORMED_MSG` = 16 |
I don't see the last 2 error (8 & 16) in the 62.0.0 specs. Where is the
reference for them?
> + * +---+-------+--------------------------------------------------------------+
> + * |...| | RESERVED = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + * | 15| 31:0 | RESERVED = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +struct guc_ct_buffer_desc {
> + u32 head;
> + u32 tail;
> + u32 status;
> +#define GUC_CTB_STATUS_NO_ERROR 0
> +#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
> +#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
> +#define GUC_CTB_STATUS_MISMATCH (1 << 2)
> +#define GUC_CTB_STATUS_NO_BACKCHANNEL (1 << 3)
> +#define GUC_CTB_STATUS_MALFORMED_MSG (1 << 4)
use BIT() ?
> + u32 reserved[13];
> +} __packed;
> +static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>
> /**
> * DOC: CTB based communication
> @@ -60,24 +112,6 @@
> * - **flags**, holds various bits to control message handling
> */
>
> -/*
> - * Describes single command transport buffer.
> - * Used by both guc-master and clients.
> - */
> -struct guc_ct_buffer_desc {
> - u32 addr; /* gfx address */
> - u64 host_private; /* host private data */
> - u32 size; /* size in bytes */
> - u32 head; /* offset updated by GuC*/
> - u32 tail; /* offset updated by owner */
> - u32 is_in_error; /* error indicator */
> - u32 reserved1;
> - u32 reserved2;
> - u32 owner; /* id of the channel owner */
> - u32 owner_sub_id; /* owner-defined field for extra tracking */
> - u32 reserved[5];
> -} __packed;
> -
> /* Type of command transport buffer */
> #define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> #define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 63056ea0631e..3241a477196f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -112,32 +112,28 @@ static inline const char *guc_ct_buffer_type_to_str(u32 type)
> }
> }
>
> -static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
> - u32 cmds_addr, u32 size)
> +static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
this function is called from only 1 place and only does a memset now, so
IMO we can just drop it and inline the memset.
The logic below matches the specs.
Daniele
> {
> memset(desc, 0, sizeof(*desc));
> - desc->addr = cmds_addr;
> - desc->size = size;
> - desc->owner = CTB_OWNER_HOST;
> }
>
> -static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb, u32 cmds_addr)
> +static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
> {
> ctb->broken = false;
> - guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
> + guc_ct_buffer_desc_init(ctb->desc);
> }
>
> static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
> struct guc_ct_buffer_desc *desc,
> - u32 *cmds, u32 size)
> + u32 *cmds, u32 size_in_bytes)
> {
> - GEM_BUG_ON(size % 4);
> + GEM_BUG_ON(size_in_bytes % 4);
>
> ctb->desc = desc;
> ctb->cmds = cmds;
> - ctb->size = size;
> + ctb->size = size_in_bytes / 4;
>
> - guc_ct_buffer_reset(ctb, 0);
> + guc_ct_buffer_reset(ctb);
> }
>
> static int guc_action_register_ct_buffer(struct intel_guc *guc,
> @@ -279,10 +275,10 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>
> /* (re)initialize descriptors */
> cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> - guc_ct_buffer_reset(&ct->ctbs.send, cmds);
> + guc_ct_buffer_reset(&ct->ctbs.send);
>
> cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> - guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
> + guc_ct_buffer_reset(&ct->ctbs.recv);
>
> /*
> * Register both CT buffers starting with RECV buffer.
> @@ -391,17 +387,15 @@ static int ct_write(struct intel_guc_ct *ct,
> if (unlikely(ctb->broken))
> return -EPIPE;
>
> - if (unlikely(desc->is_in_error))
> + if (unlikely(desc->status))
> goto corrupted;
>
> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
> - (tail | head) >= size))
> + if (unlikely((tail | head) >= size)) {
> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> + head, tail, size);
> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
> goto corrupted;
> -
> - /* later calculations will be done in dwords */
> - head /= 4;
> - tail /= 4;
> - size /= 4;
> + }
>
> /*
> * tail == head condition indicates empty. GuC FW does not support
> @@ -447,14 +441,14 @@ static int ct_write(struct intel_guc_ct *ct,
> */
> write_barrier(ct);
>
> - /* now update desc tail (back in bytes) */
> - desc->tail = tail * 4;
> + /* now update descriptor */
> + WRITE_ONCE(desc->tail, tail);
> +
> return 0;
>
> corrupted:
> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
> - desc->addr, desc->head, desc->tail, desc->size);
> - desc->is_in_error = 1;
> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
> + desc->head, desc->tail, desc->status);
> ctb->broken = true;
> return -EPIPE;
> }
> @@ -640,17 +634,15 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> if (unlikely(ctb->broken))
> return -EPIPE;
>
> - if (unlikely(desc->is_in_error))
> + if (unlikely(desc->status))
> goto corrupted;
>
> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
> - (tail | head) >= size))
> + if (unlikely((tail | head) >= size)) {
> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
> + head, tail, size);
> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
> goto corrupted;
> -
> - /* later calculations will be done in dwords */
> - head /= 4;
> - tail /= 4;
> - size /= 4;
> + }
>
> /* tail == head condition indicates empty */
> available = tail - head;
> @@ -677,6 +669,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> size - head : available - 1), &cmds[head],
> 4 * (head + available - 1 > size ?
> available - 1 - size + head : 0), &cmds[0]);
> + desc->status |= GUC_CTB_STATUS_UNDERFLOW;
> goto corrupted;
> }
>
> @@ -699,13 +692,14 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> }
> CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
>
> - desc->head = head * 4;
> + /* now update descriptor */
> + WRITE_ONCE(desc->head, head);
> +
> return available - len;
>
> corrupted:
> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u size=%u\n",
> - desc->addr, desc->head, desc->tail, desc->size);
> - desc->is_in_error = 1;
> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
> + desc->head, desc->tail, desc->status);
> ctb->broken = true;
> return -EPIPE;
> }
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> index 7d3cd375d6a7..905202caaad3 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> @@ -31,7 +31,7 @@ struct intel_guc;
> * @lock: protects access to the commands buffer and buffer descriptor
> * @desc: pointer to the buffer descriptor
> * @cmds: pointer to the commands buffer
> - * @size: size of the commands buffer
> + * @size: size of the commands buffer in dwords
> * @broken: flag to indicate if descriptor data is broken
> */
> struct intel_guc_ct_buffer {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-08 1:23 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 1:23 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Definition of the CTB registration action has changed.
> Add some ABI documentation and implement required changes.
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
> 3 files changed, 152 insertions(+), 35 deletions(-)
>
> 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 90efef8a73e4..6426fc183692 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
> @@ -6,6 +6,113 @@
> #ifndef _ABI_GUC_ACTIONS_ABI_H
> #define _ABI_GUC_ACTIONS_ABI_H
>
> +/**
> + * DOC: HOST2GUC_REGISTER_CTB
> + *
> + * This message is used as part of the `CTB based communication`_ setup.
> + *
> + * This message must be sent as `MMIO HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | DATA0 = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 0x5200 |
Specs says 4505
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:12 | RESERVED = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | **TYPE** - type for the `CT Buffer`_ |
> + * | | | |
> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` = 0 |
> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` = 1 |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1 |
> + * +---+-------+--------------------------------------------------------------+
> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_ |
> + * +---+-------+--------------------------------------------------------------+
> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ |
> + * +---+-------+--------------------------------------------------------------+
> +*
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | DATA0 = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
Why FIXME? AFAICS the specs still says 4505, even if we plan to update
at some point I don;t think this deserves a FIXME since nothing is
incorrect.
> +
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> +#define GUC_CTB_TYPE_HOST2GUC 0u
> +#define GUC_CTB_TYPE_GUC2HOST 1u
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
The full mask still seems like overkill to me and I still think we
should use BIT()/GENMASK() and a _MASK prefix, but not going to block on it.
> +
> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
> +
> +/**
> + * DOC: HOST2GUC_DEREGISTER_CTB
> + *
> + * This message is used as part of the `CTB based communication`_ teardown.
> + *
> + * This message must be sent as `MMIO HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | DATA0 = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` = 0x5201 |
Specs says 4506
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:12 | RESERVED = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | **TYPE** - type of the `CT Buffer`_ |
> + * | | | |
> + * | | | see `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | RESERVED = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> +*
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | DATA0 = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME 0x5201
Same comment for the FIXME as above
> +
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
> +
> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
> +
> +/* legacy definitions */
> +
> enum intel_guc_action {
> INTEL_GUC_ACTION_DEFAULT = 0x0,
> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index c2a069a78e01..127b256a662c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> * - **flags**, holds various bits to control message handling
> */
>
> -/* Type of command transport buffer */
> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> -
> /*
> * Definition of the command transport message header (DW0)
> *
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 3241a477196f..6a29be779cc9 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
> static inline const char *guc_ct_buffer_type_to_str(u32 type)
> {
> switch (type) {
> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> + case GUC_CTB_TYPE_HOST2GUC:
> return "SEND";
> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> + case GUC_CTB_TYPE_GUC2HOST:
> return "RECV";
> default:
> return "<invalid>";
> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
> guc_ct_buffer_reset(ctb);
> }
>
> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
> - u32 desc_addr,
> - u32 type)
> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32 type,
> + u32 desc_addr, u32 buff_addr, u32 size)
> {
> - u32 action[] = {
> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
> - desc_addr,
> - sizeof(struct guc_ct_buffer_desc),
> - type
> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_REGISTER_CTB),
IMO we could use a macro or 2 for the HXG header, to avoid all these
lines, which are hard to read. something like:
GUC_HXG_HEADER(origin, type, data, action) \
(FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
H2G_HEADER(type, data, action) \
GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
and then call
H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
Not a blocker.
Daniele
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K - 1) |
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
> };
>
> - /* Can't use generic send(), CT registration must go over MMIO */
> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
> + GEM_BUG_ON(size % SZ_4K);
> +
> + /* CT registration must go over MMIO */
> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
> }
>
> -static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
> + u32 desc_addr, u32 buff_addr, u32 size)
> {
> - int err = guc_action_register_ct_buffer(ct_to_guc(ct), desc_addr, type);
> + int err;
>
> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
> + desc_addr, buff_addr, size);
> if (unlikely(err))
> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
> guc_ct_buffer_type_to_str(type), err);
> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
>
> static int guc_action_deregister_ct_buffer(struct intel_guc *guc, u32 type)
> {
> - u32 action[] = {
> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
> - CTB_OWNER_HOST,
> - type
> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> };
>
> - /* Can't use generic send(), CT deregistration must go over MMIO */
> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
> +
> + /* CT deregistration must go over MMIO */
> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
> }
>
> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
> int intel_guc_ct_enable(struct intel_guc_ct *ct)
> {
> struct intel_guc *guc = ct_to_guc(ct);
> - u32 base, cmds;
> + u32 base, desc, cmds;
> void *blob;
> int err;
>
> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>
> /* (re)initialize descriptors */
> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> guc_ct_buffer_reset(&ct->ctbs.send);
> -
> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> guc_ct_buffer_reset(&ct->ctbs.recv);
>
> /*
> * Register both CT buffers starting with RECV buffer.
> * Descriptors are in first half of the blob.
> */
> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
> + desc, cmds, ct->ctbs.recv.size * 4);
> +
> if (unlikely(err))
> goto err_out;
>
> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
> + desc, cmds, ct->ctbs.send.size * 4);
> +
> if (unlikely(err))
> goto err_deregister;
>
> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> return 0;
>
> err_deregister:
> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> err_out:
> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
> return err;
> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
> ct->enabled = false;
>
> if (intel_guc_is_fw_running(guc)) {
> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> }
> }
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-08 1:23 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 1:23 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Definition of the CTB registration action has changed.
> Add some ABI documentation and implement required changes.
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
> 3 files changed, 152 insertions(+), 35 deletions(-)
>
> 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 90efef8a73e4..6426fc183692 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
> @@ -6,6 +6,113 @@
> #ifndef _ABI_GUC_ACTIONS_ABI_H
> #define _ABI_GUC_ACTIONS_ABI_H
>
> +/**
> + * DOC: HOST2GUC_REGISTER_CTB
> + *
> + * This message is used as part of the `CTB based communication`_ setup.
> + *
> + * This message must be sent as `MMIO HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | DATA0 = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` = 0x5200 |
Specs says 4505
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:12 | RESERVED = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | **TYPE** - type for the `CT Buffer`_ |
> + * | | | |
> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` = 0 |
> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` = 1 |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units minus 1 |
> + * +---+-------+--------------------------------------------------------------+
> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB Descriptor`_ |
> + * +---+-------+--------------------------------------------------------------+
> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT Buffer`_ |
> + * +---+-------+--------------------------------------------------------------+
> +*
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | DATA0 = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
Why FIXME? AFAICS the specs still says 4505, even if we plan to update
at some point I don;t think this deserves a FIXME since nothing is
incorrect.
> +
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> +#define GUC_CTB_TYPE_HOST2GUC 0u
> +#define GUC_CTB_TYPE_GUC2HOST 1u
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR GUC_HXG_REQUEST_MSG_n_DATAn
The full mask still seems like overkill to me and I still think we
should use BIT()/GENMASK() and a _MASK prefix, but not going to block on it.
> +
> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
> +
> +/**
> + * DOC: HOST2GUC_DEREGISTER_CTB
> + *
> + * This message is used as part of the `CTB based communication`_ teardown.
> + *
> + * This message must be sent as `MMIO HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_HOST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_REQUEST_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:16 | DATA0 = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` = 0x5201 |
Specs says 4506
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:12 | RESERVED = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | **TYPE** - type of the `CT Buffer`_ |
> + * | | | |
> + * | | | see `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | RESERVED = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> +*
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31 | ORIGIN = GUC_HXG_ORIGIN_GUC_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 30:28 | TYPE = GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 27:0 | DATA0 = MBZ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME 0x5201
Same comment for the FIXME as above
> +
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ GUC_HXG_REQUEST_MSG_0_DATA0
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
> +
> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN GUC_HXG_RESPONSE_MSG_MIN_LEN
> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ GUC_HXG_RESPONSE_MSG_0_DATA0
> +
> +/* legacy definitions */
> +
> enum intel_guc_action {
> INTEL_GUC_ACTION_DEFAULT = 0x0,
> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index c2a069a78e01..127b256a662c 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> * - **flags**, holds various bits to control message handling
> */
>
> -/* Type of command transport buffer */
> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> -
> /*
> * Definition of the command transport message header (DW0)
> *
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 3241a477196f..6a29be779cc9 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
> static inline const char *guc_ct_buffer_type_to_str(u32 type)
> {
> switch (type) {
> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> + case GUC_CTB_TYPE_HOST2GUC:
> return "SEND";
> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> + case GUC_CTB_TYPE_GUC2HOST:
> return "RECV";
> default:
> return "<invalid>";
> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
> guc_ct_buffer_reset(ctb);
> }
>
> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
> - u32 desc_addr,
> - u32 type)
> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32 type,
> + u32 desc_addr, u32 buff_addr, u32 size)
> {
> - u32 action[] = {
> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
> - desc_addr,
> - sizeof(struct guc_ct_buffer_desc),
> - type
> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_REGISTER_CTB),
IMO we could use a macro or 2 for the HXG header, to avoid all these
lines, which are hard to read. something like:
GUC_HXG_HEADER(origin, type, data, action) \
(FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
H2G_HEADER(type, data, action) \
GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
and then call
H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
Not a blocker.
Daniele
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K - 1) |
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
> };
>
> - /* Can't use generic send(), CT registration must go over MMIO */
> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
> + GEM_BUG_ON(size % SZ_4K);
> +
> + /* CT registration must go over MMIO */
> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
> }
>
> -static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
> + u32 desc_addr, u32 buff_addr, u32 size)
> {
> - int err = guc_action_register_ct_buffer(ct_to_guc(ct), desc_addr, type);
> + int err;
>
> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
> + desc_addr, buff_addr, size);
> if (unlikely(err))
> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
> guc_ct_buffer_type_to_str(type), err);
> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct intel_guc_ct *ct, u32 desc_addr, u32 type)
>
> static int guc_action_deregister_ct_buffer(struct intel_guc *guc, u32 type)
> {
> - u32 action[] = {
> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
> - CTB_OWNER_HOST,
> - type
> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> };
>
> - /* Can't use generic send(), CT deregistration must go over MMIO */
> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL, 0);
> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type != GUC_CTB_TYPE_GUC2HOST);
> +
> + /* CT deregistration must go over MMIO */
> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request), NULL, 0);
> }
>
> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
> int intel_guc_ct_enable(struct intel_guc_ct *ct)
> {
> struct intel_guc *guc = ct_to_guc(ct);
> - u32 base, cmds;
> + u32 base, desc, cmds;
> void *blob;
> int err;
>
> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>
> /* (re)initialize descriptors */
> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> guc_ct_buffer_reset(&ct->ctbs.send);
> -
> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> guc_ct_buffer_reset(&ct->ctbs.recv);
>
> /*
> * Register both CT buffers starting with RECV buffer.
> * Descriptors are in first half of the blob.
> */
> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
> + desc, cmds, ct->ctbs.recv.size * 4);
> +
> if (unlikely(err))
> goto err_out;
>
> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
> + desc, cmds, ct->ctbs.send.size * 4);
> +
> if (unlikely(err))
> goto err_deregister;
>
> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> return 0;
>
> err_deregister:
> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> err_out:
> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
> return err;
> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
> ct->enabled = false;
>
> if (intel_guc_is_fw_running(guc)) {
> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> }
> }
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for Update firmware to v62.0.0
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
` (18 preceding siblings ...)
(?)
@ 2021-06-08 2:17 ` Patchwork
-1 siblings, 0 replies; 87+ messages in thread
From: Patchwork @ 2021-06-08 2:17 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 30249 bytes --]
== Series Details ==
Series: Update firmware to v62.0.0
URL : https://patchwork.freedesktop.org/series/91106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10187_full -> Patchwork_20298_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_20298_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_persistence@clone:
- shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +2 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-snb5/igt@gem_ctx_persistence@clone.html
* igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl: NOTRUN -> [SKIP][2] ([fdo#109271]) +74 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl7/igt@gem_ctx_persistence@legacy-engines-hang@blt.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk5/igt@gem_exec_fair@basic-none@rcs0.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk4/igt@gem_exec_fair@basic-none@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-tglb7/igt@gem_exec_fair@basic-pace@vcs0.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb7/igt@gem_exec_fair@basic-pace@vcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk: NOTRUN -> [FAIL][7] ([i915#2842]) +2 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk7/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2389])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb1/igt@gem_exec_reloc@basic-wide-active@vcs1.html
* igt@gem_mmap_gtt@big-copy-xy:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#307])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk8/igt@gem_mmap_gtt@big-copy-xy.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk7/igt@gem_mmap_gtt@big-copy-xy.html
* igt@gem_mmap_gtt@cpuset-basic-small-copy-xy:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#307] / [i915#3468])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk7/igt@gem_mmap_gtt@cpuset-basic-small-copy-xy.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk6/igt@gem_mmap_gtt@cpuset-basic-small-copy-xy.html
* igt@gem_mmap_gtt@cpuset-big-copy:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#307])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb4/igt@gem_mmap_gtt@cpuset-big-copy.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb8/igt@gem_mmap_gtt@cpuset-big-copy.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [WARN][15] ([i915#2658])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl2/igt@gem_pread@exhaustion.html
* igt@gem_pwrite@basic-exhaustion:
- shard-snb: NOTRUN -> [WARN][16] ([i915#2658]) +1 similar issue
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-snb5/igt@gem_pwrite@basic-exhaustion.html
* igt@gem_userptr_blits@input-checking:
- shard-apl: NOTRUN -> [DMESG-WARN][17] ([i915#3002])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl2/igt@gem_userptr_blits@input-checking.html
* igt@gen7_exec_parse@batch-without-end:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109289]) +1 similar issue
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@gen7_exec_parse@batch-without-end.html
- shard-tglb: NOTRUN -> [SKIP][19] ([fdo#109289])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@gen7_exec_parse@batch-without-end.html
* igt@i915_pm_backlight@fade_with_dpms:
- shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271]) +33 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl2/igt@i915_pm_backlight@fade_with_dpms.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-tglb: NOTRUN -> [WARN][21] ([i915#2681])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- shard-tglb: NOTRUN -> [SKIP][22] ([fdo#111644] / [i915#1397] / [i915#2411])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@i915_pm_rpm@dpms-mode-unset-non-lpsp.html
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#110892])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@i915_pm_rpm@dpms-mode-unset-non-lpsp.html
* igt@i915_selftest@live@hangcheck:
- shard-snb: [PASS][24] -> [INCOMPLETE][25] ([i915#2782])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-snb7/igt@i915_selftest@live@hangcheck.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-snb6/igt@i915_selftest@live@hangcheck.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][26] -> [DMESG-WARN][27] ([i915#180]) +1 similar issue
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-apl7/igt@i915_suspend@sysfs-reader.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl6/igt@i915_suspend@sysfs-reader.html
- shard-kbl: [PASS][28] -> [DMESG-WARN][29] ([i915#180]) +2 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-kbl1/igt@i915_suspend@sysfs-reader.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl4/igt@i915_suspend@sysfs-reader.html
* igt@kms_big_fb@linear-8bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][30] ([fdo#111614]) +1 similar issue
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_big_fb@linear-8bpp-rotate-270.html
- shard-iclb: NOTRUN -> [SKIP][31] ([fdo#110725] / [fdo#111614])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_big_fb@linear-8bpp-rotate-270.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][32] ([fdo#111615]) +1 similar issue
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_big_fb@yf-tiled-64bpp-rotate-270.html
* igt@kms_big_joiner@invalid-modeset:
- shard-iclb: NOTRUN -> [SKIP][33] ([i915#2705])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_big_joiner@invalid-modeset.html
- shard-tglb: NOTRUN -> [SKIP][34] ([i915#2705])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_chamelium@hdmi-crc-multiple:
- shard-iclb: NOTRUN -> [SKIP][35] ([fdo#109284] / [fdo#111827]) +1 similar issue
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_chamelium@hdmi-crc-multiple.html
* igt@kms_chamelium@hdmi-edid-read:
- shard-skl: NOTRUN -> [SKIP][36] ([fdo#109271] / [fdo#111827]) +7 similar issues
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl2/igt@kms_chamelium@hdmi-edid-read.html
* igt@kms_chamelium@vga-hpd-after-suspend:
- shard-tglb: NOTRUN -> [SKIP][37] ([fdo#109284] / [fdo#111827]) +5 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_chamelium@vga-hpd-after-suspend.html
* igt@kms_chamelium@vga-hpd-without-ddc:
- shard-snb: NOTRUN -> [SKIP][38] ([fdo#109271] / [fdo#111827]) +15 similar issues
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-snb5/igt@kms_chamelium@vga-hpd-without-ddc.html
* igt@kms_color@pipe-d-ctm-0-75:
- shard-iclb: NOTRUN -> [SKIP][39] ([fdo#109278] / [i915#1149])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_color@pipe-d-ctm-0-75.html
* igt@kms_color_chamelium@pipe-a-ctm-0-5:
- shard-glk: NOTRUN -> [SKIP][40] ([fdo#109271] / [fdo#111827]) +2 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk7/igt@kms_color_chamelium@pipe-a-ctm-0-5.html
* igt@kms_color_chamelium@pipe-b-ctm-0-25:
- shard-kbl: NOTRUN -> [SKIP][41] ([fdo#109271] / [fdo#111827]) +4 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl2/igt@kms_color_chamelium@pipe-b-ctm-0-25.html
* igt@kms_color_chamelium@pipe-c-ctm-0-25:
- shard-apl: NOTRUN -> [SKIP][42] ([fdo#109271] / [fdo#111827]) +6 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl7/igt@kms_color_chamelium@pipe-c-ctm-0-25.html
* igt@kms_content_protection@atomic:
- shard-apl: NOTRUN -> [TIMEOUT][43] ([i915#1319])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl7/igt@kms_content_protection@atomic.html
* igt@kms_content_protection@legacy:
- shard-glk: NOTRUN -> [SKIP][44] ([fdo#109271]) +19 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk7/igt@kms_content_protection@legacy.html
* igt@kms_content_protection@srm:
- shard-tglb: NOTRUN -> [SKIP][45] ([fdo#111828])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_content_protection@srm.html
* igt@kms_cursor_crc@pipe-a-cursor-512x170-onscreen:
- shard-tglb: NOTRUN -> [SKIP][46] ([fdo#109279] / [i915#3359]) +1 similar issue
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_cursor_crc@pipe-a-cursor-512x170-onscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-32x32-sliding:
- shard-tglb: NOTRUN -> [SKIP][47] ([i915#3319]) +2 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_cursor_crc@pipe-b-cursor-32x32-sliding.html
* igt@kms_cursor_crc@pipe-b-cursor-512x170-offscreen:
- shard-iclb: NOTRUN -> [SKIP][48] ([fdo#109278] / [fdo#109279])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_cursor_crc@pipe-b-cursor-512x170-offscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-max-size-rapid-movement:
- shard-tglb: NOTRUN -> [SKIP][49] ([i915#3359]) +2 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_cursor_crc@pipe-b-cursor-max-size-rapid-movement.html
* igt@kms_cursor_crc@pipe-c-cursor-dpms:
- shard-apl: NOTRUN -> [FAIL][50] ([i915#3444])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl7/igt@kms_cursor_crc@pipe-c-cursor-dpms.html
* igt@kms_cursor_legacy@cursora-vs-flipb-legacy:
- shard-iclb: NOTRUN -> [SKIP][51] ([fdo#109274] / [fdo#109278])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_cursor_legacy@cursora-vs-flipb-legacy.html
* igt@kms_cursor_legacy@pipe-d-single-bo:
- shard-apl: NOTRUN -> [SKIP][52] ([fdo#109271] / [i915#533])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl7/igt@kms_cursor_legacy@pipe-d-single-bo.html
* igt@kms_cursor_legacy@pipe-d-torture-move:
- shard-iclb: NOTRUN -> [SKIP][53] ([fdo#109278]) +7 similar issues
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_cursor_legacy@pipe-d-torture-move.html
* igt@kms_flip@2x-wf_vblank-ts-check-interruptible:
- shard-iclb: NOTRUN -> [SKIP][54] ([fdo#109274])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_flip@2x-wf_vblank-ts-check-interruptible.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl: [PASS][55] -> [FAIL][56] ([i915#79])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
- shard-snb: NOTRUN -> [SKIP][57] ([fdo#109271]) +260 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-snb5/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-render:
- shard-iclb: NOTRUN -> [SKIP][58] ([fdo#109280]) +7 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move:
- shard-tglb: NOTRUN -> [SKIP][59] ([fdo#111825]) +14 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-move.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][60] -> [FAIL][61] ([i915#1188])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl5/igt@kms_hdr@bpc-switch-dpms.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl6/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-kbl: NOTRUN -> [DMESG-WARN][62] ([i915#180]) +2 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl4/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_hdr@static-swap:
- shard-tglb: NOTRUN -> [SKIP][63] ([i915#1187])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_hdr@static-swap.html
- shard-iclb: NOTRUN -> [SKIP][64] ([i915#1187])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_hdr@static-swap.html
* igt@kms_pipe_b_c_ivb@disable-pipe-b-enable-pipe-c:
- shard-apl: NOTRUN -> [SKIP][65] ([fdo#109271]) +96 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl7/igt@kms_pipe_b_c_ivb@disable-pipe-b-enable-pipe-c.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: NOTRUN -> [FAIL][66] ([fdo#108145] / [i915#265])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-apl: NOTRUN -> [FAIL][67] ([fdo#108145] / [i915#265])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl7/igt@kms_plane_alpha_blend@pipe-c-alpha-7efc.html
* igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- shard-skl: NOTRUN -> [SKIP][68] ([fdo#109271] / [i915#2733])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl2/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4:
- shard-tglb: NOTRUN -> [SKIP][69] ([i915#2920]) +1 similar issue
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4.html
- shard-iclb: NOTRUN -> [SKIP][70] ([i915#658])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-4.html
* igt@kms_psr2_sf@plane-move-sf-dmg-area-0:
- shard-apl: NOTRUN -> [SKIP][71] ([fdo#109271] / [i915#658])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl6/igt@kms_psr2_sf@plane-move-sf-dmg-area-0.html
* igt@kms_psr2_su@frontbuffer:
- shard-tglb: NOTRUN -> [SKIP][72] ([i915#1911])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_psr2_su@frontbuffer.html
- shard-iclb: NOTRUN -> [SKIP][73] ([fdo#109642] / [fdo#111068] / [i915#658])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_basic:
- shard-tglb: NOTRUN -> [FAIL][74] ([i915#132] / [i915#3467])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@kms_psr@psr2_basic.html
* igt@kms_psr@psr2_sprite_mmap_cpu:
- shard-iclb: [PASS][75] -> [SKIP][76] ([fdo#109441])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_psr@psr2_sprite_mmap_cpu.html
* igt@kms_psr@suspend:
- shard-skl: [PASS][77] -> [INCOMPLETE][78] ([i915#198])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl3/igt@kms_psr@suspend.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl6/igt@kms_psr@suspend.html
* igt@kms_writeback@writeback-fb-id:
- shard-kbl: NOTRUN -> [SKIP][79] ([fdo#109271] / [i915#2437])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl2/igt@kms_writeback@writeback-fb-id.html
* igt@kms_writeback@writeback-invalid-parameters:
- shard-tglb: NOTRUN -> [SKIP][80] ([i915#2437])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_writeback@writeback-invalid-parameters.html
- shard-iclb: NOTRUN -> [SKIP][81] ([i915#2437])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@kms_writeback@writeback-invalid-parameters.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-skl: NOTRUN -> [SKIP][82] ([fdo#109271] / [i915#2437])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl7/igt@kms_writeback@writeback-pixel-formats.html
* igt@prime_nv_test@nv_write_i915_gtt_mmap_read:
- shard-tglb: NOTRUN -> [SKIP][83] ([fdo#109291]) +1 similar issue
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@prime_nv_test@nv_write_i915_gtt_mmap_read.html
- shard-iclb: NOTRUN -> [SKIP][84] ([fdo#109291])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@prime_nv_test@nv_write_i915_gtt_mmap_read.html
* igt@sysfs_clients@fair-1:
- shard-apl: NOTRUN -> [SKIP][85] ([fdo#109271] / [i915#2994]) +2 similar issues
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl6/igt@sysfs_clients@fair-1.html
* igt@sysfs_clients@recycle:
- shard-skl: NOTRUN -> [SKIP][86] ([fdo#109271] / [i915#2994])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl7/igt@sysfs_clients@recycle.html
* igt@sysfs_clients@split-25:
- shard-tglb: NOTRUN -> [SKIP][87] ([i915#2994])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@sysfs_clients@split-25.html
- shard-iclb: NOTRUN -> [SKIP][88] ([i915#2994])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@sysfs_clients@split-25.html
#### Possible fixes ####
* igt@drm_mm@all@insert_range:
- shard-skl: [INCOMPLETE][89] ([i915#2485]) -> [PASS][90]
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl7/igt@drm_mm@all@insert_range.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl5/igt@drm_mm@all@insert_range.html
* igt@gem_ctx_persistence@smoketest:
- shard-apl: [FAIL][91] ([i915#2896]) -> [PASS][92]
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-apl1/igt@gem_ctx_persistence@smoketest.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl3/igt@gem_ctx_persistence@smoketest.html
* igt@gem_eio@in-flight-1us:
- shard-skl: [TIMEOUT][93] ([i915#3063]) -> [PASS][94]
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl6/igt@gem_eio@in-flight-1us.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl2/igt@gem_eio@in-flight-1us.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [TIMEOUT][95] ([i915#2369] / [i915#3063]) -> [PASS][96]
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-tglb2/igt@gem_eio@unwedge-stress.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: [FAIL][97] ([i915#2846]) -> [PASS][98]
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-kbl4/igt@gem_exec_fair@basic-deadline.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl2/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [FAIL][99] ([i915#2842]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb8/igt@gem_exec_fair@basic-none-share@rcs0.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb7/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][101] ([i915#2842]) -> [PASS][102] +1 similar issue
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-kbl1/igt@gem_exec_fair@basic-none@vcs0.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl1/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][103] ([i915#2842]) -> [PASS][104]
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk4/igt@gem_exec_fair@basic-pace-share@rcs0.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk4/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [SKIP][105] ([fdo#109271]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs0.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl1/igt@gem_exec_fair@basic-pace@vcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [SKIP][107] ([i915#2190]) -> [PASS][108]
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-tglb6/igt@gem_huc_copy@huc-copy.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb8/igt@gem_huc_copy@huc-copy.html
* igt@gem_mmap_gtt@big-copy-odd:
- shard-glk: [FAIL][109] ([i915#307]) -> [PASS][110] +1 similar issue
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk7/igt@gem_mmap_gtt@big-copy-odd.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk6/igt@gem_mmap_gtt@big-copy-odd.html
* igt@gem_mmap_gtt@cpuset-medium-copy-xy:
- shard-iclb: [FAIL][111] ([i915#2428]) -> [PASS][112] +1 similar issue
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb2/igt@gem_mmap_gtt@cpuset-medium-copy-xy.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@gem_mmap_gtt@cpuset-medium-copy-xy.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [DMESG-WARN][113] ([i915#1436] / [i915#716]) -> [PASS][114]
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk8/igt@gen9_exec_parse@allowed-all.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk7/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl: [INCOMPLETE][115] ([i915#151]) -> [PASS][116]
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl3/igt@i915_pm_rpm@system-suspend-execbuf.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl2/igt@i915_pm_rpm@system-suspend-execbuf.html
* igt@i915_suspend@debugfs-reader:
- shard-iclb: [INCOMPLETE][117] ([i915#1185]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb3/igt@i915_suspend@debugfs-reader.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb5/igt@i915_suspend@debugfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [DMESG-WARN][119] ([i915#180]) -> [PASS][120] +5 similar issues
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled:
- shard-skl: [FAIL][121] -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl4/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl7/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-ytiled.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:
- shard-glk: [FAIL][123] ([i915#79]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@plain-flip-ts-check@b-edp1:
- shard-skl: [FAIL][125] ([i915#2122]) -> [PASS][126]
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl4/igt@kms_flip@plain-flip-ts-check@b-edp1.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl3/igt@kms_flip@plain-flip-ts-check@b-edp1.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [FAIL][127] ([i915#1188]) -> [PASS][128]
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl1/igt@kms_hdr@bpc-switch-suspend.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl2/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
- shard-apl: [DMESG-WARN][129] ([i915#180]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes.html
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-tglb: [INCOMPLETE][131] -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-tglb5/igt@kms_plane_multiple@atomic-pipe-b-tiling-y.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb1/igt@kms_plane_multiple@atomic-pipe-b-tiling-y.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [SKIP][133] ([fdo#109441]) -> [PASS][134] +2 similar issues
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb5/igt@kms_psr@psr2_cursor_render.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
* igt@perf@polling-small-buf:
- shard-skl: [FAIL][135] ([i915#1722]) -> [PASS][136]
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-skl2/igt@perf@polling-small-buf.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-skl7/igt@perf@polling-small-buf.html
* igt@prime_vgem@sync@vecs0:
- shard-tglb: [INCOMPLETE][137] ([i915#409]) -> [PASS][138]
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-tglb3/igt@prime_vgem@sync@vecs0.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb3/igt@prime_vgem@sync@vecs0.html
#### Warnings ####
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][139] ([i915#588]) -> [SKIP][140] ([i915#658])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb1/igt@i915_pm_dc@dc3co-vpb-simulation.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][141] ([i915#2684]) -> [WARN][142] ([i915#1804] / [i915#2684]) +1 similar issue
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-iclb1/igt@i915_pm_rc6_residency@rc6-fence.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-iclb7/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_selftest@live@execlists:
- shard-tglb: [INCOMPLETE][143] ([i915#3462]) -> [DMESG-FAIL][144] ([i915#3462])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-tglb8/igt@i915_selftest@live@execlists.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-tglb6/igt@i915_selftest@live@execlists.html
* igt@kms_flip@flip-vs-suspend@a-dp1:
- shard-kbl: [INCOMPLETE][145] ([i915#155]) -> [DMESG-WARN][146] ([i915#180])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10187/shard-kbl2/igt@kms_flip@flip-vs-suspend@a-dp1.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/shard-kbl4/igt@kms_flip@flip-vs-suspend@a-dp1.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-1:
- shard-iclb: [SKIP][147]
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20298/index.html
[-- Attachment #1.2: Type: text/html, Size: 33691 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 08/13] drm/i915/guc: New CTB based communication
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
@ 2021-06-08 2:20 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 2:20 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Format of the CTB messages has changed:
> - support for multiple formats
> - message fence is now part of the header
> - reuse of unified HXG message formats
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
> .../gt/uc/abi/guc_communication_ctb_abi.h | 56 +++++
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++++++-----------
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
> 3 files changed, 135 insertions(+), 117 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index 127b256a662c..92660726c094 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
> } __packed;
> static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>
> +/**
> + * DOC: CTB Message
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:16 | **FENCE** - message identifier |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:12 | **FORMAT** - format of the CTB message |
> + * | | | - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | **RESERVED** |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | **NUM_DWORDS** - length of the CTB message (w/o header) |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | optional (depends on FORMAT) |
> + * +---+-------+ |
> + * |...| | |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_CTB_MSG_MIN_LEN 1u
> +#define GUC_CTB_MSG_MAX_LEN 256u
> +#define GUC_CTB_MSG_0_FENCE (0xffff << 16)
> +#define GUC_CTB_MSG_0_FORMAT (0xf << 12)
> +#define GUC_CTB_FORMAT_HXG 0u
> +#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
> +#define GUC_CTB_MSG_0_NUM_DWORDS (0xff << 0)
> +
> +/**
> + * DOC: CTB HXG Message
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:16 | FENCE |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | RESERVED = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+ | | |
> + * |...| | | Embedded `HXG Message`_ | |
> + * +---+-------+ | | |
> + * | n | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_CTB_HXG_MSG_MIN_LEN (GUC_CTB_MSG_MIN_LEN + GUC_HXG_MSG_MIN_LEN)
> +#define GUC_CTB_HXG_MSG_MAX_LEN GUC_CTB_MSG_MAX_LEN
> +
> /**
> * DOC: CTB based communication
> *
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 6a29be779cc9..729f29bc2a57 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
> }
> }
>
> -/**
> - * DOC: CTB Host to GuC request
> - *
> - * Format of the CTB Host to GuC request message is as follows::
> - *
> - * +------------+---------+---------+---------+---------+
> - * | msg[0] | [1] | [2] | ... | [n-1] |
> - * +------------+---------+---------+---------+---------+
> - * | MESSAGE | MESSAGE PAYLOAD |
> - * + HEADER +---------+---------+---------+---------+
> - * | | 0 | 1 | ... | n |
> - * +============+=========+=========+=========+=========+
> - * | len >= 1 | FENCE | request specific data |
> - * +------+-----+---------+---------+---------+---------+
> - *
> - * ^-----------------len-------------------^
> - */
> -
> static int ct_write(struct intel_guc_ct *ct,
> const u32 *action,
> u32 len /* in dwords */,
> @@ -395,6 +377,7 @@ static int ct_write(struct intel_guc_ct *ct,
> u32 size = ctb->size;
> u32 used;
> u32 header;
> + u32 hxg;
> u32 *cmds = ctb->cmds;
> unsigned int i;
>
> @@ -425,22 +408,24 @@ static int ct_write(struct intel_guc_ct *ct,
> return -ENOSPC;
Doesn't the free space math up here need updating, since now we have an
extra header dword?
>
> /*
> - * Write the message. The format is the following:
> - * DW0: header (including action code)
> - * DW1: fence
> - * DW2+: action data
> + * dw0: CT header (including fence)
> + * dw1: HXG header
maybe better as:
* dw1+: HXG message
> */
> - header = (len << GUC_CT_MSG_LEN_SHIFT) |
> - GUC_CT_MSG_SEND_STATUS |
> - (action[0] << GUC_CT_MSG_ACTION_SHIFT);
> + header = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
> + FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> + FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> +
> + hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
Do we have a case where we might want to use a different type? e.g. a
response to a request from GuC?
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
See macro suggestion for the hxg header in previous patch review.
>
> - CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
> - 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
> + CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
> + tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
>
> cmds[tail] = header;
> tail = (tail + 1) % size;
>
> - cmds[tail] = fence;
> + cmds[tail] = hxg;
> tail = (tail + 1) % size;
>
> for (i = 1; i < len; i++) {
> @@ -598,21 +583,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
> return ret;
> }
>
> -static inline unsigned int ct_header_get_len(u32 header)
> -{
> - return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
> -}
> -
> -static inline unsigned int ct_header_get_action(u32 header)
> -{
> - return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
> -}
> -
> -static inline bool ct_header_is_response(u32 header)
> -{
> - return !!(header & GUC_CT_MSG_IS_RESPONSE);
> -}
> -
> static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
> {
> struct ct_incoming_msg *msg;
> @@ -675,7 +645,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> head = (head + 1) % size;
>
> /* message len with header */
> - len = ct_header_get_len(header) + 1;
> + len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, header) + GUC_CTB_MSG_MIN_LEN;
> if (unlikely(len > (u32)available)) {
> CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
> 4, &header,
> @@ -718,55 +688,24 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> return -EPIPE;
> }
>
> -/**
> - * DOC: CTB GuC to Host response
> - *
> - * Format of the CTB GuC to Host response message is as follows::
> - *
> - * +------------+---------+---------+---------+---------+---------+
> - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> - * +------------+---------+---------+---------+---------+---------+
> - * | MESSAGE | MESSAGE PAYLOAD |
> - * + HEADER +---------+---------+---------+---------+---------+
> - * | | 0 | 1 | 2 | ... | n |
> - * +============+=========+=========+=========+=========+=========+
> - * | len >= 2 | FENCE | STATUS | response specific data |
> - * +------+-----+---------+---------+---------+---------+---------+
> - *
> - * ^-----------------------len-----------------------^
> - */
> -
> static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *response)
> {
> - u32 header = response->msg[0];
> - u32 len = ct_header_get_len(header);
> - u32 fence;
> - u32 status;
> - u32 datalen;
> + u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
> + u32 fence = FIELD_GET(GUC_CTB_MSG_0_FENCE, response->msg[0]);
> + const u32 *hxg = &response->msg[GUC_CTB_MSG_MIN_LEN];
IMO it'd be better to just save the hxg in the msg field. We can save
the fence as an extra field in the ct_incoming_msg. That way we won't
have to convert from CTB to HXG in multiple places in the code (I count
4 total in this patch).
Daniele
> + const u32 *data = &hxg[GUC_HXG_MSG_MIN_LEN];
> + u32 datalen = len - GUC_HXG_MSG_MIN_LEN;
> struct ct_request *req;
> unsigned long flags;
> bool found = false;
> int err = 0;
>
> - GEM_BUG_ON(!ct_header_is_response(header));
> + GEM_BUG_ON(len < GUC_HXG_MSG_MIN_LEN);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]) != GUC_HXG_ORIGIN_GUC);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_SUCCESS &&
> + FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_FAILURE);
>
> - /* Response payload shall at least include fence and status */
> - if (unlikely(len < 2)) {
> - CT_ERROR(ct, "Corrupted response (len %u)\n", len);
> - return -EPROTO;
> - }
> -
> - fence = response->msg[1];
> - status = response->msg[2];
> - datalen = len - 2;
> -
> - /* Format of the status dword follows HXG header */
> - if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
> - CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
> - return -EPROTO;
> - }
> -
> - CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
> + CT_DEBUG(ct, "response fence %u status %#x\n", fence, hxg[0]);
>
> spin_lock_irqsave(&ct->requests.lock, flags);
> list_for_each_entry(req, &ct->requests.pending, link) {
> @@ -782,9 +721,9 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> err = -EMSGSIZE;
> }
> if (datalen)
> - memcpy(req->response_buf, response->msg + 3, 4 * datalen);
> + memcpy(req->response_buf, data, 4 * datalen);
> req->response_len = datalen;
> - WRITE_ONCE(req->status, status);
> + WRITE_ONCE(req->status, hxg[0]);
> found = true;
> break;
> }
> @@ -805,14 +744,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> static int ct_process_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> {
> struct intel_guc *guc = ct_to_guc(ct);
> - u32 header, action, len;
> + const u32 *hxg;
> const u32 *payload;
> + u32 hxg_len, action, len;
> int ret;
>
> - header = request->msg[0];
> - payload = &request->msg[1];
> - action = ct_header_get_action(header);
> - len = ct_header_get_len(header);
> + hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> + hxg_len = request->size - GUC_CTB_MSG_MIN_LEN;
> + payload = &hxg[GUC_HXG_MSG_MIN_LEN];
> + action = FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION, hxg[0]);
> + len = hxg_len - GUC_HXG_MSG_MIN_LEN;
>
> CT_DEBUG(ct, "request %x %*ph\n", action, 4 * len, payload);
>
> @@ -874,29 +815,12 @@ static void ct_incoming_request_worker_func(struct work_struct *w)
> queue_work(system_unbound_wq, &ct->requests.worker);
> }
>
> -/**
> - * DOC: CTB GuC to Host request
> - *
> - * Format of the CTB GuC to Host request message is as follows::
> - *
> - * +------------+---------+---------+---------+---------+---------+
> - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> - * +------------+---------+---------+---------+---------+---------+
> - * | MESSAGE | MESSAGE PAYLOAD |
> - * + HEADER +---------+---------+---------+---------+---------+
> - * | | 0 | 1 | 2 | ... | n |
> - * +============+=========+=========+=========+=========+=========+
> - * | len | request specific data |
> - * +------+-----+---------+---------+---------+---------+---------+
> - *
> - * ^-----------------------len-----------------------^
> - */
> -
> -static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> +static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> {
> + const u32 *hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> unsigned long flags;
>
> - GEM_BUG_ON(ct_header_is_response(request->msg[0]));
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_EVENT);
>
> spin_lock_irqsave(&ct->requests.lock, flags);
> list_add_tail(&request->link, &ct->requests.incoming);
> @@ -906,15 +830,53 @@ static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *re
> return 0;
> }
>
> -static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> +static int ct_handle_hxg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> {
> - u32 header = msg->msg[0];
> + u32 origin, type;
> + u32 *hxg;
> int err;
>
> - if (ct_header_is_response(header))
> + if (unlikely(msg->size < GUC_CTB_HXG_MSG_MIN_LEN))
> + return -EBADMSG;
> +
> + hxg = &msg->msg[GUC_CTB_MSG_MIN_LEN];
> +
> + origin = FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]);
> + if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
> + err = -EPROTO;
> + goto failed;
> + }
> +
> + type = FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]);
> + switch (type) {
> + case GUC_HXG_TYPE_EVENT:
> + err = ct_handle_event(ct, msg);
> + break;
> + case GUC_HXG_TYPE_RESPONSE_SUCCESS:
> + case GUC_HXG_TYPE_RESPONSE_FAILURE:
> err = ct_handle_response(ct, msg);
> + break;
> + default:
> + err = -EOPNOTSUPP;
> + }
> +
> + if (unlikely(err)) {
> +failed:
> + CT_ERROR(ct, "Failed to handle HXG message (%pe) %*ph\n",
> + ERR_PTR(err), 4 * GUC_HXG_MSG_MIN_LEN, hxg);
> + }
> + return err;
> +}
> +
> +static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> +{
> + u32 format = FIELD_GET(GUC_CTB_MSG_0_FORMAT, msg->msg[0]);
> + int err;
> +
> + if (format == GUC_CTB_FORMAT_HXG)
> + err = ct_handle_hxg(ct, msg);
> else
> - err = ct_handle_request(ct, msg);
> + err = -EOPNOTSUPP;
>
> if (unlikely(err)) {
> CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> index 905202caaad3..1ae2dde6db93 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> @@ -61,7 +61,7 @@ struct intel_guc_ct {
> struct tasklet_struct receive_tasklet;
>
> struct {
> - u32 last_fence; /* last fence used to send request */
> + u16 last_fence; /* last fence used to send request */
>
> spinlock_t lock; /* protects pending requests list */
> struct list_head pending; /* requests waiting for response */
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 08/13] drm/i915/guc: New CTB based communication
@ 2021-06-08 2:20 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-08 2:20 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 11:03 AM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> Format of the CTB messages has changed:
> - support for multiple formats
> - message fence is now part of the header
> - reuse of unified HXG message formats
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
> .../gt/uc/abi/guc_communication_ctb_abi.h | 56 +++++
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++++++-----------
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
> 3 files changed, 135 insertions(+), 117 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index 127b256a662c..92660726c094 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
> } __packed;
> static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>
> +/**
> + * DOC: CTB Message
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:16 | **FENCE** - message identifier |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:12 | **FORMAT** - format of the CTB message |
> + * | | | - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | **RESERVED** |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | **NUM_DWORDS** - length of the CTB message (w/o header) |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | optional (depends on FORMAT) |
> + * +---+-------+ |
> + * |...| | |
> + * +---+-------+ |
> + * | n | 31:0 | |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_CTB_MSG_MIN_LEN 1u
> +#define GUC_CTB_MSG_MAX_LEN 256u
> +#define GUC_CTB_MSG_0_FENCE (0xffff << 16)
> +#define GUC_CTB_MSG_0_FORMAT (0xf << 12)
> +#define GUC_CTB_FORMAT_HXG 0u
> +#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
> +#define GUC_CTB_MSG_0_NUM_DWORDS (0xff << 0)
> +
> +/**
> + * DOC: CTB HXG Message
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:16 | FENCE |
> + * | +-------+--------------------------------------------------------------+
> + * | | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 11:8 | RESERVED = MBZ |
> + * | +-------+--------------------------------------------------------------+
> + * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message |
> + * +---+-------+--------------------------------------------------------------+
> + * | 1 | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+ | | |
> + * |...| | | Embedded `HXG Message`_ | |
> + * +---+-------+ | | |
> + * | n | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+--------------------------------------------------------------+
> + */
> +
> +#define GUC_CTB_HXG_MSG_MIN_LEN (GUC_CTB_MSG_MIN_LEN + GUC_HXG_MSG_MIN_LEN)
> +#define GUC_CTB_HXG_MSG_MAX_LEN GUC_CTB_MSG_MAX_LEN
> +
> /**
> * DOC: CTB based communication
> *
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 6a29be779cc9..729f29bc2a57 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
> }
> }
>
> -/**
> - * DOC: CTB Host to GuC request
> - *
> - * Format of the CTB Host to GuC request message is as follows::
> - *
> - * +------------+---------+---------+---------+---------+
> - * | msg[0] | [1] | [2] | ... | [n-1] |
> - * +------------+---------+---------+---------+---------+
> - * | MESSAGE | MESSAGE PAYLOAD |
> - * + HEADER +---------+---------+---------+---------+
> - * | | 0 | 1 | ... | n |
> - * +============+=========+=========+=========+=========+
> - * | len >= 1 | FENCE | request specific data |
> - * +------+-----+---------+---------+---------+---------+
> - *
> - * ^-----------------len-------------------^
> - */
> -
> static int ct_write(struct intel_guc_ct *ct,
> const u32 *action,
> u32 len /* in dwords */,
> @@ -395,6 +377,7 @@ static int ct_write(struct intel_guc_ct *ct,
> u32 size = ctb->size;
> u32 used;
> u32 header;
> + u32 hxg;
> u32 *cmds = ctb->cmds;
> unsigned int i;
>
> @@ -425,22 +408,24 @@ static int ct_write(struct intel_guc_ct *ct,
> return -ENOSPC;
Doesn't the free space math up here need updating, since now we have an
extra header dword?
>
> /*
> - * Write the message. The format is the following:
> - * DW0: header (including action code)
> - * DW1: fence
> - * DW2+: action data
> + * dw0: CT header (including fence)
> + * dw1: HXG header
maybe better as:
* dw1+: HXG message
> */
> - header = (len << GUC_CT_MSG_LEN_SHIFT) |
> - GUC_CT_MSG_SEND_STATUS |
> - (action[0] << GUC_CT_MSG_ACTION_SHIFT);
> + header = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
> + FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> + FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> +
> + hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
Do we have a case where we might want to use a different type? e.g. a
response to a request from GuC?
> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
See macro suggestion for the hxg header in previous patch review.
>
> - CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
> - 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
> + CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
> + tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
>
> cmds[tail] = header;
> tail = (tail + 1) % size;
>
> - cmds[tail] = fence;
> + cmds[tail] = hxg;
> tail = (tail + 1) % size;
>
> for (i = 1; i < len; i++) {
> @@ -598,21 +583,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
> return ret;
> }
>
> -static inline unsigned int ct_header_get_len(u32 header)
> -{
> - return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
> -}
> -
> -static inline unsigned int ct_header_get_action(u32 header)
> -{
> - return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
> -}
> -
> -static inline bool ct_header_is_response(u32 header)
> -{
> - return !!(header & GUC_CT_MSG_IS_RESPONSE);
> -}
> -
> static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
> {
> struct ct_incoming_msg *msg;
> @@ -675,7 +645,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> head = (head + 1) % size;
>
> /* message len with header */
> - len = ct_header_get_len(header) + 1;
> + len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, header) + GUC_CTB_MSG_MIN_LEN;
> if (unlikely(len > (u32)available)) {
> CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
> 4, &header,
> @@ -718,55 +688,24 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> return -EPIPE;
> }
>
> -/**
> - * DOC: CTB GuC to Host response
> - *
> - * Format of the CTB GuC to Host response message is as follows::
> - *
> - * +------------+---------+---------+---------+---------+---------+
> - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> - * +------------+---------+---------+---------+---------+---------+
> - * | MESSAGE | MESSAGE PAYLOAD |
> - * + HEADER +---------+---------+---------+---------+---------+
> - * | | 0 | 1 | 2 | ... | n |
> - * +============+=========+=========+=========+=========+=========+
> - * | len >= 2 | FENCE | STATUS | response specific data |
> - * +------+-----+---------+---------+---------+---------+---------+
> - *
> - * ^-----------------------len-----------------------^
> - */
> -
> static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *response)
> {
> - u32 header = response->msg[0];
> - u32 len = ct_header_get_len(header);
> - u32 fence;
> - u32 status;
> - u32 datalen;
> + u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
> + u32 fence = FIELD_GET(GUC_CTB_MSG_0_FENCE, response->msg[0]);
> + const u32 *hxg = &response->msg[GUC_CTB_MSG_MIN_LEN];
IMO it'd be better to just save the hxg in the msg field. We can save
the fence as an extra field in the ct_incoming_msg. That way we won't
have to convert from CTB to HXG in multiple places in the code (I count
4 total in this patch).
Daniele
> + const u32 *data = &hxg[GUC_HXG_MSG_MIN_LEN];
> + u32 datalen = len - GUC_HXG_MSG_MIN_LEN;
> struct ct_request *req;
> unsigned long flags;
> bool found = false;
> int err = 0;
>
> - GEM_BUG_ON(!ct_header_is_response(header));
> + GEM_BUG_ON(len < GUC_HXG_MSG_MIN_LEN);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]) != GUC_HXG_ORIGIN_GUC);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_SUCCESS &&
> + FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_FAILURE);
>
> - /* Response payload shall at least include fence and status */
> - if (unlikely(len < 2)) {
> - CT_ERROR(ct, "Corrupted response (len %u)\n", len);
> - return -EPROTO;
> - }
> -
> - fence = response->msg[1];
> - status = response->msg[2];
> - datalen = len - 2;
> -
> - /* Format of the status dword follows HXG header */
> - if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
> - CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
> - return -EPROTO;
> - }
> -
> - CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
> + CT_DEBUG(ct, "response fence %u status %#x\n", fence, hxg[0]);
>
> spin_lock_irqsave(&ct->requests.lock, flags);
> list_for_each_entry(req, &ct->requests.pending, link) {
> @@ -782,9 +721,9 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> err = -EMSGSIZE;
> }
> if (datalen)
> - memcpy(req->response_buf, response->msg + 3, 4 * datalen);
> + memcpy(req->response_buf, data, 4 * datalen);
> req->response_len = datalen;
> - WRITE_ONCE(req->status, status);
> + WRITE_ONCE(req->status, hxg[0]);
> found = true;
> break;
> }
> @@ -805,14 +744,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> static int ct_process_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> {
> struct intel_guc *guc = ct_to_guc(ct);
> - u32 header, action, len;
> + const u32 *hxg;
> const u32 *payload;
> + u32 hxg_len, action, len;
> int ret;
>
> - header = request->msg[0];
> - payload = &request->msg[1];
> - action = ct_header_get_action(header);
> - len = ct_header_get_len(header);
> + hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> + hxg_len = request->size - GUC_CTB_MSG_MIN_LEN;
> + payload = &hxg[GUC_HXG_MSG_MIN_LEN];
> + action = FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION, hxg[0]);
> + len = hxg_len - GUC_HXG_MSG_MIN_LEN;
>
> CT_DEBUG(ct, "request %x %*ph\n", action, 4 * len, payload);
>
> @@ -874,29 +815,12 @@ static void ct_incoming_request_worker_func(struct work_struct *w)
> queue_work(system_unbound_wq, &ct->requests.worker);
> }
>
> -/**
> - * DOC: CTB GuC to Host request
> - *
> - * Format of the CTB GuC to Host request message is as follows::
> - *
> - * +------------+---------+---------+---------+---------+---------+
> - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> - * +------------+---------+---------+---------+---------+---------+
> - * | MESSAGE | MESSAGE PAYLOAD |
> - * + HEADER +---------+---------+---------+---------+---------+
> - * | | 0 | 1 | 2 | ... | n |
> - * +============+=========+=========+=========+=========+=========+
> - * | len | request specific data |
> - * +------+-----+---------+---------+---------+---------+---------+
> - *
> - * ^-----------------------len-----------------------^
> - */
> -
> -static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> +static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> {
> + const u32 *hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> unsigned long flags;
>
> - GEM_BUG_ON(ct_header_is_response(request->msg[0]));
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_EVENT);
>
> spin_lock_irqsave(&ct->requests.lock, flags);
> list_add_tail(&request->link, &ct->requests.incoming);
> @@ -906,15 +830,53 @@ static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *re
> return 0;
> }
>
> -static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> +static int ct_handle_hxg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> {
> - u32 header = msg->msg[0];
> + u32 origin, type;
> + u32 *hxg;
> int err;
>
> - if (ct_header_is_response(header))
> + if (unlikely(msg->size < GUC_CTB_HXG_MSG_MIN_LEN))
> + return -EBADMSG;
> +
> + hxg = &msg->msg[GUC_CTB_MSG_MIN_LEN];
> +
> + origin = FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]);
> + if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
> + err = -EPROTO;
> + goto failed;
> + }
> +
> + type = FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]);
> + switch (type) {
> + case GUC_HXG_TYPE_EVENT:
> + err = ct_handle_event(ct, msg);
> + break;
> + case GUC_HXG_TYPE_RESPONSE_SUCCESS:
> + case GUC_HXG_TYPE_RESPONSE_FAILURE:
> err = ct_handle_response(ct, msg);
> + break;
> + default:
> + err = -EOPNOTSUPP;
> + }
> +
> + if (unlikely(err)) {
> +failed:
> + CT_ERROR(ct, "Failed to handle HXG message (%pe) %*ph\n",
> + ERR_PTR(err), 4 * GUC_HXG_MSG_MIN_LEN, hxg);
> + }
> + return err;
> +}
> +
> +static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> +{
> + u32 format = FIELD_GET(GUC_CTB_MSG_0_FORMAT, msg->msg[0]);
> + int err;
> +
> + if (format == GUC_CTB_FORMAT_HXG)
> + err = ct_handle_hxg(ct, msg);
> else
> - err = ct_handle_request(ct, msg);
> + err = -EOPNOTSUPP;
>
> if (unlikely(err)) {
> CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> index 905202caaad3..1ae2dde6db93 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> @@ -61,7 +61,7 @@ struct intel_guc_ct {
> struct tasklet_struct receive_tasklet;
>
> struct {
> - u32 last_fence; /* last fence used to send request */
> + u16 last_fence; /* last fence used to send request */
>
> spinlock_t lock; /* protects pending requests list */
> struct list_head pending; /* requests waiting for response */
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
2021-06-07 22:46 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-08 7:59 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-08 7:59 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
Cc: john.c.harrison
On 08.06.2021 00:46, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> New GuC firmware will unify format of MMIO and CTB H2G messages.
>> Introduce their definitions now to allow gradual transition of
>> our code to match new changes.
>>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++++++++++++++++++
>> 1 file changed, 213 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> index 775e21f3058c..29ac823acd4c 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> @@ -6,6 +6,219 @@
>> #ifndef _ABI_GUC_MESSAGES_ABI_H
>> #define _ABI_GUC_MESSAGES_ABI_H
>> +/**
>> + * DOC: HXG Message
>> + *
>> + * All messages exchanged with GuC are defined using 32 bit dwords.
>> + * First dword is treated as a message header. Remaining dwords are
>> optional.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | |
>> | |
>> + * | 0 | 31 | **ORIGIN** - originator of the
>> message |
>> + * | | | - _`GUC_HXG_ORIGIN_HOST` =
>> 0 |
>> + * | | | - _`GUC_HXG_ORIGIN_GUC` =
>> 1 |
>> + * | |
>> | |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | **TYPE** - message
>> type |
>> + * | | | - _`GUC_HXG_TYPE_REQUEST` =
>> 0 |
>> + * | | | - _`GUC_HXG_TYPE_EVENT` =
>> 1 |
>> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` =
>> 3 |
>> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` =
>> 5 |
>> + * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` =
>> 6 |
>> + * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` =
>> 7 |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **AUX** - auxiliary data (depends on
>> TYPE) |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **PAYLOAD** - optional payload (depends on
>> TYPE) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_MSG_MIN_LEN 1u
>> +#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
>
> Any reason not to use BIT(31) here? same below with other bits and with
> GENMASK for masks.
initial goal was to have all ABI definitions auto-generated from GuC
spec files, using just pure C syntax to avoid any dependencies.
we can try to wrap some definitions into generic helpers like
HXG_MASK(...) and then remap them to our REG_GENMASK but didn't feel
this is super important
>
>> +#define GUC_HXG_ORIGIN_HOST 0u
>> +#define GUC_HXG_ORIGIN_GUC 1u
>> +#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
>
> I think the masks could use a _MASK postfix
all field definitions are masks, so it would be redundant IMHO
note that previously there were both _MASK and _SHIFT definitions and
then it was required to have extra suffix
>
>> +#define GUC_HXG_TYPE_REQUEST 0u
>> +#define GUC_HXG_TYPE_EVENT 1u
>> +#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
>> +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u
>> +#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
>> +#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
>> +#define GUC_HXG_MSG_0_AUX (0xfffffff << 0)
>> +#define GUC_HXG_MSG_n_PAYLOAD (0xffffffff << 0)
>
> Is a mask that covers the whole u32 really needed? Even for future
> proofing, I find it very unlikely that we'll ever have a case where the
> payload is not an entire dword.
maybe not strictly required but IIRC allows to have consistent
definitions for derived messages
>
>> +
>> +/**
>> + * DOC: HXG Request
>> + *
>> + * The `HXG Request`_ message should be used to initiate synchronous
>> activity
>> + * for which confirmation or return data is expected.
>> + *
>> + * The recipient of this message shall use `HXG Response`_, `HXG
>> Failure`_
>> + * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
>> + * message as a intermediate reply.
>> + *
>> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | **DATA0** - request data (depends on
>> ACTION) |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | **ACTION** - requested action
>> code |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **DATAn** - optional data (depends on
>> ACTION) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_REQUEST_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_REQUEST_MSG_0_DATA0 (0xfff << 16)
>> +#define GUC_HXG_REQUEST_MSG_0_ACTION (0xffff << 0)
>> +#define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
>> +
>> +/**
>> + * DOC: HXG Event
>> + *
>> + * The `HXG Event`_ message should be used to initiate asynchronous
>> activity
>> + * that does not involves immediate confirmation nor data.
>> + *
>> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_EVENT_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | **DATA0** - event data (depends on
>> ACTION) |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | **ACTION** - event action
>> code |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **DATAn** - optional event data (depends on
>> ACTION) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_EVENT_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_EVENT_MSG_0_DATA0 (0xfff << 16)
>> +#define GUC_HXG_EVENT_MSG_0_ACTION (0xffff << 0)
>> +#define GUC_HXG_EVENT_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
>> +
>> +/**
>> + * DOC: HXG Busy
>> + *
>> + * The `HXG Busy`_ message may be used to acknowledge reception of
>> the `HXG Request`_
>> + * message if the recipient expects that it processing will be longer
>> than default
>> + * timeout.
>> + *
>> + * The @COUNTER field may be used as a progress indicator.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_NO_RESPONSE_BUSY_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **COUNTER** - progress
>> indicator |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_BUSY_MSG_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_BUSY_MSG_0_COUNTER GUC_HXG_MSG_0_AUX
>> +
>> +/**
>> + * DOC: HXG Retry
>> + *
>> + * The `HXG Retry`_ message should be used by recipient to indicate
>> that the
>> + * `HXG Request`_ message was dropped and it should be resent again.
>> + *
>> + * The @REASON field may be used to provide additional information.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_NO_RESPONSE_RETRY_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **REASON** - reason for
>> retry |
>> + * | | | - _`GUC_HXG_RETRY_REASON_UNSPECIFIED` =
>> 0 |
>
> AFAICS in the specs for 62.0.0 this field is actually a MBZ. Where does
> the "reason" classification come from?
some spec revision had these bits defined as "MBZ or debug data" and
this debug data was understood as "REASON", in same fashion as "HINT" in
FAILURE_RESPONSE message.
note that UNSPECIFIED(0) still matches MBZ(0)
>
> Apart from this, all the defines match the specs.
>
> Daniele
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_RETRY_MSG_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_RETRY_MSG_0_REASON GUC_HXG_MSG_0_AUX
>> +#define GUC_HXG_RETRY_REASON_UNSPECIFIED 0u
>> +
>> +/**
>> + * DOC: HXG Failure
>> + *
>> + * The `HXG Failure`_ message shall be used as a reply to the `HXG
>> Request`_
>> + * message that could not be processed due to an error.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_FAILURE_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | **HINT** - additional error
>> hint |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | **ERROR** - error/result
>> code |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_FAILURE_MSG_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_FAILURE_MSG_0_HINT (0xfff << 16)
>> +#define GUC_HXG_FAILURE_MSG_0_ERROR (0xffff << 0)
>> +
>> +/**
>> + * DOC: HXG Response
>> + *
>> + * The `HXG Response`_ message shall be used as a reply to the `HXG
>> Request`_
>> + * message that was successfully processed without an error.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **DATA0** - data (depends on ACTION from `HXG
>> Request`_) |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **DATAn** - data (depends on ACTION from `HXG
>> Request`_) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_RESPONSE_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_RESPONSE_MSG_0_DATA0 GUC_HXG_MSG_0_AUX
>> +#define GUC_HXG_RESPONSE_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
>> +
>> +/* deprecated */
>> #define INTEL_GUC_MSG_TYPE_SHIFT 28
>> #define INTEL_GUC_MSG_TYPE_MASK (0xF <<
>> INTEL_GUC_MSG_TYPE_SHIFT)
>> #define INTEL_GUC_MSG_DATA_SHIFT 16
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
@ 2021-06-08 7:59 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-08 7:59 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
On 08.06.2021 00:46, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> New GuC firmware will unify format of MMIO and CTB H2G messages.
>> Introduce their definitions now to allow gradual transition of
>> our code to match new changes.
>>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Michał Winiarski <michal.winiarski@intel.com>
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++++++++++++++++++
>> 1 file changed, 213 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> index 775e21f3058c..29ac823acd4c 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
>> @@ -6,6 +6,219 @@
>> #ifndef _ABI_GUC_MESSAGES_ABI_H
>> #define _ABI_GUC_MESSAGES_ABI_H
>> +/**
>> + * DOC: HXG Message
>> + *
>> + * All messages exchanged with GuC are defined using 32 bit dwords.
>> + * First dword is treated as a message header. Remaining dwords are
>> optional.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | |
>> | |
>> + * | 0 | 31 | **ORIGIN** - originator of the
>> message |
>> + * | | | - _`GUC_HXG_ORIGIN_HOST` =
>> 0 |
>> + * | | | - _`GUC_HXG_ORIGIN_GUC` =
>> 1 |
>> + * | |
>> | |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | **TYPE** - message
>> type |
>> + * | | | - _`GUC_HXG_TYPE_REQUEST` =
>> 0 |
>> + * | | | - _`GUC_HXG_TYPE_EVENT` =
>> 1 |
>> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` =
>> 3 |
>> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` =
>> 5 |
>> + * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` =
>> 6 |
>> + * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` =
>> 7 |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **AUX** - auxiliary data (depends on
>> TYPE) |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **PAYLOAD** - optional payload (depends on
>> TYPE) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_MSG_MIN_LEN 1u
>> +#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
>
> Any reason not to use BIT(31) here? same below with other bits and with
> GENMASK for masks.
initial goal was to have all ABI definitions auto-generated from GuC
spec files, using just pure C syntax to avoid any dependencies.
we can try to wrap some definitions into generic helpers like
HXG_MASK(...) and then remap them to our REG_GENMASK but didn't feel
this is super important
>
>> +#define GUC_HXG_ORIGIN_HOST 0u
>> +#define GUC_HXG_ORIGIN_GUC 1u
>> +#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
>
> I think the masks could use a _MASK postfix
all field definitions are masks, so it would be redundant IMHO
note that previously there were both _MASK and _SHIFT definitions and
then it was required to have extra suffix
>
>> +#define GUC_HXG_TYPE_REQUEST 0u
>> +#define GUC_HXG_TYPE_EVENT 1u
>> +#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
>> +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u
>> +#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
>> +#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
>> +#define GUC_HXG_MSG_0_AUX (0xfffffff << 0)
>> +#define GUC_HXG_MSG_n_PAYLOAD (0xffffffff << 0)
>
> Is a mask that covers the whole u32 really needed? Even for future
> proofing, I find it very unlikely that we'll ever have a case where the
> payload is not an entire dword.
maybe not strictly required but IIRC allows to have consistent
definitions for derived messages
>
>> +
>> +/**
>> + * DOC: HXG Request
>> + *
>> + * The `HXG Request`_ message should be used to initiate synchronous
>> activity
>> + * for which confirmation or return data is expected.
>> + *
>> + * The recipient of this message shall use `HXG Response`_, `HXG
>> Failure`_
>> + * or `HXG Retry`_ message as a definite reply, and may use `HXG Busy`_
>> + * message as a intermediate reply.
>> + *
>> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | **DATA0** - request data (depends on
>> ACTION) |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | **ACTION** - requested action
>> code |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **DATAn** - optional data (depends on
>> ACTION) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_REQUEST_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_REQUEST_MSG_0_DATA0 (0xfff << 16)
>> +#define GUC_HXG_REQUEST_MSG_0_ACTION (0xffff << 0)
>> +#define GUC_HXG_REQUEST_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
>> +
>> +/**
>> + * DOC: HXG Event
>> + *
>> + * The `HXG Event`_ message should be used to initiate asynchronous
>> activity
>> + * that does not involves immediate confirmation nor data.
>> + *
>> + * Format of @DATA0 and all @DATAn fields depends on the @ACTION code.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_EVENT_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | **DATA0** - event data (depends on
>> ACTION) |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | **ACTION** - event action
>> code |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **DATAn** - optional event data (depends on
>> ACTION) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_EVENT_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_EVENT_MSG_0_DATA0 (0xfff << 16)
>> +#define GUC_HXG_EVENT_MSG_0_ACTION (0xffff << 0)
>> +#define GUC_HXG_EVENT_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
>> +
>> +/**
>> + * DOC: HXG Busy
>> + *
>> + * The `HXG Busy`_ message may be used to acknowledge reception of
>> the `HXG Request`_
>> + * message if the recipient expects that it processing will be longer
>> than default
>> + * timeout.
>> + *
>> + * The @COUNTER field may be used as a progress indicator.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_NO_RESPONSE_BUSY_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **COUNTER** - progress
>> indicator |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_BUSY_MSG_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_BUSY_MSG_0_COUNTER GUC_HXG_MSG_0_AUX
>> +
>> +/**
>> + * DOC: HXG Retry
>> + *
>> + * The `HXG Retry`_ message should be used by recipient to indicate
>> that the
>> + * `HXG Request`_ message was dropped and it should be resent again.
>> + *
>> + * The @REASON field may be used to provide additional information.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_NO_RESPONSE_RETRY_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **REASON** - reason for
>> retry |
>> + * | | | - _`GUC_HXG_RETRY_REASON_UNSPECIFIED` =
>> 0 |
>
> AFAICS in the specs for 62.0.0 this field is actually a MBZ. Where does
> the "reason" classification come from?
some spec revision had these bits defined as "MBZ or debug data" and
this debug data was understood as "REASON", in same fashion as "HINT" in
FAILURE_RESPONSE message.
note that UNSPECIFIED(0) still matches MBZ(0)
>
> Apart from this, all the defines match the specs.
>
> Daniele
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_RETRY_MSG_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_RETRY_MSG_0_REASON GUC_HXG_MSG_0_AUX
>> +#define GUC_HXG_RETRY_REASON_UNSPECIFIED 0u
>> +
>> +/**
>> + * DOC: HXG Failure
>> + *
>> + * The `HXG Failure`_ message shall be used as a reply to the `HXG
>> Request`_
>> + * message that could not be processed due to an error.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_FAILURE_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | **HINT** - additional error
>> hint |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | **ERROR** - error/result
>> code |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_FAILURE_MSG_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_FAILURE_MSG_0_HINT (0xfff << 16)
>> +#define GUC_HXG_FAILURE_MSG_0_ERROR (0xffff << 0)
>> +
>> +/**
>> + * DOC: HXG Response
>> + *
>> + * The `HXG Response`_ message shall be used as a reply to the `HXG
>> Request`_
>> + * message that was successfully processed without an error.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 |
>> ORIGIN |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | **DATA0** - data (depends on ACTION from `HXG
>> Request`_) |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0
>> | |
>> + *
>> +---+-------+
>> |
>> + * |...| | **DATAn** - data (depends on ACTION from `HXG
>> Request`_) |
>> + *
>> +---+-------+
>> |
>> + * | n | 31:0
>> | |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +#define GUC_HXG_RESPONSE_MSG_MIN_LEN GUC_HXG_MSG_MIN_LEN
>> +#define GUC_HXG_RESPONSE_MSG_0_DATA0 GUC_HXG_MSG_0_AUX
>> +#define GUC_HXG_RESPONSE_MSG_n_DATAn GUC_HXG_MSG_n_PAYLOAD
>> +
>> +/* deprecated */
>> #define INTEL_GUC_MSG_TYPE_SHIFT 28
>> #define INTEL_GUC_MSG_TYPE_MASK (0xF <<
>> INTEL_GUC_MSG_TYPE_SHIFT)
>> #define INTEL_GUC_MSG_DATA_SHIFT 16
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 02/13] drm/i915/guc: Update MMIO based communication
2021-06-07 23:06 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-08 8:15 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-08 8:15 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
Cc: john.c.harrison
On 08.06.2021 01:06, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> The MMIO based Host-to-GuC communication protocol has been
>> updated to use unified HXG messages.
>>
>> Update our intel_guc_send_mmio() function by correctly handle
>> BUSY, RETRY and FAILURE replies. Also update our documentation.
>>
>> GuC: 55.0.0
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
>> Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
>> ---
>> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++++++-------
>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
>> 2 files changed, 97 insertions(+), 58 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> index be066a62e9e0..3f9039e3ef9d 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> @@ -7,46 +7,43 @@
>> #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
>> /**
>> - * DOC: MMIO based communication
>> + * DOC: GuC MMIO based communication
>> *
>> - * The MMIO based communication between Host and GuC uses software
>> scratch
>> - * registers, where first register holds data treated as message header,
>> - * and other registers are used to hold message payload.
>> + * The MMIO based communication between Host and GuC relies on special
>> + * hardware registers which format could be defined by the software
>> + * (so called scratch registers).
>> *
>> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
>> - * but no H2G command takes more than 8 parameters and the GuC FW
>> - * itself uses an 8-element array to store the H2G message.
>> - *
>> - * +-----------+---------+---------+---------+
>> - * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
>> - * +-----------+---------+---------+---------+
>> - * | header | optional payload |
>> - * +======+====+=========+=========+=========+
>> - * | 31:28|type| | | |
>> - * +------+----+ | | |
>> - * | 27:16|data| | | |
>> - * +------+----+ | | |
>> - * | 15:0|code| | | |
>> - * +------+----+---------+---------+---------+
>> - *
>> - * The message header consists of:
>> - *
>> - * - **type**, indicates message type
>> - * - **code**, indicates message code, is specific for **type**
>> - * - **data**, indicates message data, optional, depends on **code**
>> + * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
>> + * messages, which maximum length depends on number of available scratch
>> + * registers, is directly written into those scratch registers.
>> *
>> - * The following message **types** are supported:
>> + * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
>> + * but no H2G command takes more than 8 parameters and the GuC firmware
>> + * itself uses an 8-element array to store the H2G message.
>
> Is this statement still true? I believe no MMIO H2G is over 4 DWs (given
> the limitation of the new gen11+ scratch regs), while CTB messages can
> be longer than 8 DWs.
oops, it was just copy/past, you're correct, with new unified firmware,
all MMIO H2G are up to 4 DWs
>
>> *
>> - * - **REQUEST**, indicates Host-to-GuC request, requested GuC action
>> code
>> - * must be priovided in **code** field. Optional action specific
>> parameters
>> - * can be provided in remaining payload registers or **data** field.
>> + * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
>> + * are, regardless on lower count, preffered over legacy ones.
>
> typo: preffered -> preferred
>
>> *
>> - * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC
>> request,
>> - * action response status will be provided in **code** field. Optional
>> - * response data can be returned in remaining payload registers or
>> **data**
>> - * field.
>> + * The MMIO based communication is mainly used during driver
>> initialization
>> + * phase to setup the `CTB based communication`_ that will be used
>> afterwards.
>> */
>> #define GUC_MAX_MMIO_MSG_LEN 8
>
> See comment above. Reduce this to 4?
yes, must be reduced
>
>> +/**
>> + * DOC: MMIO HXG Message
>> + *
>> + * Format of the MMIO messages follows definitions of `HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31:0 |
>> +--------------------------------------------------------+ |
>> + * +---+-------+
>> | | |
>> + * |...| | | Embedded `HXG
>> Message`_ | |
>> + * +---+-------+
>> | | |
>> + * | n | 31:0 |
>> +--------------------------------------------------------+ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> index f147cb389a20..b773567cb080 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
>> /*
>> * This function implements the MMIO based host to GuC interface.
>> */
>> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
>> len,
>> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request,
>> u32 len,
>> u32 *response_buf, u32 response_buf_size)
>> {
>> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
>> - u32 status;
>> + u32 header;
>> int i;
>> int ret;
>> GEM_BUG_ON(!len);
>> GEM_BUG_ON(len > guc->send_regs.count);
>> - /* We expect only action code */
>> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
>> -
>> - /* If CT is available, we expect to use MMIO only during
>> init/fini */
>> - GEM_BUG_ON(*action !=
>> INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
>> - *action !=
>> INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) !=
>> GUC_HXG_ORIGIN_HOST);
>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) !=
>> GUC_HXG_TYPE_REQUEST);
>> mutex_lock(&guc->send_mutex);
>> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>> +retry:
>> for (i = 0; i < len; i++)
>> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
>> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc,
>> const u32 *action, u32 len,
>> */
>> ret = __intel_wait_for_register_fw(uncore,
>> guc_send_reg(guc, 0),
>> - INTEL_GUC_MSG_TYPE_MASK,
>> - INTEL_GUC_MSG_TYPE_RESPONSE <<
>> - INTEL_GUC_MSG_TYPE_SHIFT,
>> - 10, 10, &status);
>> - /* If GuC explicitly returned an error, convert it to -EIO */
>> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
>> - ret = -EIO;
>> + GUC_HXG_MSG_0_ORIGIN,
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
>> + GUC_HXG_ORIGIN_GUC),
>> + 10, 10, &header);
>> + if (unlikely(ret)) {
>> +timeout:
>> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
>> + request[0], header);
>> + goto out;
>> + }
>> - if (ret) {
>> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
>> - action[0], ret, status);
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>> GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
>> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc,
>> 0)); \
>> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC
>> || \
>> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>> GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
>> +
>> + ret = wait_for(done, 1000);
>> + if (unlikely(ret))
>> + goto timeout;
>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
>> + GUC_HXG_ORIGIN_GUC))
>> + goto proto;
>> +#undef done
>> + }
>> +
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>> GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
>> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
>> +
>> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
>> + request[0], reason);
>> + goto retry;
>> + }
>> +
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>> GUC_HXG_TYPE_RESPONSE_FAILURE) {
>> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
>> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
>> +
>> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
>> + request[0], error, hint);
>> + ret = -ENXIO;
>> + goto out;
>> + }
>> +
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>> +proto:
>> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
>> + request[0], header);
>> + ret = -EPROTO;
>> goto out;
>> }
>> if (response_buf) {
>> - int count = min(response_buf_size, guc->send_regs.count - 1);
>> + int count = min(response_buf_size, guc->send_regs.count);
>> - for (i = 0; i < count; i++)
>> + GEM_BUG_ON(!count);
>> +
>> + response_buf[0] = header;
>> +
>> + for (i = 1; i < count; i++)
>> response_buf[i] = intel_uncore_read(uncore,
>> - guc_send_reg(guc, i + 1));
>> - }
>> + guc_send_reg(guc, i));
>
> This could use a note in the commit message to remark that we have no
> users for the returned data yet and therefore nothing will break if we
> change what we return through it.
I hope this will do the work:
"Since some of the new MMIO actions may use DATA0 from MMIO HXG
response, we must update intel_guc_send_mmio() to copy full response,
including HXG header. There will be no impact to existing users as all
of them are only relying just on return code."
>
> Apart from the nits, the logic looks good to me.
> Daniele
>
>> - /* Use data from the GuC response as our return value */
>> - ret = INTEL_GUC_MSG_TO_DATA(status);
>> + /* Use number of copied dwords as our return value */
>> + ret = count;
>> + } else {
>> + /* Use data from the GuC response as our return value */
>> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
>> + }
>> out:
>> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication
@ 2021-06-08 8:15 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-08 8:15 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
On 08.06.2021 01:06, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> The MMIO based Host-to-GuC communication protocol has been
>> updated to use unified HXG messages.
>>
>> Update our intel_guc_send_mmio() function by correctly handle
>> BUSY, RETRY and FAILURE replies. Also update our documentation.
>>
>> GuC: 55.0.0
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
>> Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
>> ---
>> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++++++-------
>> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
>> 2 files changed, 97 insertions(+), 58 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> index be066a62e9e0..3f9039e3ef9d 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
>> @@ -7,46 +7,43 @@
>> #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
>> /**
>> - * DOC: MMIO based communication
>> + * DOC: GuC MMIO based communication
>> *
>> - * The MMIO based communication between Host and GuC uses software
>> scratch
>> - * registers, where first register holds data treated as message header,
>> - * and other registers are used to hold message payload.
>> + * The MMIO based communication between Host and GuC relies on special
>> + * hardware registers which format could be defined by the software
>> + * (so called scratch registers).
>> *
>> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
>> - * but no H2G command takes more than 8 parameters and the GuC FW
>> - * itself uses an 8-element array to store the H2G message.
>> - *
>> - * +-----------+---------+---------+---------+
>> - * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
>> - * +-----------+---------+---------+---------+
>> - * | header | optional payload |
>> - * +======+====+=========+=========+=========+
>> - * | 31:28|type| | | |
>> - * +------+----+ | | |
>> - * | 27:16|data| | | |
>> - * +------+----+ | | |
>> - * | 15:0|code| | | |
>> - * +------+----+---------+---------+---------+
>> - *
>> - * The message header consists of:
>> - *
>> - * - **type**, indicates message type
>> - * - **code**, indicates message code, is specific for **type**
>> - * - **data**, indicates message data, optional, depends on **code**
>> + * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
>> + * messages, which maximum length depends on number of available scratch
>> + * registers, is directly written into those scratch registers.
>> *
>> - * The following message **types** are supported:
>> + * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
>> + * but no H2G command takes more than 8 parameters and the GuC firmware
>> + * itself uses an 8-element array to store the H2G message.
>
> Is this statement still true? I believe no MMIO H2G is over 4 DWs (given
> the limitation of the new gen11+ scratch regs), while CTB messages can
> be longer than 8 DWs.
oops, it was just copy/past, you're correct, with new unified firmware,
all MMIO H2G are up to 4 DWs
>
>> *
>> - * - **REQUEST**, indicates Host-to-GuC request, requested GuC action
>> code
>> - * must be priovided in **code** field. Optional action specific
>> parameters
>> - * can be provided in remaining payload registers or **data** field.
>> + * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
>> + * are, regardless on lower count, preffered over legacy ones.
>
> typo: preffered -> preferred
>
>> *
>> - * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC
>> request,
>> - * action response status will be provided in **code** field. Optional
>> - * response data can be returned in remaining payload registers or
>> **data**
>> - * field.
>> + * The MMIO based communication is mainly used during driver
>> initialization
>> + * phase to setup the `CTB based communication`_ that will be used
>> afterwards.
>> */
>> #define GUC_MAX_MMIO_MSG_LEN 8
>
> See comment above. Reduce this to 4?
yes, must be reduced
>
>> +/**
>> + * DOC: MMIO HXG Message
>> + *
>> + * Format of the MMIO messages follows definitions of `HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31:0 |
>> +--------------------------------------------------------+ |
>> + * +---+-------+
>> | | |
>> + * |...| | | Embedded `HXG
>> Message`_ | |
>> + * +---+-------+
>> | | |
>> + * | n | 31:0 |
>> +--------------------------------------------------------+ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> index f147cb389a20..b773567cb080 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
>> /*
>> * This function implements the MMIO based host to GuC interface.
>> */
>> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
>> len,
>> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request,
>> u32 len,
>> u32 *response_buf, u32 response_buf_size)
>> {
>> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
>> - u32 status;
>> + u32 header;
>> int i;
>> int ret;
>> GEM_BUG_ON(!len);
>> GEM_BUG_ON(len > guc->send_regs.count);
>> - /* We expect only action code */
>> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
>> -
>> - /* If CT is available, we expect to use MMIO only during
>> init/fini */
>> - GEM_BUG_ON(*action !=
>> INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
>> - *action !=
>> INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) !=
>> GUC_HXG_ORIGIN_HOST);
>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) !=
>> GUC_HXG_TYPE_REQUEST);
>> mutex_lock(&guc->send_mutex);
>> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>> +retry:
>> for (i = 0; i < len; i++)
>> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
>> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc,
>> const u32 *action, u32 len,
>> */
>> ret = __intel_wait_for_register_fw(uncore,
>> guc_send_reg(guc, 0),
>> - INTEL_GUC_MSG_TYPE_MASK,
>> - INTEL_GUC_MSG_TYPE_RESPONSE <<
>> - INTEL_GUC_MSG_TYPE_SHIFT,
>> - 10, 10, &status);
>> - /* If GuC explicitly returned an error, convert it to -EIO */
>> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
>> - ret = -EIO;
>> + GUC_HXG_MSG_0_ORIGIN,
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
>> + GUC_HXG_ORIGIN_GUC),
>> + 10, 10, &header);
>> + if (unlikely(ret)) {
>> +timeout:
>> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
>> + request[0], header);
>> + goto out;
>> + }
>> - if (ret) {
>> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
>> - action[0], ret, status);
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>> GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
>> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc,
>> 0)); \
>> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC
>> || \
>> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>> GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
>> +
>> + ret = wait_for(done, 1000);
>> + if (unlikely(ret))
>> + goto timeout;
>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
>> + GUC_HXG_ORIGIN_GUC))
>> + goto proto;
>> +#undef done
>> + }
>> +
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>> GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
>> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
>> +
>> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
>> + request[0], reason);
>> + goto retry;
>> + }
>> +
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>> GUC_HXG_TYPE_RESPONSE_FAILURE) {
>> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
>> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
>> +
>> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
>> + request[0], error, hint);
>> + ret = -ENXIO;
>> + goto out;
>> + }
>> +
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>> +proto:
>> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
>> + request[0], header);
>> + ret = -EPROTO;
>> goto out;
>> }
>> if (response_buf) {
>> - int count = min(response_buf_size, guc->send_regs.count - 1);
>> + int count = min(response_buf_size, guc->send_regs.count);
>> - for (i = 0; i < count; i++)
>> + GEM_BUG_ON(!count);
>> +
>> + response_buf[0] = header;
>> +
>> + for (i = 1; i < count; i++)
>> response_buf[i] = intel_uncore_read(uncore,
>> - guc_send_reg(guc, i + 1));
>> - }
>> + guc_send_reg(guc, i));
>
> This could use a note in the commit message to remark that we have no
> users for the returned data yet and therefore nothing will break if we
> change what we return through it.
I hope this will do the work:
"Since some of the new MMIO actions may use DATA0 from MMIO HXG
response, we must update intel_guc_send_mmio() to copy full response,
including HXG header. There will be no impact to existing users as all
of them are only relying just on return code."
>
> Apart from the nits, the logic looks good to me.
> Daniele
>
>> - /* Use data from the GuC response as our return value */
>> - ret = INTEL_GUC_MSG_TO_DATA(status);
>> + /* Use number of copied dwords as our return value */
>> + ret = count;
>> + } else {
>> + /* Use data from the GuC response as our return value */
>> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
>> + }
>> out:
>> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 03/13] drm/i915/guc: Update CTB response status definition
2021-06-08 0:05 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-08 8:23 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-08 8:23 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
Cc: john.c.harrison
On 08.06.2021 02:05, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Format of the STATUS dword in CTB response message now follows
>> definition of the HXG header. Update our code and remove any
>> obsolete legacy definitions.
>
> This is kind of hard to review on its own against the specs, because
> there are larger changes to the CTB flows which AFAICS are part of patch
> 8. If what you wanted to do here was a simple replacement of defines to
> keep the later patch simpler, then, considering all patches are going to
> be squashed anyway:
>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> One suggestion below.
>
>>
>> GuC: 55.0.0
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Acked-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 ++++++++------
>> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -----------------
>> 2 files changed, 8 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 8f7b148fef58..3f7f48611487 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct
>> ct_request *req, u32 *status)
>> * up to that length of time, then switch to a slower sleep-wait
>> loop.
>> * No GuC command should ever take longer than 10ms.
>> */
>> -#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
>> +#define done \
>> + (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
>> + GUC_HXG_ORIGIN_GUC)
>> err = wait_for_us(done, 10);
>> if (err)
>> err = wait_for(done, 10);
>> @@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
>> if (unlikely(err))
>> goto unlink;
>> - if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) !=
>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>> err = -EIO;
>> goto unlink;
>> }
>> if (response_buf) {
>> /* There shall be no data in the status */
>> - WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
>> + WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0,
>> request.status));
>> /* Return actual response len */
>> err = request.response_len;
>> } else {
>> /* There shall be no response payload */
>> WARN_ON(request.response_len);
>> /* Return data decoded from the status dword */
>> - err = INTEL_GUC_MSG_TO_DATA(*status);
>> + err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
>
> Given that the same FIELD_GET() are repeated multiple times, IMO we
> could've kept some helper macros, something like:
>
> INTEL_GUC_HXG_RESPONSE_TO_DATA(hxg) \
> FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, hxg)
>
> INTEL_GUC_HXG_ORIGIN_IS_GUC(hxg) \
> (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg) == GUC_HXG_ORIGIN_GUC)
>
> INTEL_GUC_HXG_TYPE(hxg) \
> FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg)
>
> Which could be useful in the mmio code as well.
> Not sure how this changes in patch 8 though, I might put some more
> comments on that patch.
sure, we can add some of above helper macros, but not part of the ABI
definitions, but in fwif.h where we have other wrappers
and better to add them later as optional improvement, when all
refactoring dust settles down
>
> Daniele
>
>> }
>> unlink:
>> @@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct
>> *ct, struct ct_incoming_msg *r
>> status = response->msg[2];
>> datalen = len - 2;
>> - /* Format of the status follows RESPONSE message */
>> - if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
>> + /* Format of the status dword follows HXG header */
>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) !=
>> GUC_HXG_ORIGIN_GUC)) {
>> CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
>> return -EPROTO;
>> }
>> 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 e9a9d85e2aa3..fb04e2211b79 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> @@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
>> struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
>> } __packed;
>> -#define __INTEL_GUC_MSG_GET(T, m) \
>> - (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ##
>> _SHIFT)
>> -#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
>> -#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
>> -#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
>> -
>> -#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
>> - (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
>> -#define INTEL_GUC_MSG_IS_REQUEST(m)
>> __INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
>> -#define INTEL_GUC_MSG_IS_RESPONSE(m)
>> __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
>> -
>> -#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
>> - (typecheck(u32, (m)) && \
>> - ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
>> - ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
>> - (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
>> -
>> /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
>> enum intel_guc_recv_message {
>> INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 03/13] drm/i915/guc: Update CTB response status definition
@ 2021-06-08 8:23 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-08 8:23 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
On 08.06.2021 02:05, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Format of the STATUS dword in CTB response message now follows
>> definition of the HXG header. Update our code and remove any
>> obsolete legacy definitions.
>
> This is kind of hard to review on its own against the specs, because
> there are larger changes to the CTB flows which AFAICS are part of patch
> 8. If what you wanted to do here was a simple replacement of defines to
> keep the later patch simpler, then, considering all patches are going to
> be squashed anyway:
>
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> One suggestion below.
>
>>
>> GuC: 55.0.0
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Acked-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 ++++++++------
>> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -----------------
>> 2 files changed, 8 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 8f7b148fef58..3f7f48611487 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct
>> ct_request *req, u32 *status)
>> * up to that length of time, then switch to a slower sleep-wait
>> loop.
>> * No GuC command should ever take longer than 10ms.
>> */
>> -#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
>> +#define done \
>> + (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
>> + GUC_HXG_ORIGIN_GUC)
>> err = wait_for_us(done, 10);
>> if (err)
>> err = wait_for(done, 10);
>> @@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
>> if (unlikely(err))
>> goto unlink;
>> - if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) !=
>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>> err = -EIO;
>> goto unlink;
>> }
>> if (response_buf) {
>> /* There shall be no data in the status */
>> - WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
>> + WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0,
>> request.status));
>> /* Return actual response len */
>> err = request.response_len;
>> } else {
>> /* There shall be no response payload */
>> WARN_ON(request.response_len);
>> /* Return data decoded from the status dword */
>> - err = INTEL_GUC_MSG_TO_DATA(*status);
>> + err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
>
> Given that the same FIELD_GET() are repeated multiple times, IMO we
> could've kept some helper macros, something like:
>
> INTEL_GUC_HXG_RESPONSE_TO_DATA(hxg) \
> FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, hxg)
>
> INTEL_GUC_HXG_ORIGIN_IS_GUC(hxg) \
> (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg) == GUC_HXG_ORIGIN_GUC)
>
> INTEL_GUC_HXG_TYPE(hxg) \
> FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg)
>
> Which could be useful in the mmio code as well.
> Not sure how this changes in patch 8 though, I might put some more
> comments on that patch.
sure, we can add some of above helper macros, but not part of the ABI
definitions, but in fwif.h where we have other wrappers
and better to add them later as optional improvement, when all
refactoring dust settles down
>
> Daniele
>
>> }
>> unlink:
>> @@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct
>> *ct, struct ct_incoming_msg *r
>> status = response->msg[2];
>> datalen = len - 2;
>> - /* Format of the status follows RESPONSE message */
>> - if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
>> + /* Format of the status dword follows HXG header */
>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) !=
>> GUC_HXG_ORIGIN_GUC)) {
>> CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
>> return -EPROTO;
>> }
>> 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 e9a9d85e2aa3..fb04e2211b79 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> @@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
>> struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
>> } __packed;
>> -#define __INTEL_GUC_MSG_GET(T, m) \
>> - (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ##
>> _SHIFT)
>> -#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
>> -#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
>> -#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
>> -
>> -#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
>> - (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
>> -#define INTEL_GUC_MSG_IS_REQUEST(m)
>> __INTEL_GUC_MSG_TYPE_IS(REQUEST, m)
>> -#define INTEL_GUC_MSG_IS_RESPONSE(m)
>> __INTEL_GUC_MSG_TYPE_IS(RESPONSE, m)
>> -
>> -#define INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(m) \
>> - (typecheck(u32, (m)) && \
>> - ((m) & (INTEL_GUC_MSG_TYPE_MASK | INTEL_GUC_MSG_CODE_MASK)) == \
>> - ((INTEL_GUC_MSG_TYPE_RESPONSE << INTEL_GUC_MSG_TYPE_SHIFT) | \
>> - (INTEL_GUC_RESPONSE_STATUS_SUCCESS << INTEL_GUC_MSG_CODE_SHIFT)))
>> -
>> /* This action will be programmed in C1BC - SOFT_SCRATCH_15_REG */
>> enum intel_guc_recv_message {
>> INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED = BIT(1),
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 02/13] drm/i915/guc: Update MMIO based communication
2021-06-08 8:15 ` [Intel-gfx] " Michal Wajdeczko
@ 2021-06-09 1:03 ` Daniele Ceraolo Spurio
-1 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-09 1:03 UTC (permalink / raw)
To: Michal Wajdeczko, Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison
<snip>
>>> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> index f147cb389a20..b773567cb080 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
>>> /*
>>> * This function implements the MMIO based host to GuC interface.
>>> */
>>> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
>>> len,
>>> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request,
>>> u32 len,
>>> u32 *response_buf, u32 response_buf_size)
>>> {
>>> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>>> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
>>> - u32 status;
>>> + u32 header;
>>> int i;
>>> int ret;
>>> GEM_BUG_ON(!len);
>>> GEM_BUG_ON(len > guc->send_regs.count);
>>> - /* We expect only action code */
>>> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
>>> -
>>> - /* If CT is available, we expect to use MMIO only during
>>> init/fini */
>>> - GEM_BUG_ON(*action !=
>>> INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
>>> - *action !=
>>> INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
>>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) !=
>>> GUC_HXG_ORIGIN_HOST);
>>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) !=
>>> GUC_HXG_TYPE_REQUEST);
>>> mutex_lock(&guc->send_mutex);
>>> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>>> +retry:
>>> for (i = 0; i < len; i++)
>>> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
>>> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>>> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>>> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc,
>>> const u32 *action, u32 len,
>>> */
>>> ret = __intel_wait_for_register_fw(uncore,
>>> guc_send_reg(guc, 0),
>>> - INTEL_GUC_MSG_TYPE_MASK,
>>> - INTEL_GUC_MSG_TYPE_RESPONSE <<
>>> - INTEL_GUC_MSG_TYPE_SHIFT,
>>> - 10, 10, &status);
>>> - /* If GuC explicitly returned an error, convert it to -EIO */
>>> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
>>> - ret = -EIO;
>>> + GUC_HXG_MSG_0_ORIGIN,
>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
>>> + GUC_HXG_ORIGIN_GUC),
>>> + 10, 10, &header);
>>> + if (unlikely(ret)) {
>>> +timeout:
>>> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
>>> + request[0], header);
>>> + goto out;
>>> + }
>>> - if (ret) {
>>> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
>>> - action[0], ret, status);
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>>> GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
>>> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc,
>>> 0)); \
>>> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC
>>> || \
>>> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>>> GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
>>> +
>>> + ret = wait_for(done, 1000);
>>> + if (unlikely(ret))
>>> + goto timeout;
>>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
>>> + GUC_HXG_ORIGIN_GUC))
>>> + goto proto;
>>> +#undef done
>>> + }
>>> +
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>>> GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
>>> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
>>> +
>>> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
>>> + request[0], reason);
>>> + goto retry;
>>> + }
>>> +
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>>> GUC_HXG_TYPE_RESPONSE_FAILURE) {
>>> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
>>> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
>>> +
>>> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
>>> + request[0], error, hint);
>>> + ret = -ENXIO;
>>> + goto out;
>>> + }
>>> +
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>>> +proto:
>>> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
>>> + request[0], header);
>>> + ret = -EPROTO;
>>> goto out;
>>> }
>>> if (response_buf) {
>>> - int count = min(response_buf_size, guc->send_regs.count - 1);
>>> + int count = min(response_buf_size, guc->send_regs.count);
>>> - for (i = 0; i < count; i++)
>>> + GEM_BUG_ON(!count);
>>> +
>>> + response_buf[0] = header;
>>> +
>>> + for (i = 1; i < count; i++)
>>> response_buf[i] = intel_uncore_read(uncore,
>>> - guc_send_reg(guc, i + 1));
>>> - }
>>> + guc_send_reg(guc, i));
>> This could use a note in the commit message to remark that we have no
>> users for the returned data yet and therefore nothing will break if we
>> change what we return through it.
> I hope this will do the work:
>
> "Since some of the new MMIO actions may use DATA0 from MMIO HXG
> response, we must update intel_guc_send_mmio() to copy full response,
> including HXG header. There will be no impact to existing users as all
> of them are only relying just on return code."
Yes it does.
Daniele
>
>> Apart from the nits, the logic looks good to me.
>> Daniele
>>
>>> - /* Use data from the GuC response as our return value */
>>> - ret = INTEL_GUC_MSG_TO_DATA(status);
>>> + /* Use number of copied dwords as our return value */
>>> + ret = count;
>>> + } else {
>>> + /* Use data from the GuC response as our return value */
>>> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
>>> + }
>>> out:
>>> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 02/13] drm/i915/guc: Update MMIO based communication
@ 2021-06-09 1:03 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-09 1:03 UTC (permalink / raw)
To: Michal Wajdeczko, Matthew Brost, intel-gfx, dri-devel
<snip>
>>> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> index f147cb389a20..b773567cb080 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
>>> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
>>> /*
>>> * This function implements the MMIO based host to GuC interface.
>>> */
>>> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32
>>> len,
>>> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request,
>>> u32 len,
>>> u32 *response_buf, u32 response_buf_size)
>>> {
>>> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
>>> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
>>> - u32 status;
>>> + u32 header;
>>> int i;
>>> int ret;
>>> GEM_BUG_ON(!len);
>>> GEM_BUG_ON(len > guc->send_regs.count);
>>> - /* We expect only action code */
>>> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
>>> -
>>> - /* If CT is available, we expect to use MMIO only during
>>> init/fini */
>>> - GEM_BUG_ON(*action !=
>>> INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
>>> - *action !=
>>> INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
>>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) !=
>>> GUC_HXG_ORIGIN_HOST);
>>> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) !=
>>> GUC_HXG_TYPE_REQUEST);
>>> mutex_lock(&guc->send_mutex);
>>> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>>> +retry:
>>> for (i = 0; i < len; i++)
>>> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
>>> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>>> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>>> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc,
>>> const u32 *action, u32 len,
>>> */
>>> ret = __intel_wait_for_register_fw(uncore,
>>> guc_send_reg(guc, 0),
>>> - INTEL_GUC_MSG_TYPE_MASK,
>>> - INTEL_GUC_MSG_TYPE_RESPONSE <<
>>> - INTEL_GUC_MSG_TYPE_SHIFT,
>>> - 10, 10, &status);
>>> - /* If GuC explicitly returned an error, convert it to -EIO */
>>> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
>>> - ret = -EIO;
>>> + GUC_HXG_MSG_0_ORIGIN,
>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
>>> + GUC_HXG_ORIGIN_GUC),
>>> + 10, 10, &header);
>>> + if (unlikely(ret)) {
>>> +timeout:
>>> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
>>> + request[0], header);
>>> + goto out;
>>> + }
>>> - if (ret) {
>>> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
>>> - action[0], ret, status);
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>>> GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
>>> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc,
>>> 0)); \
>>> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC
>>> || \
>>> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>>> GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
>>> +
>>> + ret = wait_for(done, 1000);
>>> + if (unlikely(ret))
>>> + goto timeout;
>>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
>>> + GUC_HXG_ORIGIN_GUC))
>>> + goto proto;
>>> +#undef done
>>> + }
>>> +
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>>> GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
>>> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
>>> +
>>> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
>>> + request[0], reason);
>>> + goto retry;
>>> + }
>>> +
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) ==
>>> GUC_HXG_TYPE_RESPONSE_FAILURE) {
>>> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
>>> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
>>> +
>>> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
>>> + request[0], error, hint);
>>> + ret = -ENXIO;
>>> + goto out;
>>> + }
>>> +
>>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) !=
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>>> +proto:
>>> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
>>> + request[0], header);
>>> + ret = -EPROTO;
>>> goto out;
>>> }
>>> if (response_buf) {
>>> - int count = min(response_buf_size, guc->send_regs.count - 1);
>>> + int count = min(response_buf_size, guc->send_regs.count);
>>> - for (i = 0; i < count; i++)
>>> + GEM_BUG_ON(!count);
>>> +
>>> + response_buf[0] = header;
>>> +
>>> + for (i = 1; i < count; i++)
>>> response_buf[i] = intel_uncore_read(uncore,
>>> - guc_send_reg(guc, i + 1));
>>> - }
>>> + guc_send_reg(guc, i));
>> This could use a note in the commit message to remark that we have no
>> users for the returned data yet and therefore nothing will break if we
>> change what we return through it.
> I hope this will do the work:
>
> "Since some of the new MMIO actions may use DATA0 from MMIO HXG
> response, we must update intel_guc_send_mmio() to copy full response,
> including HXG header. There will be no impact to existing users as all
> of them are only relying just on return code."
Yes it does.
Daniele
>
>> Apart from the nits, the logic looks good to me.
>> Daniele
>>
>>> - /* Use data from the GuC response as our return value */
>>> - ret = INTEL_GUC_MSG_TO_DATA(status);
>>> + /* Use number of copied dwords as our return value */
>>> + ret = count;
>>> + } else {
>>> + /* Use data from the GuC response as our return value */
>>> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
>>> + }
>>> out:
>>> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-08 1:23 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-09 17:36 ` John Harrison
-1 siblings, 0 replies; 87+ messages in thread
From: John Harrison @ 2021-06-09 17:36 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
Cc: Michal.Wajdeczko
On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>
>> 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 90efef8a73e4..6426fc183692 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
>> @@ -6,6 +6,113 @@
>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>> #define _ABI_GUC_ACTIONS_ABI_H
>> +/**
>> + * DOC: HOST2GUC_REGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_
>> setup.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>> 0x5200 |
>
> Specs says 4505
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type for the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>> 0 |
>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>> 1 |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>> minus 1 |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>> Descriptor`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>> Buffer`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + */
>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>
> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> at some point I don;t think this deserves a FIXME since nothing is
> incorrect.
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>
> The full mask still seems like overkill to me and I still think we
> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
> on it.
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/**
>> + * DOC: HOST2GUC_DEREGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_
>> teardown.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>> 0x5201 |
>
> Specs says 4506
>
I would say that the enum value should not be included in the structure
definition. I would also argue that there is no point in repeating the
common header structure for every single H2G action definition. That is
just overly verbose and makes it harder to read the spec. It implies
that every action has a different header structure and must be coded
individually.
Personally, I don't believe we should be replicating the entire GuC API
spec in the driver header files anyway. This is not something that is
defined by the i915 driver so the i915 driver should not be defining it!
Instead, just include a link or pointer to where the actual spec can be
found. We don't copy the entire bspec page for every register that the
driver touches, so why should this be any different?
John.
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type of the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | see
>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + */
>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
>> 0x5201
>
> Same comment for the FIXME as above
>
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/* legacy definitions */
>> +
>> enum intel_guc_action {
>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index c2a069a78e01..127b256a662c 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>> == 64);
>> * - **flags**, holds various bits to control message handling
>> */
>> -/* Type of command transport buffer */
>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>> -
>> /*
>> * Definition of the command transport message header (DW0)
>> *
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 3241a477196f..6a29be779cc9 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
>> *ct)
>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>> {
>> switch (type) {
>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>> + case GUC_CTB_TYPE_HOST2GUC:
>> return "SEND";
>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>> + case GUC_CTB_TYPE_GUC2HOST:
>> return "RECV";
>> default:
>> return "<invalid>";
>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>> intel_guc_ct_buffer *ctb,
>> guc_ct_buffer_reset(ctb);
>> }
>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>> - u32 desc_addr,
>> - u32 type)
>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>> type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>> - desc_addr,
>> - sizeof(struct guc_ct_buffer_desc),
>> - type
>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>
> IMO we could use a macro or 2 for the HXG header, to avoid all these
> lines, which are hard to read. something like:
>
> GUC_HXG_HEADER(origin, type, data, action) \
> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>
> H2G_HEADER(type, data, action) \
> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>
> and then call
>
> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
>
>
> Not a blocker.
>
> Daniele
>
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
>> 1) |
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
>> };
>> - /* Can't use generic send(), CT registration must go over MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>> NULL, 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> + GEM_BUG_ON(size % SZ_4K);
>> +
>> + /* CT registration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>> desc_addr, u32 type)
>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
>> desc_addr, type);
>> + int err;
>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>> + desc_addr, buff_addr, size);
>> if (unlikely(err))
>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>> guc_ct_buffer_type_to_str(type), err);
>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>> u32 type)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>> - CTB_OWNER_HOST,
>> - type
>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> };
>> - /* Can't use generic send(), CT deregistration must go over
>> MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>> NULL, 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> +
>> + /* CT deregistration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> {
>> struct intel_guc *guc = ct_to_guc(ct);
>> - u32 base, cmds;
>> + u32 base, desc, cmds;
>> void *blob;
>> int err;
>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>> /* (re)initialize descriptors */
>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.send);
>> -
>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.recv);
>> /*
>> * Register both CT buffers starting with RECV buffer.
>> * Descriptors are in first half of the blob.
>> */
>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>> blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>> + desc, cmds, ct->ctbs.recv.size * 4);
>> +
>> if (unlikely(err))
>> goto err_out;
>> - err = ct_register_buffer(ct, base +
>> ptrdiff(ct->ctbs.send.desc, blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>> + desc, cmds, ct->ctbs.send.size * 4);
>> +
>> if (unlikely(err))
>> goto err_deregister;
>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> return 0;
>> err_deregister:
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> err_out:
>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>> return err;
>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>> ct->enabled = false;
>> if (intel_guc_is_fw_running(guc)) {
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> }
>> }
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-09 17:36 ` John Harrison
0 siblings, 0 replies; 87+ messages in thread
From: John Harrison @ 2021-06-09 17:36 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>
>> 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 90efef8a73e4..6426fc183692 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
>> @@ -6,6 +6,113 @@
>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>> #define _ABI_GUC_ACTIONS_ABI_H
>> +/**
>> + * DOC: HOST2GUC_REGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_
>> setup.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>> 0x5200 |
>
> Specs says 4505
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type for the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>> 0 |
>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>> 1 |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>> minus 1 |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>> Descriptor`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>> Buffer`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + */
>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>
> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> at some point I don;t think this deserves a FIXME since nothing is
> incorrect.
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>
> The full mask still seems like overkill to me and I still think we
> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
> on it.
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/**
>> + * DOC: HOST2GUC_DEREGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_
>> teardown.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>> 0x5201 |
>
> Specs says 4506
>
I would say that the enum value should not be included in the structure
definition. I would also argue that there is no point in repeating the
common header structure for every single H2G action definition. That is
just overly verbose and makes it harder to read the spec. It implies
that every action has a different header structure and must be coded
individually.
Personally, I don't believe we should be replicating the entire GuC API
spec in the driver header files anyway. This is not something that is
defined by the i915 driver so the i915 driver should not be defining it!
Instead, just include a link or pointer to where the actual spec can be
found. We don't copy the entire bspec page for every register that the
driver touches, so why should this be any different?
John.
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type of the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | see
>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>> + */
>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
>> 0x5201
>
> Same comment for the FIXME as above
>
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/* legacy definitions */
>> +
>> enum intel_guc_action {
>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index c2a069a78e01..127b256a662c 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>> == 64);
>> * - **flags**, holds various bits to control message handling
>> */
>> -/* Type of command transport buffer */
>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>> -
>> /*
>> * Definition of the command transport message header (DW0)
>> *
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 3241a477196f..6a29be779cc9 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
>> *ct)
>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>> {
>> switch (type) {
>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>> + case GUC_CTB_TYPE_HOST2GUC:
>> return "SEND";
>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>> + case GUC_CTB_TYPE_GUC2HOST:
>> return "RECV";
>> default:
>> return "<invalid>";
>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>> intel_guc_ct_buffer *ctb,
>> guc_ct_buffer_reset(ctb);
>> }
>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>> - u32 desc_addr,
>> - u32 type)
>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>> type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>> - desc_addr,
>> - sizeof(struct guc_ct_buffer_desc),
>> - type
>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>
> IMO we could use a macro or 2 for the HXG header, to avoid all these
> lines, which are hard to read. something like:
>
> GUC_HXG_HEADER(origin, type, data, action) \
> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>
> H2G_HEADER(type, data, action) \
> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>
> and then call
>
> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
>
>
> Not a blocker.
>
> Daniele
>
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
>> 1) |
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
>> };
>> - /* Can't use generic send(), CT registration must go over MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>> NULL, 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> + GEM_BUG_ON(size % SZ_4K);
>> +
>> + /* CT registration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>> desc_addr, u32 type)
>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
>> desc_addr, type);
>> + int err;
>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>> + desc_addr, buff_addr, size);
>> if (unlikely(err))
>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>> guc_ct_buffer_type_to_str(type), err);
>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>> u32 type)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>> - CTB_OWNER_HOST,
>> - type
>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> };
>> - /* Can't use generic send(), CT deregistration must go over
>> MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>> NULL, 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> +
>> + /* CT deregistration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> {
>> struct intel_guc *guc = ct_to_guc(ct);
>> - u32 base, cmds;
>> + u32 base, desc, cmds;
>> void *blob;
>> int err;
>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>> /* (re)initialize descriptors */
>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.send);
>> -
>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.recv);
>> /*
>> * Register both CT buffers starting with RECV buffer.
>> * Descriptors are in first half of the blob.
>> */
>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>> blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>> + desc, cmds, ct->ctbs.recv.size * 4);
>> +
>> if (unlikely(err))
>> goto err_out;
>> - err = ct_register_buffer(ct, base +
>> ptrdiff(ct->ctbs.send.desc, blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>> + desc, cmds, ct->ctbs.send.size * 4);
>> +
>> if (unlikely(err))
>> goto err_deregister;
>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> return 0;
>> err_deregister:
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> err_out:
>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>> return err;
>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>> ct->enabled = false;
>> if (intel_guc_is_fw_running(guc)) {
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> }
>> }
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor
2021-06-08 0:59 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-09 18:28 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-09 18:28 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
Cc: john.c.harrison
On 08.06.2021 02:59, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Definition of the CTB descriptor has changed, leaving only
>> minimal shared fields like HEAD/TAIL/STATUS.
>>
>> Both HEAD and TAIL are now in dwords.
>>
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> ---
>> .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++++++++++++++-----
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +++++++++----------
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
>> 3 files changed, 85 insertions(+), 57 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index d38935f47ecf..c2a069a78e01 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -7,6 +7,58 @@
>> #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
>> #include <linux/types.h>
>> +#include <linux/build_bug.h>
>> +
>> +#include "guc_messages_abi.h"
>> +
>> +/**
>> + * DOC: CT Buffer
>> + *
>> + * TBD
>
> What's the plan with this TBD here?
Plan was to add some updated text based on old "DOC: CTB based
communication" section
>
>> + */
>> +
>> +/**
>> + * DOC: CTB Descriptor
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31:0 | **HEAD** - offset (in dwords) to the last dword
>> that was |
>> + * | | | read from the `CT
>> Buffer`_. |
>> + * | | | It can only be updated by the
>> receiver. |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0 | **TAIL** - offset (in dwords) to the last dword
>> that was |
>> + * | | | written to the `CT
>> Buffer`_. |
>> + * | | | It can only be updated by the
>> sender. |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 2 | 31:0 | **STATUS** - status of the
>> CTB |
>> + * | |
>> | |
>> + * | | | - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal
>> operation) |
>> + * | | | - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too
>> large) |
>> + * | | | - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated
>> message) |
>> + * | | | - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail
>> modified) |
>> + * | | | - _`GUC_CTB_STATUS_NO_BACKCHANNEL` =
>> 8 |
>> + * | | | - _`GUC_CTB_STATUS_MALFORMED_MSG` =
>> 16 |
>
> I don't see the last 2 error (8 & 16) in the 62.0.0 specs. Where is the
> reference for them?
both were discussed on various meetings but likely didn't make into
final spec 62, so for now we can drop them both
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * |...| | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 15| 31:0 | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +struct guc_ct_buffer_desc {
>> + u32 head;
>> + u32 tail;
>> + u32 status;
>> +#define GUC_CTB_STATUS_NO_ERROR 0
>> +#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
>> +#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
>> +#define GUC_CTB_STATUS_MISMATCH (1 << 2)
>> +#define GUC_CTB_STATUS_NO_BACKCHANNEL (1 << 3)
>> +#define GUC_CTB_STATUS_MALFORMED_MSG (1 << 4)
>
> use BIT() ?
as explained before, on ABI headers we didn't want any dependency and
just use plain C
>
>> + u32 reserved[13];
>> +} __packed;
>> +static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>> /**
>> * DOC: CTB based communication
>> @@ -60,24 +112,6 @@
>> * - **flags**, holds various bits to control message handling
>> */
>> -/*
>> - * Describes single command transport buffer.
>> - * Used by both guc-master and clients.
>> - */
>> -struct guc_ct_buffer_desc {
>> - u32 addr; /* gfx address */
>> - u64 host_private; /* host private data */
>> - u32 size; /* size in bytes */
>> - u32 head; /* offset updated by GuC*/
>> - u32 tail; /* offset updated by owner */
>> - u32 is_in_error; /* error indicator */
>> - u32 reserved1;
>> - u32 reserved2;
>> - u32 owner; /* id of the channel owner */
>> - u32 owner_sub_id; /* owner-defined field for extra tracking */
>> - u32 reserved[5];
>> -} __packed;
>> -
>> /* Type of command transport buffer */
>> #define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>> #define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 63056ea0631e..3241a477196f 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -112,32 +112,28 @@ static inline const char
>> *guc_ct_buffer_type_to_str(u32 type)
>> }
>> }
>> -static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
>> - u32 cmds_addr, u32 size)
>> +static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
>
> this function is called from only 1 place and only does a memset now, so
> IMO we can just drop it and inline the memset.
ok, but without enthusiasm ;)
>
> The logic below matches the specs.
>
> Daniele
>
>> {
>> memset(desc, 0, sizeof(*desc));
>> - desc->addr = cmds_addr;
>> - desc->size = size;
>> - desc->owner = CTB_OWNER_HOST;
>> }
>> -static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb,
>> u32 cmds_addr)
>> +static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
>> {
>> ctb->broken = false;
>> - guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
>> + guc_ct_buffer_desc_init(ctb->desc);
>> }
>> static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
>> struct guc_ct_buffer_desc *desc,
>> - u32 *cmds, u32 size)
>> + u32 *cmds, u32 size_in_bytes)
>> {
>> - GEM_BUG_ON(size % 4);
>> + GEM_BUG_ON(size_in_bytes % 4);
>> ctb->desc = desc;
>> ctb->cmds = cmds;
>> - ctb->size = size;
>> + ctb->size = size_in_bytes / 4;
>> - guc_ct_buffer_reset(ctb, 0);
>> + guc_ct_buffer_reset(ctb);
>> }
>> static int guc_action_register_ct_buffer(struct intel_guc *guc,
>> @@ -279,10 +275,10 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> /* (re)initialize descriptors */
>> cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> - guc_ct_buffer_reset(&ct->ctbs.send, cmds);
>> + guc_ct_buffer_reset(&ct->ctbs.send);
>> cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> - guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
>> + guc_ct_buffer_reset(&ct->ctbs.recv);
>> /*
>> * Register both CT buffers starting with RECV buffer.
>> @@ -391,17 +387,15 @@ static int ct_write(struct intel_guc_ct *ct,
>> if (unlikely(ctb->broken))
>> return -EPIPE;
>> - if (unlikely(desc->is_in_error))
>> + if (unlikely(desc->status))
>> goto corrupted;
>> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
>> - (tail | head) >= size))
>> + if (unlikely((tail | head) >= size)) {
>> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
>> + head, tail, size);
>> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
>> goto corrupted;
>> -
>> - /* later calculations will be done in dwords */
>> - head /= 4;
>> - tail /= 4;
>> - size /= 4;
>> + }
>> /*
>> * tail == head condition indicates empty. GuC FW does not support
>> @@ -447,14 +441,14 @@ static int ct_write(struct intel_guc_ct *ct,
>> */
>> write_barrier(ct);
>> - /* now update desc tail (back in bytes) */
>> - desc->tail = tail * 4;
>> + /* now update descriptor */
>> + WRITE_ONCE(desc->tail, tail);
>> +
>> return 0;
>> corrupted:
>> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u
>> size=%u\n",
>> - desc->addr, desc->head, desc->tail, desc->size);
>> - desc->is_in_error = 1;
>> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>> + desc->head, desc->tail, desc->status);
>> ctb->broken = true;
>> return -EPIPE;
>> }
>> @@ -640,17 +634,15 @@ static int ct_read(struct intel_guc_ct *ct,
>> struct ct_incoming_msg **msg)
>> if (unlikely(ctb->broken))
>> return -EPIPE;
>> - if (unlikely(desc->is_in_error))
>> + if (unlikely(desc->status))
>> goto corrupted;
>> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
>> - (tail | head) >= size))
>> + if (unlikely((tail | head) >= size)) {
>> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
>> + head, tail, size);
>> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
>> goto corrupted;
>> -
>> - /* later calculations will be done in dwords */
>> - head /= 4;
>> - tail /= 4;
>> - size /= 4;
>> + }
>> /* tail == head condition indicates empty */
>> available = tail - head;
>> @@ -677,6 +669,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
>> ct_incoming_msg **msg)
>> size - head : available - 1), &cmds[head],
>> 4 * (head + available - 1 > size ?
>> available - 1 - size + head : 0), &cmds[0]);
>> + desc->status |= GUC_CTB_STATUS_UNDERFLOW;
>> goto corrupted;
>> }
>> @@ -699,13 +692,14 @@ static int ct_read(struct intel_guc_ct *ct,
>> struct ct_incoming_msg **msg)
>> }
>> CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
>> - desc->head = head * 4;
>> + /* now update descriptor */
>> + WRITE_ONCE(desc->head, head);
>> +
>> return available - len;
>> corrupted:
>> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u
>> size=%u\n",
>> - desc->addr, desc->head, desc->tail, desc->size);
>> - desc->is_in_error = 1;
>> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>> + desc->head, desc->tail, desc->status);
>> ctb->broken = true;
>> return -EPIPE;
>> }
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> index 7d3cd375d6a7..905202caaad3 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> @@ -31,7 +31,7 @@ struct intel_guc;
>> * @lock: protects access to the commands buffer and buffer descriptor
>> * @desc: pointer to the buffer descriptor
>> * @cmds: pointer to the commands buffer
>> - * @size: size of the commands buffer
>> + * @size: size of the commands buffer in dwords
>> * @broken: flag to indicate if descriptor data is broken
>> */
>> struct intel_guc_ct_buffer {
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor
@ 2021-06-09 18:28 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-09 18:28 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
On 08.06.2021 02:59, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Definition of the CTB descriptor has changed, leaving only
>> minimal shared fields like HEAD/TAIL/STATUS.
>>
>> Both HEAD and TAIL are now in dwords.
>>
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> ---
>> .../gt/uc/abi/guc_communication_ctb_abi.h | 70 ++++++++++++++-----
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 70 +++++++++----------
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
>> 3 files changed, 85 insertions(+), 57 deletions(-)
>>
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index d38935f47ecf..c2a069a78e01 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -7,6 +7,58 @@
>> #define _ABI_GUC_COMMUNICATION_CTB_ABI_H
>> #include <linux/types.h>
>> +#include <linux/build_bug.h>
>> +
>> +#include "guc_messages_abi.h"
>> +
>> +/**
>> + * DOC: CT Buffer
>> + *
>> + * TBD
>
> What's the plan with this TBD here?
Plan was to add some updated text based on old "DOC: CTB based
communication" section
>
>> + */
>> +
>> +/**
>> + * DOC: CTB Descriptor
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31:0 | **HEAD** - offset (in dwords) to the last dword
>> that was |
>> + * | | | read from the `CT
>> Buffer`_. |
>> + * | | | It can only be updated by the
>> receiver. |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:0 | **TAIL** - offset (in dwords) to the last dword
>> that was |
>> + * | | | written to the `CT
>> Buffer`_. |
>> + * | | | It can only be updated by the
>> sender. |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 2 | 31:0 | **STATUS** - status of the
>> CTB |
>> + * | |
>> | |
>> + * | | | - _`GUC_CTB_STATUS_NO_ERROR` = 0 (normal
>> operation) |
>> + * | | | - _`GUC_CTB_STATUS_OVERFLOW` = 1 (head/tail too
>> large) |
>> + * | | | - _`GUC_CTB_STATUS_UNDERFLOW` = 2 (truncated
>> message) |
>> + * | | | - _`GUC_CTB_STATUS_MISMATCH` = 4 (head/tail
>> modified) |
>> + * | | | - _`GUC_CTB_STATUS_NO_BACKCHANNEL` =
>> 8 |
>> + * | | | - _`GUC_CTB_STATUS_MALFORMED_MSG` =
>> 16 |
>
> I don't see the last 2 error (8 & 16) in the 62.0.0 specs. Where is the
> reference for them?
both were discussed on various meetings but likely didn't make into
final spec 62, so for now we can drop them both
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * |...| | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 15| 31:0 | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +
>> +struct guc_ct_buffer_desc {
>> + u32 head;
>> + u32 tail;
>> + u32 status;
>> +#define GUC_CTB_STATUS_NO_ERROR 0
>> +#define GUC_CTB_STATUS_OVERFLOW (1 << 0)
>> +#define GUC_CTB_STATUS_UNDERFLOW (1 << 1)
>> +#define GUC_CTB_STATUS_MISMATCH (1 << 2)
>> +#define GUC_CTB_STATUS_NO_BACKCHANNEL (1 << 3)
>> +#define GUC_CTB_STATUS_MALFORMED_MSG (1 << 4)
>
> use BIT() ?
as explained before, on ABI headers we didn't want any dependency and
just use plain C
>
>> + u32 reserved[13];
>> +} __packed;
>> +static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
>> /**
>> * DOC: CTB based communication
>> @@ -60,24 +112,6 @@
>> * - **flags**, holds various bits to control message handling
>> */
>> -/*
>> - * Describes single command transport buffer.
>> - * Used by both guc-master and clients.
>> - */
>> -struct guc_ct_buffer_desc {
>> - u32 addr; /* gfx address */
>> - u64 host_private; /* host private data */
>> - u32 size; /* size in bytes */
>> - u32 head; /* offset updated by GuC*/
>> - u32 tail; /* offset updated by owner */
>> - u32 is_in_error; /* error indicator */
>> - u32 reserved1;
>> - u32 reserved2;
>> - u32 owner; /* id of the channel owner */
>> - u32 owner_sub_id; /* owner-defined field for extra tracking */
>> - u32 reserved[5];
>> -} __packed;
>> -
>> /* Type of command transport buffer */
>> #define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>> #define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 63056ea0631e..3241a477196f 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -112,32 +112,28 @@ static inline const char
>> *guc_ct_buffer_type_to_str(u32 type)
>> }
>> }
>> -static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc,
>> - u32 cmds_addr, u32 size)
>> +static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
>
> this function is called from only 1 place and only does a memset now, so
> IMO we can just drop it and inline the memset.
ok, but without enthusiasm ;)
>
> The logic below matches the specs.
>
> Daniele
>
>> {
>> memset(desc, 0, sizeof(*desc));
>> - desc->addr = cmds_addr;
>> - desc->size = size;
>> - desc->owner = CTB_OWNER_HOST;
>> }
>> -static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb,
>> u32 cmds_addr)
>> +static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
>> {
>> ctb->broken = false;
>> - guc_ct_buffer_desc_init(ctb->desc, cmds_addr, ctb->size);
>> + guc_ct_buffer_desc_init(ctb->desc);
>> }
>> static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
>> struct guc_ct_buffer_desc *desc,
>> - u32 *cmds, u32 size)
>> + u32 *cmds, u32 size_in_bytes)
>> {
>> - GEM_BUG_ON(size % 4);
>> + GEM_BUG_ON(size_in_bytes % 4);
>> ctb->desc = desc;
>> ctb->cmds = cmds;
>> - ctb->size = size;
>> + ctb->size = size_in_bytes / 4;
>> - guc_ct_buffer_reset(ctb, 0);
>> + guc_ct_buffer_reset(ctb);
>> }
>> static int guc_action_register_ct_buffer(struct intel_guc *guc,
>> @@ -279,10 +275,10 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> /* (re)initialize descriptors */
>> cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> - guc_ct_buffer_reset(&ct->ctbs.send, cmds);
>> + guc_ct_buffer_reset(&ct->ctbs.send);
>> cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> - guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
>> + guc_ct_buffer_reset(&ct->ctbs.recv);
>> /*
>> * Register both CT buffers starting with RECV buffer.
>> @@ -391,17 +387,15 @@ static int ct_write(struct intel_guc_ct *ct,
>> if (unlikely(ctb->broken))
>> return -EPIPE;
>> - if (unlikely(desc->is_in_error))
>> + if (unlikely(desc->status))
>> goto corrupted;
>> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
>> - (tail | head) >= size))
>> + if (unlikely((tail | head) >= size)) {
>> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
>> + head, tail, size);
>> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
>> goto corrupted;
>> -
>> - /* later calculations will be done in dwords */
>> - head /= 4;
>> - tail /= 4;
>> - size /= 4;
>> + }
>> /*
>> * tail == head condition indicates empty. GuC FW does not support
>> @@ -447,14 +441,14 @@ static int ct_write(struct intel_guc_ct *ct,
>> */
>> write_barrier(ct);
>> - /* now update desc tail (back in bytes) */
>> - desc->tail = tail * 4;
>> + /* now update descriptor */
>> + WRITE_ONCE(desc->tail, tail);
>> +
>> return 0;
>> corrupted:
>> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u
>> size=%u\n",
>> - desc->addr, desc->head, desc->tail, desc->size);
>> - desc->is_in_error = 1;
>> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>> + desc->head, desc->tail, desc->status);
>> ctb->broken = true;
>> return -EPIPE;
>> }
>> @@ -640,17 +634,15 @@ static int ct_read(struct intel_guc_ct *ct,
>> struct ct_incoming_msg **msg)
>> if (unlikely(ctb->broken))
>> return -EPIPE;
>> - if (unlikely(desc->is_in_error))
>> + if (unlikely(desc->status))
>> goto corrupted;
>> - if (unlikely(!IS_ALIGNED(head | tail, 4) ||
>> - (tail | head) >= size))
>> + if (unlikely((tail | head) >= size)) {
>> + CT_ERROR(ct, "Invalid offsets head=%u tail=%u (size=%u)\n",
>> + head, tail, size);
>> + desc->status |= GUC_CTB_STATUS_OVERFLOW;
>> goto corrupted;
>> -
>> - /* later calculations will be done in dwords */
>> - head /= 4;
>> - tail /= 4;
>> - size /= 4;
>> + }
>> /* tail == head condition indicates empty */
>> available = tail - head;
>> @@ -677,6 +669,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
>> ct_incoming_msg **msg)
>> size - head : available - 1), &cmds[head],
>> 4 * (head + available - 1 > size ?
>> available - 1 - size + head : 0), &cmds[0]);
>> + desc->status |= GUC_CTB_STATUS_UNDERFLOW;
>> goto corrupted;
>> }
>> @@ -699,13 +692,14 @@ static int ct_read(struct intel_guc_ct *ct,
>> struct ct_incoming_msg **msg)
>> }
>> CT_DEBUG(ct, "received %*ph\n", 4 * len, (*msg)->msg);
>> - desc->head = head * 4;
>> + /* now update descriptor */
>> + WRITE_ONCE(desc->head, head);
>> +
>> return available - len;
>> corrupted:
>> - CT_ERROR(ct, "Corrupted descriptor addr=%#x head=%u tail=%u
>> size=%u\n",
>> - desc->addr, desc->head, desc->tail, desc->size);
>> - desc->is_in_error = 1;
>> + CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
>> + desc->head, desc->tail, desc->status);
>> ctb->broken = true;
>> return -EPIPE;
>> }
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> index 7d3cd375d6a7..905202caaad3 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
>> @@ -31,7 +31,7 @@ struct intel_guc;
>> * @lock: protects access to the commands buffer and buffer descriptor
>> * @desc: pointer to the buffer descriptor
>> * @cmds: pointer to the commands buffer
>> - * @size: size of the commands buffer
>> + * @size: size of the commands buffer in dwords
>> * @broken: flag to indicate if descriptor data is broken
>> */
>> struct intel_guc_ct_buffer {
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-08 1:23 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-09 19:35 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-09 19:35 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
Cc: john.c.harrison
On 08.06.2021 03:23, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>
>> 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 90efef8a73e4..6426fc183692 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
>> @@ -6,6 +6,113 @@
>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>> #define _ABI_GUC_ACTIONS_ABI_H
>> +/**
>> + * DOC: HOST2GUC_REGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_ setup.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>> 0x5200 |
>
> Specs says 4505
but draft was saying 5200 ;)
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type for the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>> 0 |
>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>> 1 |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>> minus 1 |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>> Descriptor`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>> Buffer`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>
> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> at some point I don;t think this deserves a FIXME since nothing is
> incorrect.
patch was prepared based on draft spec and this FIXME was added just as
head-up since we were expecting GuC to make this change soon, but since
we are going with GuC 62 that uses 4505, agree, we need drop this FIXME
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>
> The full mask still seems like overkill to me and I still think we
> should use BIT()/GENMASK() and a _MASK prefix, but not going to block on
> it.
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/**
>> + * DOC: HOST2GUC_DEREGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_
>> teardown.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>> 0x5201 |
>
> Specs says 4506
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type of the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | see
>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME 0x5201
>
> Same comment for the FIXME as above
>
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/* legacy definitions */
>> +
>> enum intel_guc_action {
>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index c2a069a78e01..127b256a662c 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>> == 64);
>> * - **flags**, holds various bits to control message handling
>> */
>> -/* Type of command transport buffer */
>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>> -
>> /*
>> * Definition of the command transport message header (DW0)
>> *
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 3241a477196f..6a29be779cc9 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>> {
>> switch (type) {
>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>> + case GUC_CTB_TYPE_HOST2GUC:
>> return "SEND";
>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>> + case GUC_CTB_TYPE_GUC2HOST:
>> return "RECV";
>> default:
>> return "<invalid>";
>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>> intel_guc_ct_buffer *ctb,
>> guc_ct_buffer_reset(ctb);
>> }
>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>> - u32 desc_addr,
>> - u32 type)
>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>> type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>> - desc_addr,
>> - sizeof(struct guc_ct_buffer_desc),
>> - type
>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>
> IMO we could use a macro or 2 for the HXG header, to avoid all these
> lines, which are hard to read. something like:
>
> GUC_HXG_HEADER(origin, type, data, action) \
> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>
> H2G_HEADER(type, data, action) \
> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>
> and then call
>
> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
note that each message type defines its own bits, so helpers macros will
likely be per type, but still doable (as the future improvement)
#define H2G_REQUEST(action, data) ... \
GUC_ACTION_##action
H2G_REQUEST(HOST2GUC_REGISTER_CTB, 0)
>
>
> Not a blocker.
>
> Daniele
>
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size /
>> SZ_4K - 1) |
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR,
>> desc_addr),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR,
>> buff_addr),
>> };
>> - /* Can't use generic send(), CT registration must go over MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL,
>> 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> + GEM_BUG_ON(size % SZ_4K);
>> +
>> + /* CT registration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>> desc_addr, u32 type)
>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct), desc_addr,
>> type);
>> + int err;
>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>> + desc_addr, buff_addr, size);
>> if (unlikely(err))
>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>> guc_ct_buffer_type_to_str(type), err);
>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>> u32 type)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>> - CTB_OWNER_HOST,
>> - type
>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> };
>> - /* Can't use generic send(), CT deregistration must go over
>> MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL,
>> 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> +
>> + /* CT deregistration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> {
>> struct intel_guc *guc = ct_to_guc(ct);
>> - u32 base, cmds;
>> + u32 base, desc, cmds;
>> void *blob;
>> int err;
>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>> /* (re)initialize descriptors */
>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.send);
>> -
>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.recv);
>> /*
>> * Register both CT buffers starting with RECV buffer.
>> * Descriptors are in first half of the blob.
>> */
>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>> blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>> + desc, cmds, ct->ctbs.recv.size * 4);
>> +
>> if (unlikely(err))
>> goto err_out;
>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc,
>> blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>> + desc, cmds, ct->ctbs.send.size * 4);
>> +
>> if (unlikely(err))
>> goto err_deregister;
>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> return 0;
>> err_deregister:
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> err_out:
>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>> return err;
>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>> ct->enabled = false;
>> if (intel_guc_is_fw_running(guc)) {
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> }
>> }
>>
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-09 19:35 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-09 19:35 UTC (permalink / raw)
To: Daniele Ceraolo Spurio, Matthew Brost, intel-gfx, dri-devel
On 08.06.2021 03:23, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>
>> Definition of the CTB registration action has changed.
>> Add some ABI documentation and implement required changes.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>
>> 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 90efef8a73e4..6426fc183692 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
>> @@ -6,6 +6,113 @@
>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>> #define _ABI_GUC_ACTIONS_ABI_H
>> +/**
>> + * DOC: HOST2GUC_REGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_ setup.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>> 0x5200 |
>
> Specs says 4505
but draft was saying 5200 ;)
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type for the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>> 0 |
>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>> 1 |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>> minus 1 |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>> Descriptor`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>> Buffer`_ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>
> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> at some point I don;t think this deserves a FIXME since nothing is
> incorrect.
patch was prepared based on draft spec and this FIXME was added just as
head-up since we were expecting GuC to make this change soon, but since
we are going with GuC 62 that uses 4505, agree, we need drop this FIXME
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>> GUC_HXG_REQUEST_MSG_n_DATAn
>
> The full mask still seems like overkill to me and I still think we
> should use BIT()/GENMASK() and a _MASK prefix, but not going to block on
> it.
>
>> +
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/**
>> + * DOC: HOST2GUC_DEREGISTER_CTB
>> + *
>> + * This message is used as part of the `CTB based communication`_
>> teardown.
>> + *
>> + * This message must be sent as `MMIO HXG Message`_.
>> + *
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_HOST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_REQUEST_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:16 | DATA0 =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>> 0x5201 |
>
> Specs says 4506
>
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | 1 | 31:12 | RESERVED =
>> MBZ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 11:8 | **TYPE** - type of the `CT
>> Buffer`_ |
>> + * | |
>> | |
>> + * | | | see
>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 7:0 | RESERVED =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> +*
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + * | | Bits |
>> Description |
>> + *
>> +===+=======+==============================================================+
>>
>> + * | 0 | 31 | ORIGIN =
>> GUC_HXG_ORIGIN_GUC_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 30:28 | TYPE =
>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>> + * |
>> +-------+--------------------------------------------------------------+
>> + * | | 27:0 | DATA0 =
>> MBZ |
>> + *
>> +---+-------+--------------------------------------------------------------+
>>
>> + */
>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME 0x5201
>
> Same comment for the FIXME as above
>
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>> GUC_HXG_REQUEST_MSG_0_DATA0
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>> +
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>> GUC_HXG_RESPONSE_MSG_0_DATA0
>> +
>> +/* legacy definitions */
>> +
>> enum intel_guc_action {
>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>> diff --git
>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> index c2a069a78e01..127b256a662c 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>> == 64);
>> * - **flags**, holds various bits to control message handling
>> */
>> -/* Type of command transport buffer */
>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>> -
>> /*
>> * Definition of the command transport message header (DW0)
>> *
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 3241a477196f..6a29be779cc9 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>> {
>> switch (type) {
>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>> + case GUC_CTB_TYPE_HOST2GUC:
>> return "SEND";
>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>> + case GUC_CTB_TYPE_GUC2HOST:
>> return "RECV";
>> default:
>> return "<invalid>";
>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>> intel_guc_ct_buffer *ctb,
>> guc_ct_buffer_reset(ctb);
>> }
>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>> - u32 desc_addr,
>> - u32 type)
>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>> type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>> - desc_addr,
>> - sizeof(struct guc_ct_buffer_desc),
>> - type
>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>
> IMO we could use a macro or 2 for the HXG header, to avoid all these
> lines, which are hard to read. something like:
>
> GUC_HXG_HEADER(origin, type, data, action) \
> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>
> H2G_HEADER(type, data, action) \
> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>
> and then call
>
> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
note that each message type defines its own bits, so helpers macros will
likely be per type, but still doable (as the future improvement)
#define H2G_REQUEST(action, data) ... \
GUC_ACTION_##action
H2G_REQUEST(HOST2GUC_REGISTER_CTB, 0)
>
>
> Not a blocker.
>
> Daniele
>
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size /
>> SZ_4K - 1) |
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR,
>> desc_addr),
>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR,
>> buff_addr),
>> };
>> - /* Can't use generic send(), CT registration must go over MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL,
>> 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> + GEM_BUG_ON(size % SZ_4K);
>> +
>> + /* CT registration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>> desc_addr, u32 type)
>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>> + u32 desc_addr, u32 buff_addr, u32 size)
>> {
>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct), desc_addr,
>> type);
>> + int err;
>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>> + desc_addr, buff_addr, size);
>> if (unlikely(err))
>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>> guc_ct_buffer_type_to_str(type), err);
>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>> u32 type)
>> {
>> - u32 action[] = {
>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>> - CTB_OWNER_HOST,
>> - type
>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>> };
>> - /* Can't use generic send(), CT deregistration must go over
>> MMIO */
>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action), NULL,
>> 0);
>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>> GUC_CTB_TYPE_GUC2HOST);
>> +
>> + /* CT deregistration must go over MMIO */
>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>> NULL, 0);
>> }
>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> {
>> struct intel_guc *guc = ct_to_guc(ct);
>> - u32 base, cmds;
>> + u32 base, desc, cmds;
>> void *blob;
>> int err;
>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>> /* (re)initialize descriptors */
>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.send);
>> -
>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> guc_ct_buffer_reset(&ct->ctbs.recv);
>> /*
>> * Register both CT buffers starting with RECV buffer.
>> * Descriptors are in first half of the blob.
>> */
>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>> blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>> + desc, cmds, ct->ctbs.recv.size * 4);
>> +
>> if (unlikely(err))
>> goto err_out;
>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc,
>> blob),
>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>> + desc, cmds, ct->ctbs.send.size * 4);
>> +
>> if (unlikely(err))
>> goto err_deregister;
>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>> return 0;
>> err_deregister:
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> err_out:
>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>> return err;
>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>> ct->enabled = false;
>> if (intel_guc_is_fw_running(guc)) {
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>> }
>> }
>>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-09 17:36 ` [Intel-gfx] " John Harrison
@ 2021-06-09 20:07 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-09 20:07 UTC (permalink / raw)
To: John Harrison, Daniele Ceraolo Spurio, Matthew Brost, intel-gfx,
dri-devel
On 09.06.2021 19:36, John Harrison wrote:
> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>
>>> Definition of the CTB registration action has changed.
>>> Add some ABI documentation and implement required changes.
>>>
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>>> ---
>>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>>
>>> 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 90efef8a73e4..6426fc183692 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
>>> @@ -6,6 +6,113 @@
>>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>>> #define _ABI_GUC_ACTIONS_ABI_H
>>> +/**
>>> + * DOC: HOST2GUC_REGISTER_CTB
>>> + *
>>> + * This message is used as part of the `CTB based communication`_
>>> setup.
>>> + *
>>> + * This message must be sent as `MMIO HXG Message`_.
>>> + *
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_HOST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_REQUEST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:16 | DATA0 =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>>> 0x5200 |
>>
>> Specs says 4505
>>
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 1 | 31:12 | RESERVED =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 11:8 | **TYPE** - type for the `CT
>>> Buffer`_ |
>>> + * | |
>>> | |
>>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>>> 0 |
>>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>>> 1 |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>>> minus 1 |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>>> Descriptor`_ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>>> Buffer`_ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> +*
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_GUC_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:0 | DATA0 =
>>> MBZ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + */
>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>>
>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
>> at some point I don;t think this deserves a FIXME since nothing is
>> incorrect.
>>
>>> +
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>
>> The full mask still seems like overkill to me and I still think we
>> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
>> on it.
>>
>>> +
>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>> +
>>> +/**
>>> + * DOC: HOST2GUC_DEREGISTER_CTB
>>> + *
>>> + * This message is used as part of the `CTB based communication`_
>>> teardown.
>>> + *
>>> + * This message must be sent as `MMIO HXG Message`_.
>>> + *
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_HOST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_REQUEST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:16 | DATA0 =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>>> 0x5201 |
>>
>> Specs says 4506
>>
> I would say that the enum value should not be included in the structure
> definition. I would also argue that there is no point in repeating the
> common header structure for every single H2G action definition. That is
> just overly verbose and makes it harder to read the spec. It implies
> that every action has a different header structure and must be coded
> individually.
but some actions are defined as REQUEST some as EVENT, so we need to say
that, also each REQUEST action may define its own DATA0, so again we
still need to define these bits somewhere
>
> Personally, I don't believe we should be replicating the entire GuC API
> spec in the driver header files anyway. This is not something that is
> defined by the i915 driver so the i915 driver should not be defining it!
> Instead, just include a link or pointer to where the actual spec can be
> found. We don't copy the entire bspec page for every register that the
> driver touches, so why should this be any different?
to some extend we have to replicate at least part of the GuC ABI spec,
part that defines all bits, and IMHO there is nothing wrong if it comes
with full message layout definitions, especially if you compare that
with previous approach, were H2G action definitions were limited just to
single enum value (and to find out how to use given H2G you had to look
into firmware source code)
so while we keep these abi.h files in kernel repo, they shall be treated
as read-only imported external interface definitions, from which we just
use all #define for coding and DOC: for documentation (latter at least
until GuC will release its spec to the public)
>
> John.
>
>
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 1 | 31:12 | RESERVED =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 11:8 | **TYPE** - type of the `CT
>>> Buffer`_ |
>>> + * | |
>>> | |
>>> + * | | | see
>>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 7:0 | RESERVED =
>>> MBZ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> +*
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_GUC_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:0 | DATA0 =
>>> MBZ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + */
>>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
>>> 0x5201
>>
>> Same comment for the FIXME as above
>>
>>> +
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>>> +
>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>> +
>>> +/* legacy definitions */
>>> +
>>> enum intel_guc_action {
>>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>>> diff --git
>>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> index c2a069a78e01..127b256a662c 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>>> == 64);
>>> * - **flags**, holds various bits to control message handling
>>> */
>>> -/* Type of command transport buffer */
>>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>>> -
>>> /*
>>> * Definition of the command transport message header (DW0)
>>> *
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index 3241a477196f..6a29be779cc9 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
>>> *ct)
>>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>>> {
>>> switch (type) {
>>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>>> + case GUC_CTB_TYPE_HOST2GUC:
>>> return "SEND";
>>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>>> + case GUC_CTB_TYPE_GUC2HOST:
>>> return "RECV";
>>> default:
>>> return "<invalid>";
>>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>>> intel_guc_ct_buffer *ctb,
>>> guc_ct_buffer_reset(ctb);
>>> }
>>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>>> - u32 desc_addr,
>>> - u32 type)
>>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>>> type,
>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>> {
>>> - u32 action[] = {
>>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>>> - desc_addr,
>>> - sizeof(struct guc_ct_buffer_desc),
>>> - type
>>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>>
>> IMO we could use a macro or 2 for the HXG header, to avoid all these
>> lines, which are hard to read. something like:
>>
>> GUC_HXG_HEADER(origin, type, data, action) \
>> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
>> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
>> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
>> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>>
>> H2G_HEADER(type, data, action) \
>> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>>
>> and then call
>>
>> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
>>
>>
>> Not a blocker.
>>
>> Daniele
>>
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
>>> 1) |
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
>>> };
>>> - /* Can't use generic send(), CT registration must go over MMIO */
>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>> NULL, 0);
>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>> GUC_CTB_TYPE_GUC2HOST);
>>> + GEM_BUG_ON(size % SZ_4K);
>>> +
>>> + /* CT registration must go over MMIO */
>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>> NULL, 0);
>>> }
>>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>>> desc_addr, u32 type)
>>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>> {
>>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
>>> desc_addr, type);
>>> + int err;
>>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>>> + desc_addr, buff_addr, size);
>>> if (unlikely(err))
>>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>>> guc_ct_buffer_type_to_str(type), err);
>>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>>> u32 type)
>>> {
>>> - u32 action[] = {
>>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>>> - CTB_OWNER_HOST,
>>> - type
>>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>> };
>>> - /* Can't use generic send(), CT deregistration must go over
>>> MMIO */
>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>> NULL, 0);
>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>> GUC_CTB_TYPE_GUC2HOST);
>>> +
>>> + /* CT deregistration must go over MMIO */
>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>> NULL, 0);
>>> }
>>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>> {
>>> struct intel_guc *guc = ct_to_guc(ct);
>>> - u32 base, cmds;
>>> + u32 base, desc, cmds;
>>> void *blob;
>>> int err;
>>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>>> /* (re)initialize descriptors */
>>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>> guc_ct_buffer_reset(&ct->ctbs.send);
>>> -
>>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>> guc_ct_buffer_reset(&ct->ctbs.recv);
>>> /*
>>> * Register both CT buffers starting with RECV buffer.
>>> * Descriptors are in first half of the blob.
>>> */
>>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>>> blob),
>>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>>> + desc, cmds, ct->ctbs.recv.size * 4);
>>> +
>>> if (unlikely(err))
>>> goto err_out;
>>> - err = ct_register_buffer(ct, base +
>>> ptrdiff(ct->ctbs.send.desc, blob),
>>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>>> + desc, cmds, ct->ctbs.send.size * 4);
>>> +
>>> if (unlikely(err))
>>> goto err_deregister;
>>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>> return 0;
>>> err_deregister:
>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>> err_out:
>>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>>> return err;
>>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>>> ct->enabled = false;
>>> if (intel_guc_is_fw_running(guc)) {
>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>> }
>>> }
>>
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-09 20:07 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-09 20:07 UTC (permalink / raw)
To: John Harrison, Daniele Ceraolo Spurio, Matthew Brost, intel-gfx,
dri-devel
On 09.06.2021 19:36, John Harrison wrote:
> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>
>>> Definition of the CTB registration action has changed.
>>> Add some ABI documentation and implement required changes.
>>>
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>>> ---
>>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>>
>>> 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 90efef8a73e4..6426fc183692 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
>>> @@ -6,6 +6,113 @@
>>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>>> #define _ABI_GUC_ACTIONS_ABI_H
>>> +/**
>>> + * DOC: HOST2GUC_REGISTER_CTB
>>> + *
>>> + * This message is used as part of the `CTB based communication`_
>>> setup.
>>> + *
>>> + * This message must be sent as `MMIO HXG Message`_.
>>> + *
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_HOST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_REQUEST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:16 | DATA0 =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>>> 0x5200 |
>>
>> Specs says 4505
>>
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 1 | 31:12 | RESERVED =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 11:8 | **TYPE** - type for the `CT
>>> Buffer`_ |
>>> + * | |
>>> | |
>>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>>> 0 |
>>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>>> 1 |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>>> minus 1 |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>>> Descriptor`_ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>>> Buffer`_ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> +*
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_GUC_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:0 | DATA0 =
>>> MBZ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + */
>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>>
>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
>> at some point I don;t think this deserves a FIXME since nothing is
>> incorrect.
>>
>>> +
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>
>> The full mask still seems like overkill to me and I still think we
>> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
>> on it.
>>
>>> +
>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>> +
>>> +/**
>>> + * DOC: HOST2GUC_DEREGISTER_CTB
>>> + *
>>> + * This message is used as part of the `CTB based communication`_
>>> teardown.
>>> + *
>>> + * This message must be sent as `MMIO HXG Message`_.
>>> + *
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_HOST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_REQUEST_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:16 | DATA0 =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>>> 0x5201 |
>>
>> Specs says 4506
>>
> I would say that the enum value should not be included in the structure
> definition. I would also argue that there is no point in repeating the
> common header structure for every single H2G action definition. That is
> just overly verbose and makes it harder to read the spec. It implies
> that every action has a different header structure and must be coded
> individually.
but some actions are defined as REQUEST some as EVENT, so we need to say
that, also each REQUEST action may define its own DATA0, so again we
still need to define these bits somewhere
>
> Personally, I don't believe we should be replicating the entire GuC API
> spec in the driver header files anyway. This is not something that is
> defined by the i915 driver so the i915 driver should not be defining it!
> Instead, just include a link or pointer to where the actual spec can be
> found. We don't copy the entire bspec page for every register that the
> driver touches, so why should this be any different?
to some extend we have to replicate at least part of the GuC ABI spec,
part that defines all bits, and IMHO there is nothing wrong if it comes
with full message layout definitions, especially if you compare that
with previous approach, were H2G action definitions were limited just to
single enum value (and to find out how to use given H2G you had to look
into firmware source code)
so while we keep these abi.h files in kernel repo, they shall be treated
as read-only imported external interface definitions, from which we just
use all #define for coding and DOC: for documentation (latter at least
until GuC will release its spec to the public)
>
> John.
>
>
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | 1 | 31:12 | RESERVED =
>>> MBZ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 11:8 | **TYPE** - type of the `CT
>>> Buffer`_ |
>>> + * | |
>>> | |
>>> + * | | | see
>>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 7:0 | RESERVED =
>>> MBZ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> +*
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + * | | Bits |
>>> Description |
>>> + *
>>> +===+=======+==============================================================+
>>>
>>> + * | 0 | 31 | ORIGIN =
>>> GUC_HXG_ORIGIN_GUC_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 30:28 | TYPE =
>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>> + * |
>>> +-------+--------------------------------------------------------------+
>>> + * | | 27:0 | DATA0 =
>>> MBZ |
>>> + *
>>> +---+-------+--------------------------------------------------------------+
>>>
>>> + */
>>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
>>> 0x5201
>>
>> Same comment for the FIXME as above
>>
>>> +
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>>> +
>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>> +
>>> +/* legacy definitions */
>>> +
>>> enum intel_guc_action {
>>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>>> diff --git
>>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> index c2a069a78e01..127b256a662c 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>>> == 64);
>>> * - **flags**, holds various bits to control message handling
>>> */
>>> -/* Type of command transport buffer */
>>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>>> -
>>> /*
>>> * Definition of the command transport message header (DW0)
>>> *
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index 3241a477196f..6a29be779cc9 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
>>> *ct)
>>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>>> {
>>> switch (type) {
>>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>>> + case GUC_CTB_TYPE_HOST2GUC:
>>> return "SEND";
>>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>>> + case GUC_CTB_TYPE_GUC2HOST:
>>> return "RECV";
>>> default:
>>> return "<invalid>";
>>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>>> intel_guc_ct_buffer *ctb,
>>> guc_ct_buffer_reset(ctb);
>>> }
>>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>>> - u32 desc_addr,
>>> - u32 type)
>>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>>> type,
>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>> {
>>> - u32 action[] = {
>>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>>> - desc_addr,
>>> - sizeof(struct guc_ct_buffer_desc),
>>> - type
>>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>>
>> IMO we could use a macro or 2 for the HXG header, to avoid all these
>> lines, which are hard to read. something like:
>>
>> GUC_HXG_HEADER(origin, type, data, action) \
>> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
>> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
>> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
>> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>>
>> H2G_HEADER(type, data, action) \
>> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>>
>> and then call
>>
>> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
>>
>>
>> Not a blocker.
>>
>> Daniele
>>
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
>>> 1) |
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
>>> };
>>> - /* Can't use generic send(), CT registration must go over MMIO */
>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>> NULL, 0);
>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>> GUC_CTB_TYPE_GUC2HOST);
>>> + GEM_BUG_ON(size % SZ_4K);
>>> +
>>> + /* CT registration must go over MMIO */
>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>> NULL, 0);
>>> }
>>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>>> desc_addr, u32 type)
>>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>> {
>>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
>>> desc_addr, type);
>>> + int err;
>>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>>> + desc_addr, buff_addr, size);
>>> if (unlikely(err))
>>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>>> guc_ct_buffer_type_to_str(type), err);
>>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>>> u32 type)
>>> {
>>> - u32 action[] = {
>>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>>> - CTB_OWNER_HOST,
>>> - type
>>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>> };
>>> - /* Can't use generic send(), CT deregistration must go over
>>> MMIO */
>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>> NULL, 0);
>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>> GUC_CTB_TYPE_GUC2HOST);
>>> +
>>> + /* CT deregistration must go over MMIO */
>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>> NULL, 0);
>>> }
>>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>> {
>>> struct intel_guc *guc = ct_to_guc(ct);
>>> - u32 base, cmds;
>>> + u32 base, desc, cmds;
>>> void *blob;
>>> int err;
>>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>>> /* (re)initialize descriptors */
>>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>> guc_ct_buffer_reset(&ct->ctbs.send);
>>> -
>>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>> guc_ct_buffer_reset(&ct->ctbs.recv);
>>> /*
>>> * Register both CT buffers starting with RECV buffer.
>>> * Descriptors are in first half of the blob.
>>> */
>>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>>> blob),
>>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>>> + desc, cmds, ct->ctbs.recv.size * 4);
>>> +
>>> if (unlikely(err))
>>> goto err_out;
>>> - err = ct_register_buffer(ct, base +
>>> ptrdiff(ct->ctbs.send.desc, blob),
>>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>>> + desc, cmds, ct->ctbs.send.size * 4);
>>> +
>>> if (unlikely(err))
>>> goto err_deregister;
>>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>> return 0;
>>> err_deregister:
>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>> err_out:
>>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>>> return err;
>>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>>> ct->enabled = false;
>>> if (intel_guc_is_fw_running(guc)) {
>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>> }
>>> }
>>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 08/13] drm/i915/guc: New CTB based communication
2021-06-08 2:20 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-10 4:01 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-10 4:01 UTC (permalink / raw)
To: Daniele Ceraolo Spurio
Cc: intel-gfx, john.c.harrison, dri-devel, Michal.Wajdeczko
On Mon, Jun 07, 2021 at 07:20:01PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >
> > Format of the CTB messages has changed:
> > - support for multiple formats
> > - message fence is now part of the header
> > - reuse of unified HXG message formats
> >
> > Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> > ---
> > .../gt/uc/abi/guc_communication_ctb_abi.h | 56 +++++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++++++-----------
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
> > 3 files changed, 135 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > index 127b256a662c..92660726c094 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > @@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
> > } __packed;
> > static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> > +/**
> > + * DOC: CTB Message
> > + *
> > + * +---+-------+--------------------------------------------------------------+
> > + * | | Bits | Description |
> > + * +===+=======+==============================================================+
> > + * | 0 | 31:16 | **FENCE** - message identifier |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 15:12 | **FORMAT** - format of the CTB message |
> > + * | | | - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_ |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 11:8 | **RESERVED** |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 7:0 | **NUM_DWORDS** - length of the CTB message (w/o header) |
> > + * +---+-------+--------------------------------------------------------------+
> > + * | 1 | 31:0 | optional (depends on FORMAT) |
> > + * +---+-------+ |
> > + * |...| | |
> > + * +---+-------+ |
> > + * | n | 31:0 | |
> > + * +---+-------+--------------------------------------------------------------+
> > + */
> > +
> > +#define GUC_CTB_MSG_MIN_LEN 1u
> > +#define GUC_CTB_MSG_MAX_LEN 256u
> > +#define GUC_CTB_MSG_0_FENCE (0xffff << 16)
> > +#define GUC_CTB_MSG_0_FORMAT (0xf << 12)
> > +#define GUC_CTB_FORMAT_HXG 0u
> > +#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
> > +#define GUC_CTB_MSG_0_NUM_DWORDS (0xff << 0)
> > +
> > +/**
> > + * DOC: CTB HXG Message
> > + *
> > + * +---+-------+--------------------------------------------------------------+
> > + * | | Bits | Description |
> > + * +===+=======+==============================================================+
> > + * | 0 | 31:16 | FENCE |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 11:8 | RESERVED = MBZ |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message |
> > + * +---+-------+--------------------------------------------------------------+
> > + * | 1 | 31:0 | +--------------------------------------------------------+ |
> > + * +---+-------+ | | |
> > + * |...| | | Embedded `HXG Message`_ | |
> > + * +---+-------+ | | |
> > + * | n | 31:0 | +--------------------------------------------------------+ |
> > + * +---+-------+--------------------------------------------------------------+
> > + */
> > +
> > +#define GUC_CTB_HXG_MSG_MIN_LEN (GUC_CTB_MSG_MIN_LEN + GUC_HXG_MSG_MIN_LEN)
> > +#define GUC_CTB_HXG_MSG_MAX_LEN GUC_CTB_MSG_MAX_LEN
> > +
> > /**
> > * DOC: CTB based communication
> > *
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 6a29be779cc9..729f29bc2a57 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
> > }
> > }
> > -/**
> > - * DOC: CTB Host to GuC request
> > - *
> > - * Format of the CTB Host to GuC request message is as follows::
> > - *
> > - * +------------+---------+---------+---------+---------+
> > - * | msg[0] | [1] | [2] | ... | [n-1] |
> > - * +------------+---------+---------+---------+---------+
> > - * | MESSAGE | MESSAGE PAYLOAD |
> > - * + HEADER +---------+---------+---------+---------+
> > - * | | 0 | 1 | ... | n |
> > - * +============+=========+=========+=========+=========+
> > - * | len >= 1 | FENCE | request specific data |
> > - * +------+-----+---------+---------+---------+---------+
> > - *
> > - * ^-----------------len-------------------^
> > - */
> > -
> > static int ct_write(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len /* in dwords */,
> > @@ -395,6 +377,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > u32 size = ctb->size;
> > u32 used;
> > u32 header;
> > + u32 hxg;
> > u32 *cmds = ctb->cmds;
> > unsigned int i;
> > @@ -425,22 +408,24 @@ static int ct_write(struct intel_guc_ct *ct,
> > return -ENOSPC;
>
> Doesn't the free space math up here need updating, since now we have an
> extra header dword?
>
No, action[0] is included in the HXG header so the match is the same.
I will update the comment below to better relect this.
> > /*
> > - * Write the message. The format is the following:
> > - * DW0: header (including action code)
> > - * DW1: fence
> > - * DW2+: action data
> > + * dw0: CT header (including fence)
> > + * dw1: HXG header
>
> maybe better as:
>
> * dw1+: HXG message
Going to be:
/*
* dw0: CT header (including fence)
* dw1: HXG header (including action code)
* dw2+: action data
*/
>
> > */
> > - header = (len << GUC_CT_MSG_LEN_SHIFT) |
> > - GUC_CT_MSG_SEND_STATUS |
> > - (action[0] << GUC_CT_MSG_ACTION_SHIFT);
> > + header = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
> > + FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> > + FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> > +
> > + hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>
> Do we have a case where we might want to use a different type? e.g. a
> response to a request from GuC?
>
> > + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
>
> See macro suggestion for the hxg header in previous patch review.
>
Michal says we can do in follow, I agree with him on that.
> > - CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
> > - 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
> > + CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
> > + tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
> > cmds[tail] = header;
> > tail = (tail + 1) % size;
> > - cmds[tail] = fence;
> > + cmds[tail] = hxg;
> > tail = (tail + 1) % size;
> > for (i = 1; i < len; i++) {
> > @@ -598,21 +583,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
> > return ret;
> > }
> > -static inline unsigned int ct_header_get_len(u32 header)
> > -{
> > - return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
> > -}
> > -
> > -static inline unsigned int ct_header_get_action(u32 header)
> > -{
> > - return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
> > -}
> > -
> > -static inline bool ct_header_is_response(u32 header)
> > -{
> > - return !!(header & GUC_CT_MSG_IS_RESPONSE);
> > -}
> > -
> > static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
> > {
> > struct ct_incoming_msg *msg;
> > @@ -675,7 +645,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> > head = (head + 1) % size;
> > /* message len with header */
> > - len = ct_header_get_len(header) + 1;
> > + len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, header) + GUC_CTB_MSG_MIN_LEN;
> > if (unlikely(len > (u32)available)) {
> > CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
> > 4, &header,
> > @@ -718,55 +688,24 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> > return -EPIPE;
> > }
> > -/**
> > - * DOC: CTB GuC to Host response
> > - *
> > - * Format of the CTB GuC to Host response message is as follows::
> > - *
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | MESSAGE | MESSAGE PAYLOAD |
> > - * + HEADER +---------+---------+---------+---------+---------+
> > - * | | 0 | 1 | 2 | ... | n |
> > - * +============+=========+=========+=========+=========+=========+
> > - * | len >= 2 | FENCE | STATUS | response specific data |
> > - * +------+-----+---------+---------+---------+---------+---------+
> > - *
> > - * ^-----------------------len-----------------------^
> > - */
> > -
> > static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *response)
> > {
> > - u32 header = response->msg[0];
> > - u32 len = ct_header_get_len(header);
> > - u32 fence;
> > - u32 status;
> > - u32 datalen;
> > + u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
> > + u32 fence = FIELD_GET(GUC_CTB_MSG_0_FENCE, response->msg[0]);
> > + const u32 *hxg = &response->msg[GUC_CTB_MSG_MIN_LEN];
>
> IMO it'd be better to just save the hxg in the msg field. We can save the
> fence as an extra field in the ct_incoming_msg. That way we won't have to
> convert from CTB to HXG in multiple places in the code (I count 4 total in
> this patch).
>
Not really sure I follow this but assume this isn't a blocker as this not
a functional change. We can always revisit in a follow up.
Matt
> Daniele
>
> > + const u32 *data = &hxg[GUC_HXG_MSG_MIN_LEN];
> > + u32 datalen = len - GUC_HXG_MSG_MIN_LEN;
> > struct ct_request *req;
> > unsigned long flags;
> > bool found = false;
> > int err = 0;
> > - GEM_BUG_ON(!ct_header_is_response(header));
> > + GEM_BUG_ON(len < GUC_HXG_MSG_MIN_LEN);
> > + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]) != GUC_HXG_ORIGIN_GUC);
> > + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_SUCCESS &&
> > + FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_FAILURE);
> > - /* Response payload shall at least include fence and status */
> > - if (unlikely(len < 2)) {
> > - CT_ERROR(ct, "Corrupted response (len %u)\n", len);
> > - return -EPROTO;
> > - }
> > -
> > - fence = response->msg[1];
> > - status = response->msg[2];
> > - datalen = len - 2;
> > -
> > - /* Format of the status dword follows HXG header */
> > - if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
> > - CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
> > - return -EPROTO;
> > - }
> > -
> > - CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
> > + CT_DEBUG(ct, "response fence %u status %#x\n", fence, hxg[0]);
> > spin_lock_irqsave(&ct->requests.lock, flags);
> > list_for_each_entry(req, &ct->requests.pending, link) {
> > @@ -782,9 +721,9 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> > err = -EMSGSIZE;
> > }
> > if (datalen)
> > - memcpy(req->response_buf, response->msg + 3, 4 * datalen);
> > + memcpy(req->response_buf, data, 4 * datalen);
> > req->response_len = datalen;
> > - WRITE_ONCE(req->status, status);
> > + WRITE_ONCE(req->status, hxg[0]);
> > found = true;
> > break;
> > }
> > @@ -805,14 +744,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> > static int ct_process_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> > {
> > struct intel_guc *guc = ct_to_guc(ct);
> > - u32 header, action, len;
> > + const u32 *hxg;
> > const u32 *payload;
> > + u32 hxg_len, action, len;
> > int ret;
> > - header = request->msg[0];
> > - payload = &request->msg[1];
> > - action = ct_header_get_action(header);
> > - len = ct_header_get_len(header);
> > + hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> > + hxg_len = request->size - GUC_CTB_MSG_MIN_LEN;
> > + payload = &hxg[GUC_HXG_MSG_MIN_LEN];
> > + action = FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION, hxg[0]);
> > + len = hxg_len - GUC_HXG_MSG_MIN_LEN;
> > CT_DEBUG(ct, "request %x %*ph\n", action, 4 * len, payload);
> > @@ -874,29 +815,12 @@ static void ct_incoming_request_worker_func(struct work_struct *w)
> > queue_work(system_unbound_wq, &ct->requests.worker);
> > }
> > -/**
> > - * DOC: CTB GuC to Host request
> > - *
> > - * Format of the CTB GuC to Host request message is as follows::
> > - *
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | MESSAGE | MESSAGE PAYLOAD |
> > - * + HEADER +---------+---------+---------+---------+---------+
> > - * | | 0 | 1 | 2 | ... | n |
> > - * +============+=========+=========+=========+=========+=========+
> > - * | len | request specific data |
> > - * +------+-----+---------+---------+---------+---------+---------+
> > - *
> > - * ^-----------------------len-----------------------^
> > - */
> > -
> > -static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> > +static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> > {
> > + const u32 *hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> > unsigned long flags;
> > - GEM_BUG_ON(ct_header_is_response(request->msg[0]));
> > + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_EVENT);
> > spin_lock_irqsave(&ct->requests.lock, flags);
> > list_add_tail(&request->link, &ct->requests.incoming);
> > @@ -906,15 +830,53 @@ static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *re
> > return 0;
> > }
> > -static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> > +static int ct_handle_hxg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> > {
> > - u32 header = msg->msg[0];
> > + u32 origin, type;
> > + u32 *hxg;
> > int err;
> > - if (ct_header_is_response(header))
> > + if (unlikely(msg->size < GUC_CTB_HXG_MSG_MIN_LEN))
> > + return -EBADMSG;
> > +
> > + hxg = &msg->msg[GUC_CTB_MSG_MIN_LEN];
> > +
> > + origin = FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]);
> > + if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
> > + err = -EPROTO;
> > + goto failed;
> > + }
> > +
> > + type = FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]);
> > + switch (type) {
> > + case GUC_HXG_TYPE_EVENT:
> > + err = ct_handle_event(ct, msg);
> > + break;
> > + case GUC_HXG_TYPE_RESPONSE_SUCCESS:
> > + case GUC_HXG_TYPE_RESPONSE_FAILURE:
> > err = ct_handle_response(ct, msg);
> > + break;
> > + default:
> > + err = -EOPNOTSUPP;
> > + }
> > +
> > + if (unlikely(err)) {
> > +failed:
> > + CT_ERROR(ct, "Failed to handle HXG message (%pe) %*ph\n",
> > + ERR_PTR(err), 4 * GUC_HXG_MSG_MIN_LEN, hxg);
> > + }
> > + return err;
> > +}
> > +
> > +static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> > +{
> > + u32 format = FIELD_GET(GUC_CTB_MSG_0_FORMAT, msg->msg[0]);
> > + int err;
> > +
> > + if (format == GUC_CTB_FORMAT_HXG)
> > + err = ct_handle_hxg(ct, msg);
> > else
> > - err = ct_handle_request(ct, msg);
> > + err = -EOPNOTSUPP;
> > if (unlikely(err)) {
> > CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > index 905202caaad3..1ae2dde6db93 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > @@ -61,7 +61,7 @@ struct intel_guc_ct {
> > struct tasklet_struct receive_tasklet;
> > struct {
> > - u32 last_fence; /* last fence used to send request */
> > + u16 last_fence; /* last fence used to send request */
> > spinlock_t lock; /* protects pending requests list */
> > struct list_head pending; /* requests waiting for response */
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 08/13] drm/i915/guc: New CTB based communication
@ 2021-06-10 4:01 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-10 4:01 UTC (permalink / raw)
To: Daniele Ceraolo Spurio; +Cc: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 07:20:01PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >
> > Format of the CTB messages has changed:
> > - support for multiple formats
> > - message fence is now part of the header
> > - reuse of unified HXG message formats
> >
> > Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> > ---
> > .../gt/uc/abi/guc_communication_ctb_abi.h | 56 +++++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 194 +++++++-----------
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 +-
> > 3 files changed, 135 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > index 127b256a662c..92660726c094 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> > @@ -60,6 +60,62 @@ struct guc_ct_buffer_desc {
> > } __packed;
> > static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> > +/**
> > + * DOC: CTB Message
> > + *
> > + * +---+-------+--------------------------------------------------------------+
> > + * | | Bits | Description |
> > + * +===+=======+==============================================================+
> > + * | 0 | 31:16 | **FENCE** - message identifier |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 15:12 | **FORMAT** - format of the CTB message |
> > + * | | | - _`GUC_CTB_FORMAT_HXG` = 0 - see `CTB HXG Message`_ |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 11:8 | **RESERVED** |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 7:0 | **NUM_DWORDS** - length of the CTB message (w/o header) |
> > + * +---+-------+--------------------------------------------------------------+
> > + * | 1 | 31:0 | optional (depends on FORMAT) |
> > + * +---+-------+ |
> > + * |...| | |
> > + * +---+-------+ |
> > + * | n | 31:0 | |
> > + * +---+-------+--------------------------------------------------------------+
> > + */
> > +
> > +#define GUC_CTB_MSG_MIN_LEN 1u
> > +#define GUC_CTB_MSG_MAX_LEN 256u
> > +#define GUC_CTB_MSG_0_FENCE (0xffff << 16)
> > +#define GUC_CTB_MSG_0_FORMAT (0xf << 12)
> > +#define GUC_CTB_FORMAT_HXG 0u
> > +#define GUC_CTB_MSG_0_RESERVED (0xf << 8)
> > +#define GUC_CTB_MSG_0_NUM_DWORDS (0xff << 0)
> > +
> > +/**
> > + * DOC: CTB HXG Message
> > + *
> > + * +---+-------+--------------------------------------------------------------+
> > + * | | Bits | Description |
> > + * +===+=======+==============================================================+
> > + * | 0 | 31:16 | FENCE |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 15:12 | FORMAT = GUC_CTB_FORMAT_HXG_ |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 11:8 | RESERVED = MBZ |
> > + * | +-------+--------------------------------------------------------------+
> > + * | | 7:0 | NUM_DWORDS = length (in dwords) of the embedded HXG message |
> > + * +---+-------+--------------------------------------------------------------+
> > + * | 1 | 31:0 | +--------------------------------------------------------+ |
> > + * +---+-------+ | | |
> > + * |...| | | Embedded `HXG Message`_ | |
> > + * +---+-------+ | | |
> > + * | n | 31:0 | +--------------------------------------------------------+ |
> > + * +---+-------+--------------------------------------------------------------+
> > + */
> > +
> > +#define GUC_CTB_HXG_MSG_MIN_LEN (GUC_CTB_MSG_MIN_LEN + GUC_HXG_MSG_MIN_LEN)
> > +#define GUC_CTB_HXG_MSG_MAX_LEN GUC_CTB_MSG_MAX_LEN
> > +
> > /**
> > * DOC: CTB based communication
> > *
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 6a29be779cc9..729f29bc2a57 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -365,24 +365,6 @@ static void write_barrier(struct intel_guc_ct *ct)
> > }
> > }
> > -/**
> > - * DOC: CTB Host to GuC request
> > - *
> > - * Format of the CTB Host to GuC request message is as follows::
> > - *
> > - * +------------+---------+---------+---------+---------+
> > - * | msg[0] | [1] | [2] | ... | [n-1] |
> > - * +------------+---------+---------+---------+---------+
> > - * | MESSAGE | MESSAGE PAYLOAD |
> > - * + HEADER +---------+---------+---------+---------+
> > - * | | 0 | 1 | ... | n |
> > - * +============+=========+=========+=========+=========+
> > - * | len >= 1 | FENCE | request specific data |
> > - * +------+-----+---------+---------+---------+---------+
> > - *
> > - * ^-----------------len-------------------^
> > - */
> > -
> > static int ct_write(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len /* in dwords */,
> > @@ -395,6 +377,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > u32 size = ctb->size;
> > u32 used;
> > u32 header;
> > + u32 hxg;
> > u32 *cmds = ctb->cmds;
> > unsigned int i;
> > @@ -425,22 +408,24 @@ static int ct_write(struct intel_guc_ct *ct,
> > return -ENOSPC;
>
> Doesn't the free space math up here need updating, since now we have an
> extra header dword?
>
No, action[0] is included in the HXG header so the match is the same.
I will update the comment below to better relect this.
> > /*
> > - * Write the message. The format is the following:
> > - * DW0: header (including action code)
> > - * DW1: fence
> > - * DW2+: action data
> > + * dw0: CT header (including fence)
> > + * dw1: HXG header
>
> maybe better as:
>
> * dw1+: HXG message
Going to be:
/*
* dw0: CT header (including fence)
* dw1: HXG header (including action code)
* dw2+: action data
*/
>
> > */
> > - header = (len << GUC_CT_MSG_LEN_SHIFT) |
> > - GUC_CT_MSG_SEND_STATUS |
> > - (action[0] << GUC_CT_MSG_ACTION_SHIFT);
> > + header = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
> > + FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
> > + FIELD_PREP(GUC_CTB_MSG_0_FENCE, fence);
> > +
> > + hxg = FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>
> Do we have a case where we might want to use a different type? e.g. a
> response to a request from GuC?
>
> > + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION |
> > + GUC_HXG_REQUEST_MSG_0_DATA0, action[0]);
>
> See macro suggestion for the hxg header in previous patch review.
>
Michal says we can do in follow, I agree with him on that.
> > - CT_DEBUG(ct, "writing %*ph %*ph %*ph\n",
> > - 4, &header, 4, &fence, 4 * (len - 1), &action[1]);
> > + CT_DEBUG(ct, "writing (tail %u) %*ph %*ph %*ph\n",
> > + tail, 4, &header, 4, &hxg, 4 * (len - 1), &action[1]);
> > cmds[tail] = header;
> > tail = (tail + 1) % size;
> > - cmds[tail] = fence;
> > + cmds[tail] = hxg;
> > tail = (tail + 1) % size;
> > for (i = 1; i < len; i++) {
> > @@ -598,21 +583,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32 *action, u32 len,
> > return ret;
> > }
> > -static inline unsigned int ct_header_get_len(u32 header)
> > -{
> > - return (header >> GUC_CT_MSG_LEN_SHIFT) & GUC_CT_MSG_LEN_MASK;
> > -}
> > -
> > -static inline unsigned int ct_header_get_action(u32 header)
> > -{
> > - return (header >> GUC_CT_MSG_ACTION_SHIFT) & GUC_CT_MSG_ACTION_MASK;
> > -}
> > -
> > -static inline bool ct_header_is_response(u32 header)
> > -{
> > - return !!(header & GUC_CT_MSG_IS_RESPONSE);
> > -}
> > -
> > static struct ct_incoming_msg *ct_alloc_msg(u32 num_dwords)
> > {
> > struct ct_incoming_msg *msg;
> > @@ -675,7 +645,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> > head = (head + 1) % size;
> > /* message len with header */
> > - len = ct_header_get_len(header) + 1;
> > + len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, header) + GUC_CTB_MSG_MIN_LEN;
> > if (unlikely(len > (u32)available)) {
> > CT_ERROR(ct, "Incomplete message %*ph %*ph %*ph\n",
> > 4, &header,
> > @@ -718,55 +688,24 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)
> > return -EPIPE;
> > }
> > -/**
> > - * DOC: CTB GuC to Host response
> > - *
> > - * Format of the CTB GuC to Host response message is as follows::
> > - *
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | MESSAGE | MESSAGE PAYLOAD |
> > - * + HEADER +---------+---------+---------+---------+---------+
> > - * | | 0 | 1 | 2 | ... | n |
> > - * +============+=========+=========+=========+=========+=========+
> > - * | len >= 2 | FENCE | STATUS | response specific data |
> > - * +------+-----+---------+---------+---------+---------+---------+
> > - *
> > - * ^-----------------------len-----------------------^
> > - */
> > -
> > static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *response)
> > {
> > - u32 header = response->msg[0];
> > - u32 len = ct_header_get_len(header);
> > - u32 fence;
> > - u32 status;
> > - u32 datalen;
> > + u32 len = FIELD_GET(GUC_CTB_MSG_0_NUM_DWORDS, response->msg[0]);
> > + u32 fence = FIELD_GET(GUC_CTB_MSG_0_FENCE, response->msg[0]);
> > + const u32 *hxg = &response->msg[GUC_CTB_MSG_MIN_LEN];
>
> IMO it'd be better to just save the hxg in the msg field. We can save the
> fence as an extra field in the ct_incoming_msg. That way we won't have to
> convert from CTB to HXG in multiple places in the code (I count 4 total in
> this patch).
>
Not really sure I follow this but assume this isn't a blocker as this not
a functional change. We can always revisit in a follow up.
Matt
> Daniele
>
> > + const u32 *data = &hxg[GUC_HXG_MSG_MIN_LEN];
> > + u32 datalen = len - GUC_HXG_MSG_MIN_LEN;
> > struct ct_request *req;
> > unsigned long flags;
> > bool found = false;
> > int err = 0;
> > - GEM_BUG_ON(!ct_header_is_response(header));
> > + GEM_BUG_ON(len < GUC_HXG_MSG_MIN_LEN);
> > + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]) != GUC_HXG_ORIGIN_GUC);
> > + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_SUCCESS &&
> > + FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_RESPONSE_FAILURE);
> > - /* Response payload shall at least include fence and status */
> > - if (unlikely(len < 2)) {
> > - CT_ERROR(ct, "Corrupted response (len %u)\n", len);
> > - return -EPROTO;
> > - }
> > -
> > - fence = response->msg[1];
> > - status = response->msg[2];
> > - datalen = len - 2;
> > -
> > - /* Format of the status dword follows HXG header */
> > - if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) != GUC_HXG_ORIGIN_GUC)) {
> > - CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
> > - return -EPROTO;
> > - }
> > -
> > - CT_DEBUG(ct, "response fence %u status %#x\n", fence, status);
> > + CT_DEBUG(ct, "response fence %u status %#x\n", fence, hxg[0]);
> > spin_lock_irqsave(&ct->requests.lock, flags);
> > list_for_each_entry(req, &ct->requests.pending, link) {
> > @@ -782,9 +721,9 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> > err = -EMSGSIZE;
> > }
> > if (datalen)
> > - memcpy(req->response_buf, response->msg + 3, 4 * datalen);
> > + memcpy(req->response_buf, data, 4 * datalen);
> > req->response_len = datalen;
> > - WRITE_ONCE(req->status, status);
> > + WRITE_ONCE(req->status, hxg[0]);
> > found = true;
> > break;
> > }
> > @@ -805,14 +744,16 @@ static int ct_handle_response(struct intel_guc_ct *ct, struct ct_incoming_msg *r
> > static int ct_process_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> > {
> > struct intel_guc *guc = ct_to_guc(ct);
> > - u32 header, action, len;
> > + const u32 *hxg;
> > const u32 *payload;
> > + u32 hxg_len, action, len;
> > int ret;
> > - header = request->msg[0];
> > - payload = &request->msg[1];
> > - action = ct_header_get_action(header);
> > - len = ct_header_get_len(header);
> > + hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> > + hxg_len = request->size - GUC_CTB_MSG_MIN_LEN;
> > + payload = &hxg[GUC_HXG_MSG_MIN_LEN];
> > + action = FIELD_GET(GUC_HXG_EVENT_MSG_0_ACTION, hxg[0]);
> > + len = hxg_len - GUC_HXG_MSG_MIN_LEN;
> > CT_DEBUG(ct, "request %x %*ph\n", action, 4 * len, payload);
> > @@ -874,29 +815,12 @@ static void ct_incoming_request_worker_func(struct work_struct *w)
> > queue_work(system_unbound_wq, &ct->requests.worker);
> > }
> > -/**
> > - * DOC: CTB GuC to Host request
> > - *
> > - * Format of the CTB GuC to Host request message is as follows::
> > - *
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | msg[0] | [1] | [2] | [3] | ... | [n-1] |
> > - * +------------+---------+---------+---------+---------+---------+
> > - * | MESSAGE | MESSAGE PAYLOAD |
> > - * + HEADER +---------+---------+---------+---------+---------+
> > - * | | 0 | 1 | 2 | ... | n |
> > - * +============+=========+=========+=========+=========+=========+
> > - * | len | request specific data |
> > - * +------+-----+---------+---------+---------+---------+---------+
> > - *
> > - * ^-----------------------len-----------------------^
> > - */
> > -
> > -static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> > +static int ct_handle_event(struct intel_guc_ct *ct, struct ct_incoming_msg *request)
> > {
> > + const u32 *hxg = &request->msg[GUC_CTB_MSG_MIN_LEN];
> > unsigned long flags;
> > - GEM_BUG_ON(ct_header_is_response(request->msg[0]));
> > + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]) != GUC_HXG_TYPE_EVENT);
> > spin_lock_irqsave(&ct->requests.lock, flags);
> > list_add_tail(&request->link, &ct->requests.incoming);
> > @@ -906,15 +830,53 @@ static int ct_handle_request(struct intel_guc_ct *ct, struct ct_incoming_msg *re
> > return 0;
> > }
> > -static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> > +static int ct_handle_hxg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> > {
> > - u32 header = msg->msg[0];
> > + u32 origin, type;
> > + u32 *hxg;
> > int err;
> > - if (ct_header_is_response(header))
> > + if (unlikely(msg->size < GUC_CTB_HXG_MSG_MIN_LEN))
> > + return -EBADMSG;
> > +
> > + hxg = &msg->msg[GUC_CTB_MSG_MIN_LEN];
> > +
> > + origin = FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg[0]);
> > + if (unlikely(origin != GUC_HXG_ORIGIN_GUC)) {
> > + err = -EPROTO;
> > + goto failed;
> > + }
> > +
> > + type = FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg[0]);
> > + switch (type) {
> > + case GUC_HXG_TYPE_EVENT:
> > + err = ct_handle_event(ct, msg);
> > + break;
> > + case GUC_HXG_TYPE_RESPONSE_SUCCESS:
> > + case GUC_HXG_TYPE_RESPONSE_FAILURE:
> > err = ct_handle_response(ct, msg);
> > + break;
> > + default:
> > + err = -EOPNOTSUPP;
> > + }
> > +
> > + if (unlikely(err)) {
> > +failed:
> > + CT_ERROR(ct, "Failed to handle HXG message (%pe) %*ph\n",
> > + ERR_PTR(err), 4 * GUC_HXG_MSG_MIN_LEN, hxg);
> > + }
> > + return err;
> > +}
> > +
> > +static void ct_handle_msg(struct intel_guc_ct *ct, struct ct_incoming_msg *msg)
> > +{
> > + u32 format = FIELD_GET(GUC_CTB_MSG_0_FORMAT, msg->msg[0]);
> > + int err;
> > +
> > + if (format == GUC_CTB_FORMAT_HXG)
> > + err = ct_handle_hxg(ct, msg);
> > else
> > - err = ct_handle_request(ct, msg);
> > + err = -EOPNOTSUPP;
> > if (unlikely(err)) {
> > CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > index 905202caaad3..1ae2dde6db93 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
> > @@ -61,7 +61,7 @@ struct intel_guc_ct {
> > struct tasklet_struct receive_tasklet;
> > struct {
> > - u32 last_fence; /* last fence used to send request */
> > + u16 last_fence; /* last fence used to send request */
> > spinlock_t lock; /* protects pending requests list */
> > struct list_head pending; /* requests waiting for response */
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-09 20:07 ` [Intel-gfx] " Michal Wajdeczko
@ 2021-06-10 4:38 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-10 4:38 UTC (permalink / raw)
To: Michal Wajdeczko
Cc: intel-gfx, Daniele Ceraolo Spurio, dri-devel, John Harrison
On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
>
>
> On 09.06.2021 19:36, John Harrison wrote:
> > On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> >> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> >>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>>
> >>> Definition of the CTB registration action has changed.
> >>> Add some ABI documentation and implement required changes.
> >>>
> >>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
> >>> ---
> >>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
> >>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
> >>> 3 files changed, 152 insertions(+), 35 deletions(-)
> >>>
> >>> 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 90efef8a73e4..6426fc183692 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
> >>> @@ -6,6 +6,113 @@
> >>> #ifndef _ABI_GUC_ACTIONS_ABI_H
> >>> #define _ABI_GUC_ACTIONS_ABI_H
> >>> +/**
> >>> + * DOC: HOST2GUC_REGISTER_CTB
> >>> + *
> >>> + * This message is used as part of the `CTB based communication`_
> >>> setup.
> >>> + *
> >>> + * This message must be sent as `MMIO HXG Message`_.
> >>> + *
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_HOST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_REQUEST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:16 | DATA0 =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
> >>> 0x5200 |
> >>
> >> Specs says 4505
> >>
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 1 | 31:12 | RESERVED =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 11:8 | **TYPE** - type for the `CT
> >>> Buffer`_ |
> >>> + * | |
> >>> | |
> >>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
> >>> 0 |
> >>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
> >>> 1 |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
> >>> minus 1 |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
> >>> Descriptor`_ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
> >>> Buffer`_ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> +*
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_GUC_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:0 | DATA0 =
> >>> MBZ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + */
> >>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
> >>
> >> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> >> at some point I don;t think this deserves a FIXME since nothing is
> >> incorrect.
> >>
> >>> +
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
> >>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
> >>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>> +#define GUC_CTB_TYPE_HOST2GUC 0u
> >>> +#define GUC_CTB_TYPE_GUC2HOST 1u
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
> >>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
> >>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>
> >> The full mask still seems like overkill to me and I still think we
> >> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
> >> on it.
> >>
> >>> +
> >>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
> >>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>> +
> >>> +/**
> >>> + * DOC: HOST2GUC_DEREGISTER_CTB
> >>> + *
> >>> + * This message is used as part of the `CTB based communication`_
> >>> teardown.
> >>> + *
> >>> + * This message must be sent as `MMIO HXG Message`_.
> >>> + *
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_HOST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_REQUEST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:16 | DATA0 =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
> >>> 0x5201 |
> >>
> >> Specs says 4506
> >>
> > I would say that the enum value should not be included in the structure
> > definition. I would also argue that there is no point in repeating the
> > common header structure for every single H2G action definition. That is
> > just overly verbose and makes it harder to read the spec. It implies
> > that every action has a different header structure and must be coded
> > individually.
>
> but some actions are defined as REQUEST some as EVENT, so we need to say
> that, also each REQUEST action may define its own DATA0, so again we
> still need to define these bits somewhere
>
> >
> > Personally, I don't believe we should be replicating the entire GuC API
> > spec in the driver header files anyway. This is not something that is
> > defined by the i915 driver so the i915 driver should not be defining it!
> > Instead, just include a link or pointer to where the actual spec can be
> > found. We don't copy the entire bspec page for every register that the
> > driver touches, so why should this be any different?
I agree with John on this one. We plan publishing the GuC, right? Let's
just point to it in the kernel DOC.
Also at some all these defines really should be auto-generated. I
suppose if these headers are auto-generated, I could live with these
files generating kernel DOC. I can't really live with having to maintain
a table like this for every action manually.
Matt
>
> to some extend we have to replicate at least part of the GuC ABI spec,
> part that defines all bits, and IMHO there is nothing wrong if it comes
> with full message layout definitions, especially if you compare that
> with previous approach, were H2G action definitions were limited just to
> single enum value (and to find out how to use given H2G you had to look
> into firmware source code)
>
> so while we keep these abi.h files in kernel repo, they shall be treated
> as read-only imported external interface definitions, from which we just
> use all #define for coding and DOC: for documentation (latter at least
> until GuC will release its spec to the public)
>
> >
> > John.
> >
> >
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 1 | 31:12 | RESERVED =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 11:8 | **TYPE** - type of the `CT
> >>> Buffer`_ |
> >>> + * | |
> >>> | |
> >>> + * | | | see
> >>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 7:0 | RESERVED =
> >>> MBZ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> +*
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_GUC_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:0 | DATA0 =
> >>> MBZ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + */
> >>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
> >>> 0x5201
> >>
> >> Same comment for the FIXME as above
> >>
> >>> +
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
> >>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
> >>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
> >>> +
> >>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
> >>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>> +
> >>> +/* legacy definitions */
> >>> +
> >>> enum intel_guc_action {
> >>> INTEL_GUC_ACTION_DEFAULT = 0x0,
> >>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
> >>> diff --git
> >>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> index c2a069a78e01..127b256a662c 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
> >>> == 64);
> >>> * - **flags**, holds various bits to control message handling
> >>> */
> >>> -/* Type of command transport buffer */
> >>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> >>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> >>> -
> >>> /*
> >>> * Definition of the command transport message header (DW0)
> >>> *
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> index 3241a477196f..6a29be779cc9 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
> >>> *ct)
> >>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
> >>> {
> >>> switch (type) {
> >>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> >>> + case GUC_CTB_TYPE_HOST2GUC:
> >>> return "SEND";
> >>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> >>> + case GUC_CTB_TYPE_GUC2HOST:
> >>> return "RECV";
> >>> default:
> >>> return "<invalid>";
> >>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
> >>> intel_guc_ct_buffer *ctb,
> >>> guc_ct_buffer_reset(ctb);
> >>> }
> >>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
> >>> - u32 desc_addr,
> >>> - u32 type)
> >>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
> >>> type,
> >>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>> {
> >>> - u32 action[] = {
> >>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
> >>> - desc_addr,
> >>> - sizeof(struct guc_ct_buffer_desc),
> >>> - type
> >>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
> >>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
> >>
> >> IMO we could use a macro or 2 for the HXG header, to avoid all these
> >> lines, which are hard to read. something like:
> >>
> >> GUC_HXG_HEADER(origin, type, data, action) \
> >> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> >> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> >> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> >> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
> >>
> >> H2G_HEADER(type, data, action) \
> >> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
> >>
> >> and then call
> >>
> >> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
> >>
> >>
> >> Not a blocker.
> >>
> >> Daniele
> >>
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
> >>> 1) |
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
> >>> };
> >>> - /* Can't use generic send(), CT registration must go over MMIO */
> >>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>> NULL, 0);
> >>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>> GUC_CTB_TYPE_GUC2HOST);
> >>> + GEM_BUG_ON(size % SZ_4K);
> >>> +
> >>> + /* CT registration must go over MMIO */
> >>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>> NULL, 0);
> >>> }
> >>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
> >>> desc_addr, u32 type)
> >>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
> >>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>> {
> >>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
> >>> desc_addr, type);
> >>> + int err;
> >>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
> >>> + desc_addr, buff_addr, size);
> >>> if (unlikely(err))
> >>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
> >>> guc_ct_buffer_type_to_str(type), err);
> >>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
> >>> intel_guc_ct *ct, u32 desc_addr, u32 type)
> >>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
> >>> u32 type)
> >>> {
> >>> - u32 action[] = {
> >>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
> >>> - CTB_OWNER_HOST,
> >>> - type
> >>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
> >>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
> >>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>> };
> >>> - /* Can't use generic send(), CT deregistration must go over
> >>> MMIO */
> >>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>> NULL, 0);
> >>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>> GUC_CTB_TYPE_GUC2HOST);
> >>> +
> >>> + /* CT deregistration must go over MMIO */
> >>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>> NULL, 0);
> >>> }
> >>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
> >>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
> >>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>> {
> >>> struct intel_guc *guc = ct_to_guc(ct);
> >>> - u32 base, cmds;
> >>> + u32 base, desc, cmds;
> >>> void *blob;
> >>> int err;
> >>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
> >>> /* (re)initialize descriptors */
> >>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>> guc_ct_buffer_reset(&ct->ctbs.send);
> >>> -
> >>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>> guc_ct_buffer_reset(&ct->ctbs.recv);
> >>> /*
> >>> * Register both CT buffers starting with RECV buffer.
> >>> * Descriptors are in first half of the blob.
> >>> */
> >>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
> >>> blob),
> >>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
> >>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
> >>> + desc, cmds, ct->ctbs.recv.size * 4);
> >>> +
> >>> if (unlikely(err))
> >>> goto err_out;
> >>> - err = ct_register_buffer(ct, base +
> >>> ptrdiff(ct->ctbs.send.desc, blob),
> >>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
> >>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
> >>> + desc, cmds, ct->ctbs.send.size * 4);
> >>> +
> >>> if (unlikely(err))
> >>> goto err_deregister;
> >>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>> return 0;
> >>> err_deregister:
> >>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>> err_out:
> >>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
> >>> return err;
> >>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
> >>> ct->enabled = false;
> >>> if (intel_guc_is_fw_running(guc)) {
> >>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
> >>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>> }
> >>> }
> >>
> >
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-10 4:38 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-10 4:38 UTC (permalink / raw)
To: Michal Wajdeczko; +Cc: intel-gfx, dri-devel
On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
>
>
> On 09.06.2021 19:36, John Harrison wrote:
> > On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> >> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> >>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>>
> >>> Definition of the CTB registration action has changed.
> >>> Add some ABI documentation and implement required changes.
> >>>
> >>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
> >>> ---
> >>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
> >>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
> >>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
> >>> 3 files changed, 152 insertions(+), 35 deletions(-)
> >>>
> >>> 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 90efef8a73e4..6426fc183692 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
> >>> @@ -6,6 +6,113 @@
> >>> #ifndef _ABI_GUC_ACTIONS_ABI_H
> >>> #define _ABI_GUC_ACTIONS_ABI_H
> >>> +/**
> >>> + * DOC: HOST2GUC_REGISTER_CTB
> >>> + *
> >>> + * This message is used as part of the `CTB based communication`_
> >>> setup.
> >>> + *
> >>> + * This message must be sent as `MMIO HXG Message`_.
> >>> + *
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_HOST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_REQUEST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:16 | DATA0 =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
> >>> 0x5200 |
> >>
> >> Specs says 4505
> >>
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 1 | 31:12 | RESERVED =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 11:8 | **TYPE** - type for the `CT
> >>> Buffer`_ |
> >>> + * | |
> >>> | |
> >>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
> >>> 0 |
> >>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
> >>> 1 |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
> >>> minus 1 |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
> >>> Descriptor`_ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
> >>> Buffer`_ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> +*
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_GUC_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:0 | DATA0 =
> >>> MBZ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + */
> >>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
> >>
> >> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> >> at some point I don;t think this deserves a FIXME since nothing is
> >> incorrect.
> >>
> >>> +
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
> >>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
> >>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>> +#define GUC_CTB_TYPE_HOST2GUC 0u
> >>> +#define GUC_CTB_TYPE_GUC2HOST 1u
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
> >>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
> >>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>
> >> The full mask still seems like overkill to me and I still think we
> >> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
> >> on it.
> >>
> >>> +
> >>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
> >>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>> +
> >>> +/**
> >>> + * DOC: HOST2GUC_DEREGISTER_CTB
> >>> + *
> >>> + * This message is used as part of the `CTB based communication`_
> >>> teardown.
> >>> + *
> >>> + * This message must be sent as `MMIO HXG Message`_.
> >>> + *
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_HOST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_REQUEST_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:16 | DATA0 =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
> >>> 0x5201 |
> >>
> >> Specs says 4506
> >>
> > I would say that the enum value should not be included in the structure
> > definition. I would also argue that there is no point in repeating the
> > common header structure for every single H2G action definition. That is
> > just overly verbose and makes it harder to read the spec. It implies
> > that every action has a different header structure and must be coded
> > individually.
>
> but some actions are defined as REQUEST some as EVENT, so we need to say
> that, also each REQUEST action may define its own DATA0, so again we
> still need to define these bits somewhere
>
> >
> > Personally, I don't believe we should be replicating the entire GuC API
> > spec in the driver header files anyway. This is not something that is
> > defined by the i915 driver so the i915 driver should not be defining it!
> > Instead, just include a link or pointer to where the actual spec can be
> > found. We don't copy the entire bspec page for every register that the
> > driver touches, so why should this be any different?
I agree with John on this one. We plan publishing the GuC, right? Let's
just point to it in the kernel DOC.
Also at some all these defines really should be auto-generated. I
suppose if these headers are auto-generated, I could live with these
files generating kernel DOC. I can't really live with having to maintain
a table like this for every action manually.
Matt
>
> to some extend we have to replicate at least part of the GuC ABI spec,
> part that defines all bits, and IMHO there is nothing wrong if it comes
> with full message layout definitions, especially if you compare that
> with previous approach, were H2G action definitions were limited just to
> single enum value (and to find out how to use given H2G you had to look
> into firmware source code)
>
> so while we keep these abi.h files in kernel repo, they shall be treated
> as read-only imported external interface definitions, from which we just
> use all #define for coding and DOC: for documentation (latter at least
> until GuC will release its spec to the public)
>
> >
> > John.
> >
> >
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | 1 | 31:12 | RESERVED =
> >>> MBZ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 11:8 | **TYPE** - type of the `CT
> >>> Buffer`_ |
> >>> + * | |
> >>> | |
> >>> + * | | | see
> >>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 7:0 | RESERVED =
> >>> MBZ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> +*
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + * | | Bits |
> >>> Description |
> >>> + *
> >>> +===+=======+==============================================================+
> >>>
> >>> + * | 0 | 31 | ORIGIN =
> >>> GUC_HXG_ORIGIN_GUC_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 30:28 | TYPE =
> >>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>> + * |
> >>> +-------+--------------------------------------------------------------+
> >>> + * | | 27:0 | DATA0 =
> >>> MBZ |
> >>> + *
> >>> +---+-------+--------------------------------------------------------------+
> >>>
> >>> + */
> >>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
> >>> 0x5201
> >>
> >> Same comment for the FIXME as above
> >>
> >>> +
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
> >>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
> >>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
> >>> +
> >>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
> >>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>> +
> >>> +/* legacy definitions */
> >>> +
> >>> enum intel_guc_action {
> >>> INTEL_GUC_ACTION_DEFAULT = 0x0,
> >>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
> >>> diff --git
> >>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> index c2a069a78e01..127b256a662c 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
> >>> == 64);
> >>> * - **flags**, holds various bits to control message handling
> >>> */
> >>> -/* Type of command transport buffer */
> >>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> >>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> >>> -
> >>> /*
> >>> * Definition of the command transport message header (DW0)
> >>> *
> >>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> index 3241a477196f..6a29be779cc9 100644
> >>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
> >>> *ct)
> >>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
> >>> {
> >>> switch (type) {
> >>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> >>> + case GUC_CTB_TYPE_HOST2GUC:
> >>> return "SEND";
> >>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> >>> + case GUC_CTB_TYPE_GUC2HOST:
> >>> return "RECV";
> >>> default:
> >>> return "<invalid>";
> >>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
> >>> intel_guc_ct_buffer *ctb,
> >>> guc_ct_buffer_reset(ctb);
> >>> }
> >>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
> >>> - u32 desc_addr,
> >>> - u32 type)
> >>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
> >>> type,
> >>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>> {
> >>> - u32 action[] = {
> >>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
> >>> - desc_addr,
> >>> - sizeof(struct guc_ct_buffer_desc),
> >>> - type
> >>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
> >>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
> >>
> >> IMO we could use a macro or 2 for the HXG header, to avoid all these
> >> lines, which are hard to read. something like:
> >>
> >> GUC_HXG_HEADER(origin, type, data, action) \
> >> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> >> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> >> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> >> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
> >>
> >> H2G_HEADER(type, data, action) \
> >> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
> >>
> >> and then call
> >>
> >> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
> >>
> >>
> >> Not a blocker.
> >>
> >> Daniele
> >>
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
> >>> 1) |
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
> >>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
> >>> };
> >>> - /* Can't use generic send(), CT registration must go over MMIO */
> >>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>> NULL, 0);
> >>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>> GUC_CTB_TYPE_GUC2HOST);
> >>> + GEM_BUG_ON(size % SZ_4K);
> >>> +
> >>> + /* CT registration must go over MMIO */
> >>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>> NULL, 0);
> >>> }
> >>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
> >>> desc_addr, u32 type)
> >>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
> >>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>> {
> >>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
> >>> desc_addr, type);
> >>> + int err;
> >>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
> >>> + desc_addr, buff_addr, size);
> >>> if (unlikely(err))
> >>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
> >>> guc_ct_buffer_type_to_str(type), err);
> >>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
> >>> intel_guc_ct *ct, u32 desc_addr, u32 type)
> >>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
> >>> u32 type)
> >>> {
> >>> - u32 action[] = {
> >>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
> >>> - CTB_OWNER_HOST,
> >>> - type
> >>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
> >>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
> >>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>> };
> >>> - /* Can't use generic send(), CT deregistration must go over
> >>> MMIO */
> >>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>> NULL, 0);
> >>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>> GUC_CTB_TYPE_GUC2HOST);
> >>> +
> >>> + /* CT deregistration must go over MMIO */
> >>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>> NULL, 0);
> >>> }
> >>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
> >>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
> >>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>> {
> >>> struct intel_guc *guc = ct_to_guc(ct);
> >>> - u32 base, cmds;
> >>> + u32 base, desc, cmds;
> >>> void *blob;
> >>> int err;
> >>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
> >>> /* (re)initialize descriptors */
> >>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>> guc_ct_buffer_reset(&ct->ctbs.send);
> >>> -
> >>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>> guc_ct_buffer_reset(&ct->ctbs.recv);
> >>> /*
> >>> * Register both CT buffers starting with RECV buffer.
> >>> * Descriptors are in first half of the blob.
> >>> */
> >>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
> >>> blob),
> >>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
> >>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
> >>> + desc, cmds, ct->ctbs.recv.size * 4);
> >>> +
> >>> if (unlikely(err))
> >>> goto err_out;
> >>> - err = ct_register_buffer(ct, base +
> >>> ptrdiff(ct->ctbs.send.desc, blob),
> >>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
> >>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
> >>> + desc, cmds, ct->ctbs.send.size * 4);
> >>> +
> >>> if (unlikely(err))
> >>> goto err_deregister;
> >>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>> return 0;
> >>> err_deregister:
> >>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>> err_out:
> >>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
> >>> return err;
> >>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
> >>> ct->enabled = false;
> >>> if (intel_guc_is_fw_running(guc)) {
> >>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
> >>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>> }
> >>> }
> >>
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-10 4:38 ` [Intel-gfx] " Matthew Brost
@ 2021-06-10 13:19 ` Michal Wajdeczko
-1 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-10 13:19 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx, Daniele Ceraolo Spurio, dri-devel, John Harrison
On 10.06.2021 06:38, Matthew Brost wrote:
> On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 09.06.2021 19:36, John Harrison wrote:
>>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>>>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>>>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>>>
>>>>> Definition of the CTB registration action has changed.
>>>>> Add some ABI documentation and implement required changes.
>>>>>
>>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>>>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>>>>> ---
>>>>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>>>>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>>>>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>>>>
>>>>> 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 90efef8a73e4..6426fc183692 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
>>>>> @@ -6,6 +6,113 @@
>>>>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>>>>> #define _ABI_GUC_ACTIONS_ABI_H
>>>>> +/**
>>>>> + * DOC: HOST2GUC_REGISTER_CTB
>>>>> + *
>>>>> + * This message is used as part of the `CTB based communication`_
>>>>> setup.
>>>>> + *
>>>>> + * This message must be sent as `MMIO HXG Message`_.
>>>>> + *
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_HOST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_REQUEST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:16 | DATA0 =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>>>>> 0x5200 |
>>>>
>>>> Specs says 4505
>>>>
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 1 | 31:12 | RESERVED =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 11:8 | **TYPE** - type for the `CT
>>>>> Buffer`_ |
>>>>> + * | |
>>>>> | |
>>>>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>>>>> 0 |
>>>>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>>>>> 1 |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>>>>> minus 1 |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>>>>> Descriptor`_ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>>>>> Buffer`_ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> +*
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_GUC_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:0 | DATA0 =
>>>>> MBZ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + */
>>>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>>>>
>>>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
>>>> at some point I don;t think this deserves a FIXME since nothing is
>>>> incorrect.
>>>>
>>>>> +
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>>>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>>>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>>>>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>>>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>>>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>>>
>>>> The full mask still seems like overkill to me and I still think we
>>>> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
>>>> on it.
>>>>
>>>>> +
>>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>>>> +
>>>>> +/**
>>>>> + * DOC: HOST2GUC_DEREGISTER_CTB
>>>>> + *
>>>>> + * This message is used as part of the `CTB based communication`_
>>>>> teardown.
>>>>> + *
>>>>> + * This message must be sent as `MMIO HXG Message`_.
>>>>> + *
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_HOST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_REQUEST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:16 | DATA0 =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>>>>> 0x5201 |
>>>>
>>>> Specs says 4506
>>>>
>>> I would say that the enum value should not be included in the structure
>>> definition. I would also argue that there is no point in repeating the
>>> common header structure for every single H2G action definition. That is
>>> just overly verbose and makes it harder to read the spec. It implies
>>> that every action has a different header structure and must be coded
>>> individually.
>>
>> but some actions are defined as REQUEST some as EVENT, so we need to say
>> that, also each REQUEST action may define its own DATA0, so again we
>> still need to define these bits somewhere
>>
>>>
>>> Personally, I don't believe we should be replicating the entire GuC API
>>> spec in the driver header files anyway. This is not something that is
>>> defined by the i915 driver so the i915 driver should not be defining it!
>>> Instead, just include a link or pointer to where the actual spec can be
>>> found. We don't copy the entire bspec page for every register that the
>>> driver touches, so why should this be any different?
>
> I agree with John on this one. We plan publishing the GuC, right? Let's
Do you know of any ETA? I don't
and likely the same promise was given few years back when GuC was
introduced in upstream, I don't want to have just code that we can't
compare with specification (in any form)
> just point to it in the kernel DOC.
>
> Also at some all these defines really should be auto-generated. I
> suppose if these headers are auto-generated, I could live with these
I was also hoping to get these ABI headers auto-generated before we
start to used them for good, unfortunately it was quite the opposite:
for some time these hand crafted tables were used as input for
discussion and then to prepare machine readable formats, but the only
tool currently available (and still WIP) is for generating spec
documentation
> files generating kernel DOC. I can't really live with having to maintain
> a table like this for every action manually.
the goal is to freeze ABI so no maintenance will be necessary, except
adding new actions, and that's also the reason to keep these ABI files
separate from the rest of our headers, where we can add/modify/improve
any helpers/wrappers as we want.
and I don't recall that you were forced to modify any of such tables
yet, nor were asked to manually prepare them for the rest of the
existing actions, especially GuC submission ones, so why complain?
>
> Matt
>
>>
>> to some extend we have to replicate at least part of the GuC ABI spec,
>> part that defines all bits, and IMHO there is nothing wrong if it comes
>> with full message layout definitions, especially if you compare that
>> with previous approach, were H2G action definitions were limited just to
>> single enum value (and to find out how to use given H2G you had to look
>> into firmware source code)
>>
>> so while we keep these abi.h files in kernel repo, they shall be treated
>> as read-only imported external interface definitions, from which we just
>> use all #define for coding and DOC: for documentation (latter at least
>> until GuC will release its spec to the public)
>>
>>>
>>> John.
>>>
>>>
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 1 | 31:12 | RESERVED =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 11:8 | **TYPE** - type of the `CT
>>>>> Buffer`_ |
>>>>> + * | |
>>>>> | |
>>>>> + * | | | see
>>>>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 7:0 | RESERVED =
>>>>> MBZ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> +*
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_GUC_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:0 | DATA0 =
>>>>> MBZ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + */
>>>>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
>>>>> 0x5201
>>>>
>>>> Same comment for the FIXME as above
>>>>
>>>>> +
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>>>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>>>>> +
>>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>>>> +
>>>>> +/* legacy definitions */
>>>>> +
>>>>> enum intel_guc_action {
>>>>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>>>>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>>>>> diff --git
>>>>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> index c2a069a78e01..127b256a662c 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>>>>> == 64);
>>>>> * - **flags**, holds various bits to control message handling
>>>>> */
>>>>> -/* Type of command transport buffer */
>>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>>>>> -
>>>>> /*
>>>>> * Definition of the command transport message header (DW0)
>>>>> *
>>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> index 3241a477196f..6a29be779cc9 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
>>>>> *ct)
>>>>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>>>>> {
>>>>> switch (type) {
>>>>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>>>>> + case GUC_CTB_TYPE_HOST2GUC:
>>>>> return "SEND";
>>>>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>>>>> + case GUC_CTB_TYPE_GUC2HOST:
>>>>> return "RECV";
>>>>> default:
>>>>> return "<invalid>";
>>>>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>>>>> intel_guc_ct_buffer *ctb,
>>>>> guc_ct_buffer_reset(ctb);
>>>>> }
>>>>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>>>>> - u32 desc_addr,
>>>>> - u32 type)
>>>>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>>>>> type,
>>>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>>>> {
>>>>> - u32 action[] = {
>>>>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>>>>> - desc_addr,
>>>>> - sizeof(struct guc_ct_buffer_desc),
>>>>> - type
>>>>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>>>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>>>>
>>>> IMO we could use a macro or 2 for the HXG header, to avoid all these
>>>> lines, which are hard to read. something like:
>>>>
>>>> GUC_HXG_HEADER(origin, type, data, action) \
>>>> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
>>>> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
>>>> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
>>>> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>>>>
>>>> H2G_HEADER(type, data, action) \
>>>> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>>>>
>>>> and then call
>>>>
>>>> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
>>>>
>>>>
>>>> Not a blocker.
>>>>
>>>> Daniele
>>>>
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
>>>>> 1) |
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
>>>>> };
>>>>> - /* Can't use generic send(), CT registration must go over MMIO */
>>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>>>> NULL, 0);
>>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>>>> GUC_CTB_TYPE_GUC2HOST);
>>>>> + GEM_BUG_ON(size % SZ_4K);
>>>>> +
>>>>> + /* CT registration must go over MMIO */
>>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>>>> NULL, 0);
>>>>> }
>>>>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>>>>> desc_addr, u32 type)
>>>>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>>>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>>>> {
>>>>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
>>>>> desc_addr, type);
>>>>> + int err;
>>>>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>>>>> + desc_addr, buff_addr, size);
>>>>> if (unlikely(err))
>>>>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>>>>> guc_ct_buffer_type_to_str(type), err);
>>>>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>>>>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>>>>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>>>>> u32 type)
>>>>> {
>>>>> - u32 action[] = {
>>>>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>>>>> - CTB_OWNER_HOST,
>>>>> - type
>>>>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>>>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>>>>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>>>> };
>>>>> - /* Can't use generic send(), CT deregistration must go over
>>>>> MMIO */
>>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>>>> NULL, 0);
>>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>>>> GUC_CTB_TYPE_GUC2HOST);
>>>>> +
>>>>> + /* CT deregistration must go over MMIO */
>>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>>>> NULL, 0);
>>>>> }
>>>>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>>>>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>>>>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>>> {
>>>>> struct intel_guc *guc = ct_to_guc(ct);
>>>>> - u32 base, cmds;
>>>>> + u32 base, desc, cmds;
>>>>> void *blob;
>>>>> int err;
>>>>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>>>>> /* (re)initialize descriptors */
>>>>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>>>> guc_ct_buffer_reset(&ct->ctbs.send);
>>>>> -
>>>>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>>>> guc_ct_buffer_reset(&ct->ctbs.recv);
>>>>> /*
>>>>> * Register both CT buffers starting with RECV buffer.
>>>>> * Descriptors are in first half of the blob.
>>>>> */
>>>>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>>>>> blob),
>>>>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>>>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>>>>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>>>>> + desc, cmds, ct->ctbs.recv.size * 4);
>>>>> +
>>>>> if (unlikely(err))
>>>>> goto err_out;
>>>>> - err = ct_register_buffer(ct, base +
>>>>> ptrdiff(ct->ctbs.send.desc, blob),
>>>>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>>>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>>>>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>>>>> + desc, cmds, ct->ctbs.send.size * 4);
>>>>> +
>>>>> if (unlikely(err))
>>>>> goto err_deregister;
>>>>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>>> return 0;
>>>>> err_deregister:
>>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>>>> err_out:
>>>>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>>>>> return err;
>>>>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>>>>> ct->enabled = false;
>>>>> if (intel_guc_is_fw_running(guc)) {
>>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>>>> }
>>>>> }
>>>>
>>>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-10 13:19 ` Michal Wajdeczko
0 siblings, 0 replies; 87+ messages in thread
From: Michal Wajdeczko @ 2021-06-10 13:19 UTC (permalink / raw)
To: Matthew Brost; +Cc: intel-gfx, dri-devel
On 10.06.2021 06:38, Matthew Brost wrote:
> On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 09.06.2021 19:36, John Harrison wrote:
>>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>>>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>>>>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>>>
>>>>> Definition of the CTB registration action has changed.
>>>>> Add some ABI documentation and implement required changes.
>>>>>
>>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>>>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
>>>>> ---
>>>>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
>>>>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
>>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
>>>>> 3 files changed, 152 insertions(+), 35 deletions(-)
>>>>>
>>>>> 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 90efef8a73e4..6426fc183692 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
>>>>> @@ -6,6 +6,113 @@
>>>>> #ifndef _ABI_GUC_ACTIONS_ABI_H
>>>>> #define _ABI_GUC_ACTIONS_ABI_H
>>>>> +/**
>>>>> + * DOC: HOST2GUC_REGISTER_CTB
>>>>> + *
>>>>> + * This message is used as part of the `CTB based communication`_
>>>>> setup.
>>>>> + *
>>>>> + * This message must be sent as `MMIO HXG Message`_.
>>>>> + *
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_HOST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_REQUEST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:16 | DATA0 =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
>>>>> 0x5200 |
>>>>
>>>> Specs says 4505
>>>>
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 1 | 31:12 | RESERVED =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 11:8 | **TYPE** - type for the `CT
>>>>> Buffer`_ |
>>>>> + * | |
>>>>> | |
>>>>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
>>>>> 0 |
>>>>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
>>>>> 1 |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
>>>>> minus 1 |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
>>>>> Descriptor`_ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
>>>>> Buffer`_ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> +*
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_GUC_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:0 | DATA0 =
>>>>> MBZ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + */
>>>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
>>>>
>>>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
>>>> at some point I don;t think this deserves a FIXME since nothing is
>>>> incorrect.
>>>>
>>>>> +
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
>>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
>>>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>>>> +#define GUC_CTB_TYPE_HOST2GUC 0u
>>>>> +#define GUC_CTB_TYPE_GUC2HOST 1u
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
>>>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
>>>>> GUC_HXG_REQUEST_MSG_n_DATAn
>>>>
>>>> The full mask still seems like overkill to me and I still think we
>>>> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
>>>> on it.
>>>>
>>>>> +
>>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
>>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
>>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>>>> +
>>>>> +/**
>>>>> + * DOC: HOST2GUC_DEREGISTER_CTB
>>>>> + *
>>>>> + * This message is used as part of the `CTB based communication`_
>>>>> teardown.
>>>>> + *
>>>>> + * This message must be sent as `MMIO HXG Message`_.
>>>>> + *
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_HOST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_REQUEST_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:16 | DATA0 =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
>>>>> 0x5201 |
>>>>
>>>> Specs says 4506
>>>>
>>> I would say that the enum value should not be included in the structure
>>> definition. I would also argue that there is no point in repeating the
>>> common header structure for every single H2G action definition. That is
>>> just overly verbose and makes it harder to read the spec. It implies
>>> that every action has a different header structure and must be coded
>>> individually.
>>
>> but some actions are defined as REQUEST some as EVENT, so we need to say
>> that, also each REQUEST action may define its own DATA0, so again we
>> still need to define these bits somewhere
>>
>>>
>>> Personally, I don't believe we should be replicating the entire GuC API
>>> spec in the driver header files anyway. This is not something that is
>>> defined by the i915 driver so the i915 driver should not be defining it!
>>> Instead, just include a link or pointer to where the actual spec can be
>>> found. We don't copy the entire bspec page for every register that the
>>> driver touches, so why should this be any different?
>
> I agree with John on this one. We plan publishing the GuC, right? Let's
Do you know of any ETA? I don't
and likely the same promise was given few years back when GuC was
introduced in upstream, I don't want to have just code that we can't
compare with specification (in any form)
> just point to it in the kernel DOC.
>
> Also at some all these defines really should be auto-generated. I
> suppose if these headers are auto-generated, I could live with these
I was also hoping to get these ABI headers auto-generated before we
start to used them for good, unfortunately it was quite the opposite:
for some time these hand crafted tables were used as input for
discussion and then to prepare machine readable formats, but the only
tool currently available (and still WIP) is for generating spec
documentation
> files generating kernel DOC. I can't really live with having to maintain
> a table like this for every action manually.
the goal is to freeze ABI so no maintenance will be necessary, except
adding new actions, and that's also the reason to keep these ABI files
separate from the rest of our headers, where we can add/modify/improve
any helpers/wrappers as we want.
and I don't recall that you were forced to modify any of such tables
yet, nor were asked to manually prepare them for the rest of the
existing actions, especially GuC submission ones, so why complain?
>
> Matt
>
>>
>> to some extend we have to replicate at least part of the GuC ABI spec,
>> part that defines all bits, and IMHO there is nothing wrong if it comes
>> with full message layout definitions, especially if you compare that
>> with previous approach, were H2G action definitions were limited just to
>> single enum value (and to find out how to use given H2G you had to look
>> into firmware source code)
>>
>> so while we keep these abi.h files in kernel repo, they shall be treated
>> as read-only imported external interface definitions, from which we just
>> use all #define for coding and DOC: for documentation (latter at least
>> until GuC will release its spec to the public)
>>
>>>
>>> John.
>>>
>>>
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | 1 | 31:12 | RESERVED =
>>>>> MBZ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 11:8 | **TYPE** - type of the `CT
>>>>> Buffer`_ |
>>>>> + * | |
>>>>> | |
>>>>> + * | | | see
>>>>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 7:0 | RESERVED =
>>>>> MBZ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> +*
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + * | | Bits |
>>>>> Description |
>>>>> + *
>>>>> +===+=======+==============================================================+
>>>>>
>>>>> + * | 0 | 31 | ORIGIN =
>>>>> GUC_HXG_ORIGIN_GUC_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 30:28 | TYPE =
>>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
>>>>> + * |
>>>>> +-------+--------------------------------------------------------------+
>>>>> + * | | 27:0 | DATA0 =
>>>>> MBZ |
>>>>> + *
>>>>> +---+-------+--------------------------------------------------------------+
>>>>>
>>>>> + */
>>>>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
>>>>> 0x5201
>>>>
>>>> Same comment for the FIXME as above
>>>>
>>>>> +
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
>>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
>>>>> GUC_HXG_REQUEST_MSG_0_DATA0
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
>>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
>>>>> +
>>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
>>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
>>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
>>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
>>>>> +
>>>>> +/* legacy definitions */
>>>>> +
>>>>> enum intel_guc_action {
>>>>> INTEL_GUC_ACTION_DEFAULT = 0x0,
>>>>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
>>>>> diff --git
>>>>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> index c2a069a78e01..127b256a662c 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
>>>>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
>>>>> == 64);
>>>>> * - **flags**, holds various bits to control message handling
>>>>> */
>>>>> -/* Type of command transport buffer */
>>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
>>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
>>>>> -
>>>>> /*
>>>>> * Definition of the command transport message header (DW0)
>>>>> *
>>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> index 3241a477196f..6a29be779cc9 100644
>>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>>>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
>>>>> *ct)
>>>>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
>>>>> {
>>>>> switch (type) {
>>>>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
>>>>> + case GUC_CTB_TYPE_HOST2GUC:
>>>>> return "SEND";
>>>>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
>>>>> + case GUC_CTB_TYPE_GUC2HOST:
>>>>> return "RECV";
>>>>> default:
>>>>> return "<invalid>";
>>>>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
>>>>> intel_guc_ct_buffer *ctb,
>>>>> guc_ct_buffer_reset(ctb);
>>>>> }
>>>>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
>>>>> - u32 desc_addr,
>>>>> - u32 type)
>>>>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
>>>>> type,
>>>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>>>> {
>>>>> - u32 action[] = {
>>>>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
>>>>> - desc_addr,
>>>>> - sizeof(struct guc_ct_buffer_desc),
>>>>> - type
>>>>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>>>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
>>>>
>>>> IMO we could use a macro or 2 for the HXG header, to avoid all these
>>>> lines, which are hard to read. something like:
>>>>
>>>> GUC_HXG_HEADER(origin, type, data, action) \
>>>> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
>>>> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
>>>> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
>>>> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
>>>>
>>>> H2G_HEADER(type, data, action) \
>>>> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
>>>>
>>>> and then call
>>>>
>>>> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
>>>>
>>>>
>>>> Not a blocker.
>>>>
>>>> Daniele
>>>>
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
>>>>> 1) |
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
>>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
>>>>> };
>>>>> - /* Can't use generic send(), CT registration must go over MMIO */
>>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>>>> NULL, 0);
>>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>>>> GUC_CTB_TYPE_GUC2HOST);
>>>>> + GEM_BUG_ON(size % SZ_4K);
>>>>> +
>>>>> + /* CT registration must go over MMIO */
>>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>>>> NULL, 0);
>>>>> }
>>>>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
>>>>> desc_addr, u32 type)
>>>>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
>>>>> + u32 desc_addr, u32 buff_addr, u32 size)
>>>>> {
>>>>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
>>>>> desc_addr, type);
>>>>> + int err;
>>>>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
>>>>> + desc_addr, buff_addr, size);
>>>>> if (unlikely(err))
>>>>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
>>>>> guc_ct_buffer_type_to_str(type), err);
>>>>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
>>>>> intel_guc_ct *ct, u32 desc_addr, u32 type)
>>>>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
>>>>> u32 type)
>>>>> {
>>>>> - u32 action[] = {
>>>>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
>>>>> - CTB_OWNER_HOST,
>>>>> - type
>>>>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
>>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
>>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
>>>>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
>>>>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
>>>>> };
>>>>> - /* Can't use generic send(), CT deregistration must go over
>>>>> MMIO */
>>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
>>>>> NULL, 0);
>>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
>>>>> GUC_CTB_TYPE_GUC2HOST);
>>>>> +
>>>>> + /* CT deregistration must go over MMIO */
>>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
>>>>> NULL, 0);
>>>>> }
>>>>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
>>>>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
>>>>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>>> {
>>>>> struct intel_guc *guc = ct_to_guc(ct);
>>>>> - u32 base, cmds;
>>>>> + u32 base, desc, cmds;
>>>>> void *blob;
>>>>> int err;
>>>>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
>>>>> /* (re)initialize descriptors */
>>>>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>>>> guc_ct_buffer_reset(&ct->ctbs.send);
>>>>> -
>>>>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>>>> guc_ct_buffer_reset(&ct->ctbs.recv);
>>>>> /*
>>>>> * Register both CT buffers starting with RECV buffer.
>>>>> * Descriptors are in first half of the blob.
>>>>> */
>>>>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
>>>>> blob),
>>>>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>>>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
>>>>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
>>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
>>>>> + desc, cmds, ct->ctbs.recv.size * 4);
>>>>> +
>>>>> if (unlikely(err))
>>>>> goto err_out;
>>>>> - err = ct_register_buffer(ct, base +
>>>>> ptrdiff(ct->ctbs.send.desc, blob),
>>>>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>>>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
>>>>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
>>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
>>>>> + desc, cmds, ct->ctbs.send.size * 4);
>>>>> +
>>>>> if (unlikely(err))
>>>>> goto err_deregister;
>>>>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
>>>>> return 0;
>>>>> err_deregister:
>>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>>>> err_out:
>>>>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
>>>>> return err;
>>>>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
>>>>> ct->enabled = false;
>>>>> if (intel_guc_is_fw_running(guc)) {
>>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
>>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
>>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
>>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
>>>>> }
>>>>> }
>>>>
>>>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
2021-06-10 13:19 ` [Intel-gfx] " Michal Wajdeczko
@ 2021-06-11 18:43 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-11 18:43 UTC (permalink / raw)
To: Michal Wajdeczko
Cc: intel-gfx, Daniele Ceraolo Spurio, dri-devel, John Harrison
On Thu, Jun 10, 2021 at 03:19:50PM +0200, Michal Wajdeczko wrote:
>
>
> On 10.06.2021 06:38, Matthew Brost wrote:
> > On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 09.06.2021 19:36, John Harrison wrote:
> >>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> >>>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> >>>>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>>>>
> >>>>> Definition of the CTB registration action has changed.
> >>>>> Add some ABI documentation and implement required changes.
> >>>>>
> >>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >>>>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
> >>>>> ---
> >>>>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
> >>>>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
> >>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
> >>>>> 3 files changed, 152 insertions(+), 35 deletions(-)
> >>>>>
> >>>>> 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 90efef8a73e4..6426fc183692 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
> >>>>> @@ -6,6 +6,113 @@
> >>>>> #ifndef _ABI_GUC_ACTIONS_ABI_H
> >>>>> #define _ABI_GUC_ACTIONS_ABI_H
> >>>>> +/**
> >>>>> + * DOC: HOST2GUC_REGISTER_CTB
> >>>>> + *
> >>>>> + * This message is used as part of the `CTB based communication`_
> >>>>> setup.
> >>>>> + *
> >>>>> + * This message must be sent as `MMIO HXG Message`_.
> >>>>> + *
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_HOST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_REQUEST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:16 | DATA0 =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
> >>>>> 0x5200 |
> >>>>
> >>>> Specs says 4505
> >>>>
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 1 | 31:12 | RESERVED =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 11:8 | **TYPE** - type for the `CT
> >>>>> Buffer`_ |
> >>>>> + * | |
> >>>>> | |
> >>>>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
> >>>>> 0 |
> >>>>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
> >>>>> 1 |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
> >>>>> minus 1 |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
> >>>>> Descriptor`_ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
> >>>>> Buffer`_ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> +*
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_GUC_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:0 | DATA0 =
> >>>>> MBZ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + */
> >>>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
> >>>>
> >>>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> >>>> at some point I don;t think this deserves a FIXME since nothing is
> >>>> incorrect.
> >>>>
> >>>>> +
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
> >>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
> >>>>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>>>> +#define GUC_CTB_TYPE_HOST2GUC 0u
> >>>>> +#define GUC_CTB_TYPE_GUC2HOST 1u
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
> >>>>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
> >>>>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>>>
> >>>> The full mask still seems like overkill to me and I still think we
> >>>> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
> >>>> on it.
> >>>>
> >>>>> +
> >>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
> >>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>>>> +
> >>>>> +/**
> >>>>> + * DOC: HOST2GUC_DEREGISTER_CTB
> >>>>> + *
> >>>>> + * This message is used as part of the `CTB based communication`_
> >>>>> teardown.
> >>>>> + *
> >>>>> + * This message must be sent as `MMIO HXG Message`_.
> >>>>> + *
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_HOST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_REQUEST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:16 | DATA0 =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
> >>>>> 0x5201 |
> >>>>
> >>>> Specs says 4506
> >>>>
> >>> I would say that the enum value should not be included in the structure
> >>> definition. I would also argue that there is no point in repeating the
> >>> common header structure for every single H2G action definition. That is
> >>> just overly verbose and makes it harder to read the spec. It implies
> >>> that every action has a different header structure and must be coded
> >>> individually.
> >>
> >> but some actions are defined as REQUEST some as EVENT, so we need to say
> >> that, also each REQUEST action may define its own DATA0, so again we
> >> still need to define these bits somewhere
> >>
> >>>
> >>> Personally, I don't believe we should be replicating the entire GuC API
> >>> spec in the driver header files anyway. This is not something that is
> >>> defined by the i915 driver so the i915 driver should not be defining it!
> >>> Instead, just include a link or pointer to where the actual spec can be
> >>> found. We don't copy the entire bspec page for every register that the
> >>> driver touches, so why should this be any different?
> >
> > I agree with John on this one. We plan publishing the GuC, right? Let's
>
> Do you know of any ETA? I don't
>
No, I don't.
> and likely the same promise was given few years back when GuC was
> introduced in upstream, I don't want to have just code that we can't
> compare with specification (in any form)
>
>
> > just point to it in the kernel DOC.
> >
> > Also at some all these defines really should be auto-generated. I
> > suppose if these headers are auto-generated, I could live with these
>
> I was also hoping to get these ABI headers auto-generated before we
> start to used them for good, unfortunately it was quite the opposite:
> for some time these hand crafted tables were used as input for
> discussion and then to prepare machine readable formats, but the only
> tool currently available (and still WIP) is for generating spec
> documentation
>
A tool really shouldn't be too hard to write to auto-generate headers.
Every other project I've worked on did tons of auto-generation of code
and I've personally written about 5 of these tools. This would be great
project for an intern or a newer employee.
> > files generating kernel DOC. I can't really live with having to maintain
> > a table like this for every action manually.
>
> the goal is to freeze ABI so no maintenance will be necessary, except
> adding new actions, and that's also the reason to keep these ABI files
> separate from the rest of our headers, where we can add/modify/improve
> any helpers/wrappers as we want.
>
> and I don't recall that you were forced to modify any of such tables
> yet, nor were asked to manually prepare them for the rest of the
> existing actions, especially GuC submission ones, so why complain?
>
I'm fine with this going in, I just personally don't want to have to
manually create a table like this for every GuC submission action.
Matt
> >
> > Matt
> >
> >>
> >> to some extend we have to replicate at least part of the GuC ABI spec,
> >> part that defines all bits, and IMHO there is nothing wrong if it comes
> >> with full message layout definitions, especially if you compare that
> >> with previous approach, were H2G action definitions were limited just to
> >> single enum value (and to find out how to use given H2G you had to look
> >> into firmware source code)
> >>
> >> so while we keep these abi.h files in kernel repo, they shall be treated
> >> as read-only imported external interface definitions, from which we just
> >> use all #define for coding and DOC: for documentation (latter at least
> >> until GuC will release its spec to the public)
> >>
> >>>
> >>> John.
> >>>
> >>>
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 1 | 31:12 | RESERVED =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 11:8 | **TYPE** - type of the `CT
> >>>>> Buffer`_ |
> >>>>> + * | |
> >>>>> | |
> >>>>> + * | | | see
> >>>>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 7:0 | RESERVED =
> >>>>> MBZ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> +*
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_GUC_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:0 | DATA0 =
> >>>>> MBZ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + */
> >>>>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
> >>>>> 0x5201
> >>>>
> >>>> Same comment for the FIXME as above
> >>>>
> >>>>> +
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
> >>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
> >>>>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
> >>>>> +
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
> >>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>>>> +
> >>>>> +/* legacy definitions */
> >>>>> +
> >>>>> enum intel_guc_action {
> >>>>> INTEL_GUC_ACTION_DEFAULT = 0x0,
> >>>>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
> >>>>> diff --git
> >>>>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> index c2a069a78e01..127b256a662c 100644
> >>>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
> >>>>> == 64);
> >>>>> * - **flags**, holds various bits to control message handling
> >>>>> */
> >>>>> -/* Type of command transport buffer */
> >>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> >>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> >>>>> -
> >>>>> /*
> >>>>> * Definition of the command transport message header (DW0)
> >>>>> *
> >>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> index 3241a477196f..6a29be779cc9 100644
> >>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
> >>>>> *ct)
> >>>>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
> >>>>> {
> >>>>> switch (type) {
> >>>>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> >>>>> + case GUC_CTB_TYPE_HOST2GUC:
> >>>>> return "SEND";
> >>>>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> >>>>> + case GUC_CTB_TYPE_GUC2HOST:
> >>>>> return "RECV";
> >>>>> default:
> >>>>> return "<invalid>";
> >>>>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
> >>>>> intel_guc_ct_buffer *ctb,
> >>>>> guc_ct_buffer_reset(ctb);
> >>>>> }
> >>>>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
> >>>>> - u32 desc_addr,
> >>>>> - u32 type)
> >>>>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
> >>>>> type,
> >>>>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>>>> {
> >>>>> - u32 action[] = {
> >>>>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
> >>>>> - desc_addr,
> >>>>> - sizeof(struct guc_ct_buffer_desc),
> >>>>> - type
> >>>>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>>>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
> >>>>
> >>>> IMO we could use a macro or 2 for the HXG header, to avoid all these
> >>>> lines, which are hard to read. something like:
> >>>>
> >>>> GUC_HXG_HEADER(origin, type, data, action) \
> >>>> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> >>>> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> >>>> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> >>>> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
> >>>>
> >>>> H2G_HEADER(type, data, action) \
> >>>> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
> >>>>
> >>>> and then call
> >>>>
> >>>> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
> >>>>
> >>>>
> >>>> Not a blocker.
> >>>>
> >>>> Daniele
> >>>>
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
> >>>>> 1) |
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
> >>>>> };
> >>>>> - /* Can't use generic send(), CT registration must go over MMIO */
> >>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>>>> NULL, 0);
> >>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>>>> GUC_CTB_TYPE_GUC2HOST);
> >>>>> + GEM_BUG_ON(size % SZ_4K);
> >>>>> +
> >>>>> + /* CT registration must go over MMIO */
> >>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>>>> NULL, 0);
> >>>>> }
> >>>>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
> >>>>> desc_addr, u32 type)
> >>>>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
> >>>>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>>>> {
> >>>>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
> >>>>> desc_addr, type);
> >>>>> + int err;
> >>>>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
> >>>>> + desc_addr, buff_addr, size);
> >>>>> if (unlikely(err))
> >>>>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
> >>>>> guc_ct_buffer_type_to_str(type), err);
> >>>>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
> >>>>> intel_guc_ct *ct, u32 desc_addr, u32 type)
> >>>>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
> >>>>> u32 type)
> >>>>> {
> >>>>> - u32 action[] = {
> >>>>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
> >>>>> - CTB_OWNER_HOST,
> >>>>> - type
> >>>>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>>>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
> >>>>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>>>> };
> >>>>> - /* Can't use generic send(), CT deregistration must go over
> >>>>> MMIO */
> >>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>>>> NULL, 0);
> >>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>>>> GUC_CTB_TYPE_GUC2HOST);
> >>>>> +
> >>>>> + /* CT deregistration must go over MMIO */
> >>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>>>> NULL, 0);
> >>>>> }
> >>>>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
> >>>>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
> >>>>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>>> {
> >>>>> struct intel_guc *guc = ct_to_guc(ct);
> >>>>> - u32 base, cmds;
> >>>>> + u32 base, desc, cmds;
> >>>>> void *blob;
> >>>>> int err;
> >>>>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
> >>>>> /* (re)initialize descriptors */
> >>>>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>>>> guc_ct_buffer_reset(&ct->ctbs.send);
> >>>>> -
> >>>>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>>>> guc_ct_buffer_reset(&ct->ctbs.recv);
> >>>>> /*
> >>>>> * Register both CT buffers starting with RECV buffer.
> >>>>> * Descriptors are in first half of the blob.
> >>>>> */
> >>>>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
> >>>>> blob),
> >>>>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>>>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
> >>>>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
> >>>>> + desc, cmds, ct->ctbs.recv.size * 4);
> >>>>> +
> >>>>> if (unlikely(err))
> >>>>> goto err_out;
> >>>>> - err = ct_register_buffer(ct, base +
> >>>>> ptrdiff(ct->ctbs.send.desc, blob),
> >>>>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>>>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
> >>>>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
> >>>>> + desc, cmds, ct->ctbs.send.size * 4);
> >>>>> +
> >>>>> if (unlikely(err))
> >>>>> goto err_deregister;
> >>>>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>>> return 0;
> >>>>> err_deregister:
> >>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>>>> err_out:
> >>>>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
> >>>>> return err;
> >>>>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
> >>>>> ct->enabled = false;
> >>>>> if (intel_guc_is_fw_running(guc)) {
> >>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
> >>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>>>> }
> >>>>> }
> >>>>
> >>>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action
@ 2021-06-11 18:43 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-11 18:43 UTC (permalink / raw)
To: Michal Wajdeczko; +Cc: intel-gfx, dri-devel
On Thu, Jun 10, 2021 at 03:19:50PM +0200, Michal Wajdeczko wrote:
>
>
> On 10.06.2021 06:38, Matthew Brost wrote:
> > On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 09.06.2021 19:36, John Harrison wrote:
> >>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
> >>>> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> >>>>> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>>>>
> >>>>> Definition of the CTB registration action has changed.
> >>>>> Add some ABI documentation and implement required changes.
> >>>>>
> >>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> >>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >>>>> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> #4
> >>>>> ---
> >>>>> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++++++++++++++
> >>>>> .../gt/uc/abi/guc_communication_ctb_abi.h | 4 -
> >>>>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 76 ++++++++-----
> >>>>> 3 files changed, 152 insertions(+), 35 deletions(-)
> >>>>>
> >>>>> 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 90efef8a73e4..6426fc183692 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
> >>>>> @@ -6,6 +6,113 @@
> >>>>> #ifndef _ABI_GUC_ACTIONS_ABI_H
> >>>>> #define _ABI_GUC_ACTIONS_ABI_H
> >>>>> +/**
> >>>>> + * DOC: HOST2GUC_REGISTER_CTB
> >>>>> + *
> >>>>> + * This message is used as part of the `CTB based communication`_
> >>>>> setup.
> >>>>> + *
> >>>>> + * This message must be sent as `MMIO HXG Message`_.
> >>>>> + *
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_HOST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_REQUEST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:16 | DATA0 =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
> >>>>> 0x5200 |
> >>>>
> >>>> Specs says 4505
> >>>>
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 1 | 31:12 | RESERVED =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 11:8 | **TYPE** - type for the `CT
> >>>>> Buffer`_ |
> >>>>> + * | |
> >>>>> | |
> >>>>> + * | | | - _`GUC_CTB_TYPE_HOST2GUC` =
> >>>>> 0 |
> >>>>> + * | | | - _`GUC_CTB_TYPE_GUC2HOST` =
> >>>>> 1 |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
> >>>>> minus 1 |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 2 | 31:0 | **DESC_ADDR** - GGTT address of the `CTB
> >>>>> Descriptor`_ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 3 | 31:0 | **BUFF_ADDF** - GGTT address of the `CT
> >>>>> Buffer`_ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> +*
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_GUC_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:0 | DATA0 =
> >>>>> MBZ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + */
> >>>>> +#define GUC_ACTION_HOST2GUC_REGISTER_CTB 0x4505 // FIXME 0x5200
> >>>>
> >>>> Why FIXME? AFAICS the specs still says 4505, even if we plan to update
> >>>> at some point I don;t think this deserves a FIXME since nothing is
> >>>> incorrect.
> >>>>
> >>>>> +
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN
> >>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_0_MBZ
> >>>>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>>>> +#define GUC_CTB_TYPE_HOST2GUC 0u
> >>>>> +#define GUC_CTB_TYPE_GUC2HOST 1u
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE (0xff << 0)
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR
> >>>>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>>>> +#define HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR
> >>>>> GUC_HXG_REQUEST_MSG_n_DATAn
> >>>>
> >>>> The full mask still seems like overkill to me and I still think we
> >>>> should use BIT()/GENMASK() and a _MASK prefix, but not going to block
> >>>> on it.
> >>>>
> >>>>> +
> >>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_LEN
> >>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>>>> +#define HOST2GUC_REGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>>>> +
> >>>>> +/**
> >>>>> + * DOC: HOST2GUC_DEREGISTER_CTB
> >>>>> + *
> >>>>> + * This message is used as part of the `CTB based communication`_
> >>>>> teardown.
> >>>>> + *
> >>>>> + * This message must be sent as `MMIO HXG Message`_.
> >>>>> + *
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_HOST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_REQUEST_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:16 | DATA0 =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 15:0 | ACTION = _`GUC_ACTION_HOST2GUC_DEREGISTER_CTB` =
> >>>>> 0x5201 |
> >>>>
> >>>> Specs says 4506
> >>>>
> >>> I would say that the enum value should not be included in the structure
> >>> definition. I would also argue that there is no point in repeating the
> >>> common header structure for every single H2G action definition. That is
> >>> just overly verbose and makes it harder to read the spec. It implies
> >>> that every action has a different header structure and must be coded
> >>> individually.
> >>
> >> but some actions are defined as REQUEST some as EVENT, so we need to say
> >> that, also each REQUEST action may define its own DATA0, so again we
> >> still need to define these bits somewhere
> >>
> >>>
> >>> Personally, I don't believe we should be replicating the entire GuC API
> >>> spec in the driver header files anyway. This is not something that is
> >>> defined by the i915 driver so the i915 driver should not be defining it!
> >>> Instead, just include a link or pointer to where the actual spec can be
> >>> found. We don't copy the entire bspec page for every register that the
> >>> driver touches, so why should this be any different?
> >
> > I agree with John on this one. We plan publishing the GuC, right? Let's
>
> Do you know of any ETA? I don't
>
No, I don't.
> and likely the same promise was given few years back when GuC was
> introduced in upstream, I don't want to have just code that we can't
> compare with specification (in any form)
>
>
> > just point to it in the kernel DOC.
> >
> > Also at some all these defines really should be auto-generated. I
> > suppose if these headers are auto-generated, I could live with these
>
> I was also hoping to get these ABI headers auto-generated before we
> start to used them for good, unfortunately it was quite the opposite:
> for some time these hand crafted tables were used as input for
> discussion and then to prepare machine readable formats, but the only
> tool currently available (and still WIP) is for generating spec
> documentation
>
A tool really shouldn't be too hard to write to auto-generate headers.
Every other project I've worked on did tons of auto-generation of code
and I've personally written about 5 of these tools. This would be great
project for an intern or a newer employee.
> > files generating kernel DOC. I can't really live with having to maintain
> > a table like this for every action manually.
>
> the goal is to freeze ABI so no maintenance will be necessary, except
> adding new actions, and that's also the reason to keep these ABI files
> separate from the rest of our headers, where we can add/modify/improve
> any helpers/wrappers as we want.
>
> and I don't recall that you were forced to modify any of such tables
> yet, nor were asked to manually prepare them for the rest of the
> existing actions, especially GuC submission ones, so why complain?
>
I'm fine with this going in, I just personally don't want to have to
manually create a table like this for every GuC submission action.
Matt
> >
> > Matt
> >
> >>
> >> to some extend we have to replicate at least part of the GuC ABI spec,
> >> part that defines all bits, and IMHO there is nothing wrong if it comes
> >> with full message layout definitions, especially if you compare that
> >> with previous approach, were H2G action definitions were limited just to
> >> single enum value (and to find out how to use given H2G you had to look
> >> into firmware source code)
> >>
> >> so while we keep these abi.h files in kernel repo, they shall be treated
> >> as read-only imported external interface definitions, from which we just
> >> use all #define for coding and DOC: for documentation (latter at least
> >> until GuC will release its spec to the public)
> >>
> >>>
> >>> John.
> >>>
> >>>
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | 1 | 31:12 | RESERVED =
> >>>>> MBZ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 11:8 | **TYPE** - type of the `CT
> >>>>> Buffer`_ |
> >>>>> + * | |
> >>>>> | |
> >>>>> + * | | | see
> >>>>> `GUC_ACTION_HOST2GUC_REGISTER_CTB`_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 7:0 | RESERVED =
> >>>>> MBZ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> +*
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + * | | Bits |
> >>>>> Description |
> >>>>> + *
> >>>>> +===+=======+==============================================================+
> >>>>>
> >>>>> + * | 0 | 31 | ORIGIN =
> >>>>> GUC_HXG_ORIGIN_GUC_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 30:28 | TYPE =
> >>>>> GUC_HXG_TYPE_RESPONSE_SUCCESS_ |
> >>>>> + * |
> >>>>> +-------+--------------------------------------------------------------+
> >>>>> + * | | 27:0 | DATA0 =
> >>>>> MBZ |
> >>>>> + *
> >>>>> +---+-------+--------------------------------------------------------------+
> >>>>>
> >>>>> + */
> >>>>> +#define GUC_ACTION_HOST2GUC_DEREGISTER_CTB 0x4506 // FIXME
> >>>>> 0x5201
> >>>>
> >>>> Same comment for the FIXME as above
> >>>>
> >>>>> +
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN
> >>>>> (GUC_HXG_REQUEST_MSG_MIN_LEN + 1u)
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_0_MBZ
> >>>>> GUC_HXG_REQUEST_MSG_0_DATA0
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ (0xfffff << 12)
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE (0xf << 8)
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_MBZ2 (0xff << 0)
> >>>>> +
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_LEN
> >>>>> GUC_HXG_RESPONSE_MSG_MIN_LEN
> >>>>> +#define HOST2GUC_DEREGISTER_CTB_RESPONSE_MSG_0_MBZ
> >>>>> GUC_HXG_RESPONSE_MSG_0_DATA0
> >>>>> +
> >>>>> +/* legacy definitions */
> >>>>> +
> >>>>> enum intel_guc_action {
> >>>>> INTEL_GUC_ACTION_DEFAULT = 0x0,
> >>>>> INTEL_GUC_ACTION_REQUEST_PREEMPTION = 0x2,
> >>>>> diff --git
> >>>>> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> index c2a069a78e01..127b256a662c 100644
> >>>>> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> >>>>> @@ -112,10 +112,6 @@ static_assert(sizeof(struct guc_ct_buffer_desc)
> >>>>> == 64);
> >>>>> * - **flags**, holds various bits to control message handling
> >>>>> */
> >>>>> -/* Type of command transport buffer */
> >>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_SEND 0x0u
> >>>>> -#define INTEL_GUC_CT_BUFFER_TYPE_RECV 0x1u
> >>>>> -
> >>>>> /*
> >>>>> * Definition of the command transport message header (DW0)
> >>>>> *
> >>>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> index 3241a477196f..6a29be779cc9 100644
> >>>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> >>>>> @@ -103,9 +103,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct
> >>>>> *ct)
> >>>>> static inline const char *guc_ct_buffer_type_to_str(u32 type)
> >>>>> {
> >>>>> switch (type) {
> >>>>> - case INTEL_GUC_CT_BUFFER_TYPE_SEND:
> >>>>> + case GUC_CTB_TYPE_HOST2GUC:
> >>>>> return "SEND";
> >>>>> - case INTEL_GUC_CT_BUFFER_TYPE_RECV:
> >>>>> + case GUC_CTB_TYPE_GUC2HOST:
> >>>>> return "RECV";
> >>>>> default:
> >>>>> return "<invalid>";
> >>>>> @@ -136,25 +136,33 @@ static void guc_ct_buffer_init(struct
> >>>>> intel_guc_ct_buffer *ctb,
> >>>>> guc_ct_buffer_reset(ctb);
> >>>>> }
> >>>>> -static int guc_action_register_ct_buffer(struct intel_guc *guc,
> >>>>> - u32 desc_addr,
> >>>>> - u32 type)
> >>>>> +static int guc_action_register_ct_buffer(struct intel_guc *guc, u32
> >>>>> type,
> >>>>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>>>> {
> >>>>> - u32 action[] = {
> >>>>> - INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER,
> >>>>> - desc_addr,
> >>>>> - sizeof(struct guc_ct_buffer_desc),
> >>>>> - type
> >>>>> + u32 request[HOST2GUC_REGISTER_CTB_REQUEST_MSG_LEN] = {
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>>>> GUC_ACTION_HOST2GUC_REGISTER_CTB),
> >>>>
> >>>> IMO we could use a macro or 2 for the HXG header, to avoid all these
> >>>> lines, which are hard to read. something like:
> >>>>
> >>>> GUC_HXG_HEADER(origin, type, data, action) \
> >>>> (FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, origin) | \
> >>>> FIELD_PREP(GUC_HXG_MSG_0_TYPE, type) | \
> >>>> FIELD_PREP(GUC_HXG_MSG_0_DATA0, data) | \
> >>>> FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION, action))
> >>>>
> >>>> H2G_HEADER(type, data, action) \
> >>>> GUC_HXG_HEADER(GUC_HXG_ORIGIN_HOST, type, data, action)
> >>>>
> >>>> and then call
> >>>>
> >>>> H2G_HEADER(GUC_HXG_TYPE_REQUEST, 0, GUC_ACTION_HOST2GUC_REGISTER_CTB)
> >>>>
> >>>>
> >>>> Not a blocker.
> >>>>
> >>>> Daniele
> >>>>
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_SIZE, size / SZ_4K -
> >>>>> 1) |
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_2_DESC_ADDR, desc_addr),
> >>>>> + FIELD_PREP(HOST2GUC_REGISTER_CTB_REQUEST_MSG_3_BUFF_ADDR, buff_addr),
> >>>>> };
> >>>>> - /* Can't use generic send(), CT registration must go over MMIO */
> >>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>>>> NULL, 0);
> >>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>>>> GUC_CTB_TYPE_GUC2HOST);
> >>>>> + GEM_BUG_ON(size % SZ_4K);
> >>>>> +
> >>>>> + /* CT registration must go over MMIO */
> >>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>>>> NULL, 0);
> >>>>> }
> >>>>> -static int ct_register_buffer(struct intel_guc_ct *ct, u32
> >>>>> desc_addr, u32 type)
> >>>>> +static int ct_register_buffer(struct intel_guc_ct *ct, u32 type,
> >>>>> + u32 desc_addr, u32 buff_addr, u32 size)
> >>>>> {
> >>>>> - int err = guc_action_register_ct_buffer(ct_to_guc(ct),
> >>>>> desc_addr, type);
> >>>>> + int err;
> >>>>> + err = guc_action_register_ct_buffer(ct_to_guc(ct), type,
> >>>>> + desc_addr, buff_addr, size);
> >>>>> if (unlikely(err))
> >>>>> CT_ERROR(ct, "Failed to register %s buffer (err=%d)\n",
> >>>>> guc_ct_buffer_type_to_str(type), err);
> >>>>> @@ -163,14 +171,17 @@ static int ct_register_buffer(struct
> >>>>> intel_guc_ct *ct, u32 desc_addr, u32 type)
> >>>>> static int guc_action_deregister_ct_buffer(struct intel_guc *guc,
> >>>>> u32 type)
> >>>>> {
> >>>>> - u32 action[] = {
> >>>>> - INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER,
> >>>>> - CTB_OWNER_HOST,
> >>>>> - type
> >>>>> + u32 request[HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_LEN] = {
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN, GUC_HXG_ORIGIN_HOST) |
> >>>>> + FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
> >>>>> + FIELD_PREP(GUC_HXG_REQUEST_MSG_0_ACTION,
> >>>>> GUC_ACTION_HOST2GUC_DEREGISTER_CTB),
> >>>>> + FIELD_PREP(HOST2GUC_DEREGISTER_CTB_REQUEST_MSG_1_TYPE, type),
> >>>>> };
> >>>>> - /* Can't use generic send(), CT deregistration must go over
> >>>>> MMIO */
> >>>>> - return intel_guc_send_mmio(guc, action, ARRAY_SIZE(action),
> >>>>> NULL, 0);
> >>>>> + GEM_BUG_ON(type != GUC_CTB_TYPE_HOST2GUC && type !=
> >>>>> GUC_CTB_TYPE_GUC2HOST);
> >>>>> +
> >>>>> + /* CT deregistration must go over MMIO */
> >>>>> + return intel_guc_send_mmio(guc, request, ARRAY_SIZE(request),
> >>>>> NULL, 0);
> >>>>> }
> >>>>> static int ct_deregister_buffer(struct intel_guc_ct *ct, u32 type)
> >>>>> @@ -258,7 +269,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
> >>>>> int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>>> {
> >>>>> struct intel_guc *guc = ct_to_guc(ct);
> >>>>> - u32 base, cmds;
> >>>>> + u32 base, desc, cmds;
> >>>>> void *blob;
> >>>>> int err;
> >>>>> @@ -274,23 +285,26 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>>> GEM_BUG_ON(blob != ct->ctbs.send.desc);
> >>>>> /* (re)initialize descriptors */
> >>>>> - cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>>>> guc_ct_buffer_reset(&ct->ctbs.send);
> >>>>> -
> >>>>> - cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>>>> guc_ct_buffer_reset(&ct->ctbs.recv);
> >>>>> /*
> >>>>> * Register both CT buffers starting with RECV buffer.
> >>>>> * Descriptors are in first half of the blob.
> >>>>> */
> >>>>> - err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc,
> >>>>> blob),
> >>>>> - INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>>>> + desc = base + ptrdiff(ct->ctbs.recv.desc, blob);
> >>>>> + cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
> >>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_GUC2HOST,
> >>>>> + desc, cmds, ct->ctbs.recv.size * 4);
> >>>>> +
> >>>>> if (unlikely(err))
> >>>>> goto err_out;
> >>>>> - err = ct_register_buffer(ct, base +
> >>>>> ptrdiff(ct->ctbs.send.desc, blob),
> >>>>> - INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>>>> + desc = base + ptrdiff(ct->ctbs.send.desc, blob);
> >>>>> + cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
> >>>>> + err = ct_register_buffer(ct, GUC_CTB_TYPE_HOST2GUC,
> >>>>> + desc, cmds, ct->ctbs.send.size * 4);
> >>>>> +
> >>>>> if (unlikely(err))
> >>>>> goto err_deregister;
> >>>>> @@ -299,7 +313,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> >>>>> return 0;
> >>>>> err_deregister:
> >>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>>>> err_out:
> >>>>> CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
> >>>>> return err;
> >>>>> @@ -318,8 +332,8 @@ void intel_guc_ct_disable(struct intel_guc_ct *ct)
> >>>>> ct->enabled = false;
> >>>>> if (intel_guc_is_fw_running(guc)) {
> >>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_SEND);
> >>>>> - ct_deregister_buffer(ct, INTEL_GUC_CT_BUFFER_TYPE_RECV);
> >>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_HOST2GUC);
> >>>>> + ct_deregister_buffer(ct, GUC_CTB_TYPE_GUC2HOST);
> >>>>> }
> >>>>> }
> >>>>
> >>>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 00/13] Update firmware to v62.0.0
2021-06-07 22:19 ` [Intel-gfx] " Daniele Ceraolo Spurio
@ 2021-06-11 18:44 ` Matthew Brost
-1 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-11 18:44 UTC (permalink / raw)
To: Daniele Ceraolo Spurio
Cc: intel-gfx, john.c.harrison, dri-devel, Michal.Wajdeczko
On Mon, Jun 07, 2021 at 03:19:11PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > As part of enabling GuC submission [1] we need to update to the latest
> > and greatest firmware. This series does that. This is a destructive
> > change. e.g. Without all the patches in this series it will break the
> > i915 driver. As such, after we review all of these patches they will
> > squashed into a single patch for merging.
>
> Can you resubmit with an added HAX patch for enable_guc=2 after the first
> round of review? none of the machines in CI seems to have attempted to load
> the guc, not even cfl-guc and kbl-guc. If all the reviews are good maybe
> just resubmit the squashed patch and the enablement with a CI tag, so we can
> merge once we get the results.
>
Done on trybot, results looks good.
https://patchwork.freedesktop.org/series/91341/
Matt
> Daniele
>
> >
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >
> > [1] https://patchwork.freedesktop.org/series/89844/
> >
> > John Harrison (3):
> > drm/i915/guc: Support per context scheduling policies
> > drm/i915/guc: Unified GuC log
> > drm/i915/guc: Update firmware to v62.0.0
> >
> > Michal Wajdeczko (10):
> > drm/i915/guc: Introduce unified HXG messages
> > drm/i915/guc: Update MMIO based communication
> > drm/i915/guc: Update CTB response status definition
> > drm/i915/guc: Add flag for mark broken CTB
> > drm/i915/guc: New definition of the CTB descriptor
> > drm/i915/guc: New definition of the CTB registration action
> > drm/i915/guc: New CTB based communication
> > drm/i915/doc: Include GuC ABI documentation
> > drm/i915/guc: Kill guc_clients.ct_pool
> > drm/i915/guc: Kill ads.client_info
> >
> > Documentation/gpu/i915.rst | 8 +
> > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++
> > .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +++++--
> > .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--
> > .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++++++++++
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 107 ++++--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 45 +--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +++++++++---------
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 75 +---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 +-
> > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 +-
> > 13 files changed, 750 insertions(+), 420 deletions(-)
> >
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0
@ 2021-06-11 18:44 ` Matthew Brost
0 siblings, 0 replies; 87+ messages in thread
From: Matthew Brost @ 2021-06-11 18:44 UTC (permalink / raw)
To: Daniele Ceraolo Spurio; +Cc: intel-gfx, dri-devel
On Mon, Jun 07, 2021 at 03:19:11PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > As part of enabling GuC submission [1] we need to update to the latest
> > and greatest firmware. This series does that. This is a destructive
> > change. e.g. Without all the patches in this series it will break the
> > i915 driver. As such, after we review all of these patches they will
> > squashed into a single patch for merging.
>
> Can you resubmit with an added HAX patch for enable_guc=2 after the first
> round of review? none of the machines in CI seems to have attempted to load
> the guc, not even cfl-guc and kbl-guc. If all the reviews are good maybe
> just resubmit the squashed patch and the enablement with a CI tag, so we can
> merge once we get the results.
>
Done on trybot, results looks good.
https://patchwork.freedesktop.org/series/91341/
Matt
> Daniele
>
> >
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> >
> > [1] https://patchwork.freedesktop.org/series/89844/
> >
> > John Harrison (3):
> > drm/i915/guc: Support per context scheduling policies
> > drm/i915/guc: Unified GuC log
> > drm/i915/guc: Update firmware to v62.0.0
> >
> > Michal Wajdeczko (10):
> > drm/i915/guc: Introduce unified HXG messages
> > drm/i915/guc: Update MMIO based communication
> > drm/i915/guc: Update CTB response status definition
> > drm/i915/guc: Add flag for mark broken CTB
> > drm/i915/guc: New definition of the CTB descriptor
> > drm/i915/guc: New definition of the CTB registration action
> > drm/i915/guc: New CTB based communication
> > drm/i915/doc: Include GuC ABI documentation
> > drm/i915/guc: Kill guc_clients.ct_pool
> > drm/i915/guc: Kill ads.client_info
> >
> > Documentation/gpu/i915.rst | 8 +
> > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 107 ++++++
> > .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +++++--
> > .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--
> > .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++++++++++
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 107 ++++--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 45 +--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +++++++++---------
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 75 +---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 29 +-
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h | 6 +-
> > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 26 +-
> > 13 files changed, 750 insertions(+), 420 deletions(-)
> >
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 02/13] drm/i915/guc: Update MMIO based communication
2021-06-10 4:36 ` [PATCH 02/13] drm/i915/guc: Update MMIO based communication Matthew Brost
@ 2021-06-14 18:11 ` Daniele Ceraolo Spurio
0 siblings, 0 replies; 87+ messages in thread
From: Daniele Ceraolo Spurio @ 2021-06-14 18:11 UTC (permalink / raw)
To: Matthew Brost, intel-gfx, dri-devel; +Cc: john.c.harrison, Michal.Wajdeczko
On 6/9/2021 9:36 PM, Matthew Brost wrote:
> From: Michal Wajdeczko <michal.wajdeczko@intel.com>
>
> The MMIO based Host-to-GuC communication protocol has been
> updated to use unified HXG messages.
>
> Update our intel_guc_send_mmio() function by correctly handle
> BUSY, RETRY and FAILURE replies. Also update our documentation.
>
> Since some of the new MMIO actions may use DATA0 from MMIO HXG
> response, we must update intel_guc_send_mmio() to copy full response,
> including HXG header. There will be no impact to existing users as all
> of them are only relying just on return code.
>
> v2:
> (Daniele)
> - preffered -> preferred
> - Max MMIO DW set to 4
> - Update commit message
>
> GuC: 55.0.0
> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
> ---
> .../gt/uc/abi/guc_communication_mmio_abi.h | 65 +++++++------
> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
> 2 files changed, 98 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> index be066a62e9e0..bbf1ddb77434 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
> @@ -7,46 +7,43 @@
> #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
>
> /**
> - * DOC: MMIO based communication
> + * DOC: GuC MMIO based communication
> *
> - * The MMIO based communication between Host and GuC uses software scratch
> - * registers, where first register holds data treated as message header,
> - * and other registers are used to hold message payload.
> + * The MMIO based communication between Host and GuC relies on special
> + * hardware registers which format could be defined by the software
> + * (so called scratch registers).
> *
> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
> - * but no H2G command takes more than 8 parameters and the GuC FW
> - * itself uses an 8-element array to store the H2G message.
> + * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
> + * messages, which maximum length depends on number of available scratch
> + * registers, is directly written into those scratch registers.
> *
> - * +-----------+---------+---------+---------+
> - * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
> - * +-----------+---------+---------+---------+
> - * | header | optional payload |
> - * +======+====+=========+=========+=========+
> - * | 31:28|type| | | |
> - * +------+----+ | | |
> - * | 27:16|data| | | |
> - * +------+----+ | | |
> - * | 15:0|code| | | |
> - * +------+----+---------+---------+---------+
> + * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
> + * but no H2G command takes more than 4 parameters and the GuC firmware
> + * itself uses an 4-element array to store the H2G message.
I don;t think this part on how the GuC stores the data us true anymore,
so I'd just remove it. With that:
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Daniele
> *
> - * The message header consists of:
> + * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
> + * are, regardless on lower count, preferred over legacy ones.
> *
> - * - **type**, indicates message type
> - * - **code**, indicates message code, is specific for **type**
> - * - **data**, indicates message data, optional, depends on **code**
> - *
> - * The following message **types** are supported:
> - *
> - * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
> - * must be priovided in **code** field. Optional action specific parameters
> - * can be provided in remaining payload registers or **data** field.
> - *
> - * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
> - * action response status will be provided in **code** field. Optional
> - * response data can be returned in remaining payload registers or **data**
> - * field.
> + * The MMIO based communication is mainly used during driver initialization
> + * phase to setup the `CTB based communication`_ that will be used afterwards.
> */
>
> -#define GUC_MAX_MMIO_MSG_LEN 8
> +#define GUC_MAX_MMIO_MSG_LEN 4
> +
> +/**
> + * DOC: MMIO HXG Message
> + *
> + * Format of the MMIO messages follows definitions of `HXG Message`_.
> + *
> + * +---+-------+--------------------------------------------------------------+
> + * | | Bits | Description |
> + * +===+=======+==============================================================+
> + * | 0 | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+ | | |
> + * |...| | | Embedded `HXG Message`_ | |
> + * +---+-------+ | | |
> + * | n | 31:0 | +--------------------------------------------------------+ |
> + * +---+-------+--------------------------------------------------------------+
> + */
>
> #endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> index f147cb389a20..b773567cb080 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
> /*
> * This function implements the MMIO based host to GuC interface.
> */
> -int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
> +int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
> u32 *response_buf, u32 response_buf_size)
> {
> + struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
> - u32 status;
> + u32 header;
> int i;
> int ret;
>
> GEM_BUG_ON(!len);
> GEM_BUG_ON(len > guc->send_regs.count);
>
> - /* We expect only action code */
> - GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
> -
> - /* If CT is available, we expect to use MMIO only during init/fini */
> - GEM_BUG_ON(*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
> - *action != INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) != GUC_HXG_ORIGIN_HOST);
> + GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) != GUC_HXG_TYPE_REQUEST);
>
> mutex_lock(&guc->send_mutex);
> intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
>
> +retry:
> for (i = 0; i < len; i++)
> - intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
> + intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
>
> intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
>
> @@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
> */
> ret = __intel_wait_for_register_fw(uncore,
> guc_send_reg(guc, 0),
> - INTEL_GUC_MSG_TYPE_MASK,
> - INTEL_GUC_MSG_TYPE_RESPONSE <<
> - INTEL_GUC_MSG_TYPE_SHIFT,
> - 10, 10, &status);
> - /* If GuC explicitly returned an error, convert it to -EIO */
> - if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
> - ret = -EIO;
> + GUC_HXG_MSG_0_ORIGIN,
> + FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
> + GUC_HXG_ORIGIN_GUC),
> + 10, 10, &header);
> + if (unlikely(ret)) {
> +timeout:
> + drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
> + request[0], header);
> + goto out;
> + }
>
> - if (ret) {
> - DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
> - action[0], ret, status);
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
> +#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc, 0)); \
> + FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC || \
> + FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
> +
> + ret = wait_for(done, 1000);
> + if (unlikely(ret))
> + goto timeout;
> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
> + GUC_HXG_ORIGIN_GUC))
> + goto proto;
> +#undef done
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
> + u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
> +
> + drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
> + request[0], reason);
> + goto retry;
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_RESPONSE_FAILURE) {
> + u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
> + u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
> +
> + drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
> + request[0], error, hint);
> + ret = -ENXIO;
> + goto out;
> + }
> +
> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
> +proto:
> + drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
> + request[0], header);
> + ret = -EPROTO;
> goto out;
> }
>
> if (response_buf) {
> - int count = min(response_buf_size, guc->send_regs.count - 1);
> + int count = min(response_buf_size, guc->send_regs.count);
>
> - for (i = 0; i < count; i++)
> + GEM_BUG_ON(!count);
> +
> + response_buf[0] = header;
> +
> + for (i = 1; i < count; i++)
> response_buf[i] = intel_uncore_read(uncore,
> - guc_send_reg(guc, i + 1));
> - }
> + guc_send_reg(guc, i));
>
> - /* Use data from the GuC response as our return value */
> - ret = INTEL_GUC_MSG_TO_DATA(status);
> + /* Use number of copied dwords as our return value */
> + ret = count;
> + } else {
> + /* Use data from the GuC response as our return value */
> + ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
> + }
>
> out:
> intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 02/13] drm/i915/guc: Update MMIO based communication
2021-06-10 4:36 [PATCH 00/13] " Matthew Brost
@ 2021-06-10 4:36 ` Matthew Brost
2021-06-14 18:11 ` Daniele Ceraolo Spurio
0 siblings, 1 reply; 87+ messages in thread
From: Matthew Brost @ 2021-06-10 4:36 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: daniele.ceraolospurio, john.c.harrison, Michal.Wajdeczko
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
The MMIO based Host-to-GuC communication protocol has been
updated to use unified HXG messages.
Update our intel_guc_send_mmio() function by correctly handle
BUSY, RETRY and FAILURE replies. Also update our documentation.
Since some of the new MMIO actions may use DATA0 from MMIO HXG
response, we must update intel_guc_send_mmio() to copy full response,
including HXG header. There will be no impact to existing users as all
of them are only relying just on return code.
v2:
(Daniele)
- preffered -> preferred
- Max MMIO DW set to 4
- Update commit message
GuC: 55.0.0
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com> #v3
---
.../gt/uc/abi/guc_communication_mmio_abi.h | 65 +++++++------
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++++++++++++++-----
2 files changed, 98 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
index be066a62e9e0..bbf1ddb77434 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h
@@ -7,46 +7,43 @@
#define _ABI_GUC_COMMUNICATION_MMIO_ABI_H
/**
- * DOC: MMIO based communication
+ * DOC: GuC MMIO based communication
*
- * The MMIO based communication between Host and GuC uses software scratch
- * registers, where first register holds data treated as message header,
- * and other registers are used to hold message payload.
+ * The MMIO based communication between Host and GuC relies on special
+ * hardware registers which format could be defined by the software
+ * (so called scratch registers).
*
- * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8,
- * but no H2G command takes more than 8 parameters and the GuC FW
- * itself uses an 8-element array to store the H2G message.
+ * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H)
+ * messages, which maximum length depends on number of available scratch
+ * registers, is directly written into those scratch registers.
*
- * +-----------+---------+---------+---------+
- * | MMIO[0] | MMIO[1] | ... | MMIO[n] |
- * +-----------+---------+---------+---------+
- * | header | optional payload |
- * +======+====+=========+=========+=========+
- * | 31:28|type| | | |
- * +------+----+ | | |
- * | 27:16|data| | | |
- * +------+----+ | | |
- * | 15:0|code| | | |
- * +------+----+---------+---------+---------+
+ * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8,
+ * but no H2G command takes more than 4 parameters and the GuC firmware
+ * itself uses an 4-element array to store the H2G message.
*
- * The message header consists of:
+ * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which
+ * are, regardless on lower count, preferred over legacy ones.
*
- * - **type**, indicates message type
- * - **code**, indicates message code, is specific for **type**
- * - **data**, indicates message data, optional, depends on **code**
- *
- * The following message **types** are supported:
- *
- * - **REQUEST**, indicates Host-to-GuC request, requested GuC action code
- * must be priovided in **code** field. Optional action specific parameters
- * can be provided in remaining payload registers or **data** field.
- *
- * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC request,
- * action response status will be provided in **code** field. Optional
- * response data can be returned in remaining payload registers or **data**
- * field.
+ * The MMIO based communication is mainly used during driver initialization
+ * phase to setup the `CTB based communication`_ that will be used afterwards.
*/
-#define GUC_MAX_MMIO_MSG_LEN 8
+#define GUC_MAX_MMIO_MSG_LEN 4
+
+/**
+ * DOC: MMIO HXG Message
+ *
+ * Format of the MMIO messages follows definitions of `HXG Message`_.
+ *
+ * +---+-------+--------------------------------------------------------------+
+ * | | Bits | Description |
+ * +===+=======+==============================================================+
+ * | 0 | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+ | | |
+ * |...| | | Embedded `HXG Message`_ | |
+ * +---+-------+ | | |
+ * | n | 31:0 | +--------------------------------------------------------+ |
+ * +---+-------+--------------------------------------------------------------+
+ */
#endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index f147cb389a20..b773567cb080 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -376,29 +376,27 @@ void intel_guc_fini(struct intel_guc *guc)
/*
* This function implements the MMIO based host to GuC interface.
*/
-int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
+int intel_guc_send_mmio(struct intel_guc *guc, const u32 *request, u32 len,
u32 *response_buf, u32 response_buf_size)
{
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct intel_uncore *uncore = guc_to_gt(guc)->uncore;
- u32 status;
+ u32 header;
int i;
int ret;
GEM_BUG_ON(!len);
GEM_BUG_ON(len > guc->send_regs.count);
- /* We expect only action code */
- GEM_BUG_ON(*action & ~INTEL_GUC_MSG_CODE_MASK);
-
- /* If CT is available, we expect to use MMIO only during init/fini */
- GEM_BUG_ON(*action != INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER &&
- *action != INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, request[0]) != GUC_HXG_ORIGIN_HOST);
+ GEM_BUG_ON(FIELD_GET(GUC_HXG_MSG_0_TYPE, request[0]) != GUC_HXG_TYPE_REQUEST);
mutex_lock(&guc->send_mutex);
intel_uncore_forcewake_get(uncore, guc->send_regs.fw_domains);
+retry:
for (i = 0; i < len; i++)
- intel_uncore_write(uncore, guc_send_reg(guc, i), action[i]);
+ intel_uncore_write(uncore, guc_send_reg(guc, i), request[i]);
intel_uncore_posting_read(uncore, guc_send_reg(guc, i - 1));
@@ -410,30 +408,74 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 *action, u32 len,
*/
ret = __intel_wait_for_register_fw(uncore,
guc_send_reg(guc, 0),
- INTEL_GUC_MSG_TYPE_MASK,
- INTEL_GUC_MSG_TYPE_RESPONSE <<
- INTEL_GUC_MSG_TYPE_SHIFT,
- 10, 10, &status);
- /* If GuC explicitly returned an error, convert it to -EIO */
- if (!ret && !INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(status))
- ret = -EIO;
+ GUC_HXG_MSG_0_ORIGIN,
+ FIELD_PREP(GUC_HXG_MSG_0_ORIGIN,
+ GUC_HXG_ORIGIN_GUC),
+ 10, 10, &header);
+ if (unlikely(ret)) {
+timeout:
+ drm_err(&i915->drm, "mmio request %#x: no reply %x\n",
+ request[0], header);
+ goto out;
+ }
- if (ret) {
- DRM_ERROR("MMIO: GuC action %#x failed with error %d %#x\n",
- action[0], ret, status);
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_BUSY) {
+#define done ({ header = intel_uncore_read(uncore, guc_send_reg(guc, 0)); \
+ FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) != GUC_HXG_ORIGIN_GUC || \
+ FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_NO_RESPONSE_BUSY; })
+
+ ret = wait_for(done, 1000);
+ if (unlikely(ret))
+ goto timeout;
+ if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, header) !=
+ GUC_HXG_ORIGIN_GUC))
+ goto proto;
+#undef done
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
+ u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
+
+ drm_dbg(&i915->drm, "mmio request %#x: retrying, reason %u\n",
+ request[0], reason);
+ goto retry;
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) == GUC_HXG_TYPE_RESPONSE_FAILURE) {
+ u32 hint = FIELD_GET(GUC_HXG_FAILURE_MSG_0_HINT, header);
+ u32 error = FIELD_GET(GUC_HXG_FAILURE_MSG_0_ERROR, header);
+
+ drm_err(&i915->drm, "mmio request %#x: failure %x/%u\n",
+ request[0], error, hint);
+ ret = -ENXIO;
+ goto out;
+ }
+
+ if (FIELD_GET(GUC_HXG_MSG_0_TYPE, header) != GUC_HXG_TYPE_RESPONSE_SUCCESS) {
+proto:
+ drm_err(&i915->drm, "mmio request %#x: unexpected reply %#x\n",
+ request[0], header);
+ ret = -EPROTO;
goto out;
}
if (response_buf) {
- int count = min(response_buf_size, guc->send_regs.count - 1);
+ int count = min(response_buf_size, guc->send_regs.count);
- for (i = 0; i < count; i++)
+ GEM_BUG_ON(!count);
+
+ response_buf[0] = header;
+
+ for (i = 1; i < count; i++)
response_buf[i] = intel_uncore_read(uncore,
- guc_send_reg(guc, i + 1));
- }
+ guc_send_reg(guc, i));
- /* Use data from the GuC response as our return value */
- ret = INTEL_GUC_MSG_TO_DATA(status);
+ /* Use number of copied dwords as our return value */
+ ret = count;
+ } else {
+ /* Use data from the GuC response as our return value */
+ ret = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, header);
+ }
out:
intel_uncore_forcewake_put(uncore, guc->send_regs.fw_domains);
--
2.28.0
^ permalink raw reply related [flat|nested] 87+ messages in thread
end of thread, other threads:[~2021-06-14 18:11 UTC | newest]
Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-07 18:03 [PATCH 00/13] Update firmware to v62.0.0 Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 22:46 ` Daniele Ceraolo Spurio
2021-06-07 22:46 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-08 7:59 ` Michal Wajdeczko
2021-06-08 7:59 ` [Intel-gfx] " Michal Wajdeczko
2021-06-07 18:03 ` [PATCH 02/13] drm/i915/guc: Update MMIO based communication Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 23:06 ` Daniele Ceraolo Spurio
2021-06-07 23:06 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-08 8:15 ` Michal Wajdeczko
2021-06-08 8:15 ` [Intel-gfx] " Michal Wajdeczko
2021-06-09 1:03 ` Daniele Ceraolo Spurio
2021-06-09 1:03 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-07 18:03 ` [PATCH 03/13] drm/i915/guc: Update CTB response status definition Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-08 0:05 ` Daniele Ceraolo Spurio
2021-06-08 0:05 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-08 8:23 ` Michal Wajdeczko
2021-06-08 8:23 ` [Intel-gfx] " Michal Wajdeczko
2021-06-07 18:03 ` [PATCH 04/13] drm/i915/guc: Support per context scheduling policies Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 05/13] drm/i915/guc: Add flag for mark broken CTB Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 06/13] drm/i915/guc: New definition of the CTB descriptor Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-08 0:59 ` Daniele Ceraolo Spurio
2021-06-08 0:59 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-09 18:28 ` Michal Wajdeczko
2021-06-09 18:28 ` [Intel-gfx] " Michal Wajdeczko
2021-06-07 18:03 ` [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-08 1:23 ` Daniele Ceraolo Spurio
2021-06-08 1:23 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-09 17:36 ` John Harrison
2021-06-09 17:36 ` [Intel-gfx] " John Harrison
2021-06-09 20:07 ` Michal Wajdeczko
2021-06-09 20:07 ` [Intel-gfx] " Michal Wajdeczko
2021-06-10 4:38 ` Matthew Brost
2021-06-10 4:38 ` [Intel-gfx] " Matthew Brost
2021-06-10 13:19 ` Michal Wajdeczko
2021-06-10 13:19 ` [Intel-gfx] " Michal Wajdeczko
2021-06-11 18:43 ` Matthew Brost
2021-06-11 18:43 ` [Intel-gfx] " Matthew Brost
2021-06-09 19:35 ` Michal Wajdeczko
2021-06-09 19:35 ` [Intel-gfx] " Michal Wajdeczko
2021-06-07 18:03 ` [PATCH 08/13] drm/i915/guc: New CTB based communication Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-08 2:20 ` Daniele Ceraolo Spurio
2021-06-08 2:20 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-10 4:01 ` Matthew Brost
2021-06-10 4:01 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 09/13] drm/i915/doc: Include GuC ABI documentation Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 17:45 ` Matthew Brost
2021-06-07 17:45 ` Matthew Brost
2021-06-07 19:38 ` Michal Wajdeczko
2021-06-07 19:38 ` Michal Wajdeczko
2021-06-07 19:35 ` Matthew Brost
2021-06-07 19:35 ` Matthew Brost
2021-06-07 18:03 ` [PATCH 10/13] drm/i915/guc: Kill guc_clients.ct_pool Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 17:57 ` Matthew Brost
2021-06-07 17:57 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 11/13] drm/i915/guc: Kill ads.client_info Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 12/13] drm/i915/guc: Unified GuC log Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:05 ` Matthew Brost
2021-06-07 18:05 ` [Intel-gfx] " Matthew Brost
2021-06-07 18:03 ` [PATCH 13/13] drm/i915/guc: Update firmware to v62.0.0 Matthew Brost
2021-06-07 18:03 ` [Intel-gfx] " Matthew Brost
2021-06-07 19:17 ` Matthew Brost
2021-06-07 19:17 ` Matthew Brost
2021-06-07 18:05 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-06-07 18:06 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-06-07 18:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-06-07 18:34 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " Patchwork
2021-06-07 22:19 ` [PATCH 00/13] " Daniele Ceraolo Spurio
2021-06-07 22:19 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-06-11 18:44 ` Matthew Brost
2021-06-11 18:44 ` [Intel-gfx] " Matthew Brost
2021-06-08 2:17 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2021-06-10 4:36 [PATCH 00/13] " Matthew Brost
2021-06-10 4:36 ` [PATCH 02/13] drm/i915/guc: Update MMIO based communication Matthew Brost
2021-06-14 18:11 ` Daniele Ceraolo Spurio
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.