Re: [RFC PATCH 20/97] drm/i915/guc: Introduce unified HXG messages
On Wed, May 12, 2021 at 12:11:40AM +0200, Michal Wajdeczko wrote:
>
>
> On 11.05.2021 17:16, Daniel Vetter wrote:
> > On Thu, May 06, 2021 at 12:13:34PM -0700, Matthew Brost wrote:
> >> From: Michal Wajdeczko
> >>
> >> 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: Michal Wajdeczko
> >> Signed-off-by: Matthew Brost
> >> Cc: Michał Winiarski
> >> ---
> >> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 226 ++
> >> 1 file changed, 226 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..1c264819aa03 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,232 @@
> >> #ifndef _ABI_GUC_MESSAGES_ABI_H
> >> #define _ABI_GUC_MESSAGES_ABI_H
> >>
> >> +/**
> >> + * DOC: HXG Message
> >
> > These aren't useful if we don't pull them in somewhere in the
> > Documentation/gpu hierarchy. General comment, and also please check that
> > it all renders correctly still.
>
> Patch that connects all these DOC sections into i915.rst is still on
> private branch, where I'm trying to verify all html rendering, and ...
>
> >
> > btw if you respin a patch not originally by you we generally add a (v1) to
> > the original s-o-b line (or whever the version split was) and explain in
> > the usual changelog in the commit message what was changed.
> >
> > This holds for the entire series ofc.
> > -Daniel
> >
> >> + *
> >> + * All messages exchanged with GuC are defined using 32 bit dwords.
> >> + * First dword is treated as a message header. Remaining dwords are
> >> optional.
> >> + *
> >> + * .. _HXG Message:
>
> where such workarounds from early documentation are already removed,
> since they are not needed any more starting from commit ef09989594bf
> ("scripts/kernel-doc: add internal hyperlink to DOC: sections")
Oh this is nice. Fwiw the upstream commit is:
commit 06a755d6269c072ed0c9b84227eaf33113dc243f
Author: Michal Wajdeczko
Date: Mon Jan 18 12:08:13 2021 +0100
scripts/kernel-doc: add internal hyperlink to DOC: sections
I guess the sha1 you have is from your own branch?
-Daniel
>
> Michal
>
> >> + *
> >> + *
> >> +---+---+--+
> >> + * | | 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 TYPE)
> >> |
> >> + *
> >> +---+---+--+
> >> + * | 1 | 31:0 | 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
Re: [RFC PATCH 20/97] drm/i915/guc: Introduce unified HXG messages
On 11.05.2021 17:16, Daniel Vetter wrote:
> On Thu, May 06, 2021 at 12:13:34PM -0700, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> 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: Michal Wajdeczko
>> Signed-off-by: Matthew Brost
>> Cc: Michał Winiarski
>> ---
>> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 226 ++
>> 1 file changed, 226 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..1c264819aa03 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,232 @@
>> #ifndef _ABI_GUC_MESSAGES_ABI_H
>> #define _ABI_GUC_MESSAGES_ABI_H
>>
>> +/**
>> + * DOC: HXG Message
>
> These aren't useful if we don't pull them in somewhere in the
> Documentation/gpu hierarchy. General comment, and also please check that
> it all renders correctly still.
Patch that connects all these DOC sections into i915.rst is still on
private branch, where I'm trying to verify all html rendering, and ...
>
> btw if you respin a patch not originally by you we generally add a (v1) to
> the original s-o-b line (or whever the version split was) and explain in
> the usual changelog in the commit message what was changed.
>
> This holds for the entire series ofc.
> -Daniel
>
>> + *
>> + * All messages exchanged with GuC are defined using 32 bit dwords.
>> + * First dword is treated as a message header. Remaining dwords are
>> optional.
>> + *
>> + * .. _HXG Message:
where such workarounds from early documentation are already removed,
since they are not needed any more starting from commit ef09989594bf
("scripts/kernel-doc: add internal hyperlink to DOC: sections")
Michal
>> + *
>> + *
>> +---+---+--+
>> + * | | 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 TYPE)
>>|
>> + *
>> +---+---+--+
>> + * | 1 | 31:0 | 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_GUC1u
>> +#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
>> +#define GUC_HXG_TYPE_REQUEST 0u
>> +#define GUC_HXG_TYPE_EVENT1u
>> +#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u
>> +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY5u
>> +#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u
>> +#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u
>> +#define GUC_HXG_MSG_0_AUX (0xfff << 0)
>> +
>> +/**
>> + * DOC: HXG Request
>> + *
>> + * The `HXG Request`_ message should be used to initiate s
Re: [RFC PATCH 20/97] drm/i915/guc: Introduce unified HXG messages
On Tue, May 11, 2021 at 05:16:38PM +0200, Daniel Vetter wrote: > On Thu, May 06, 2021 at 12:13:34PM -0700, Matthew Brost wrote: > > From: Michal Wajdeczko > > > > 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: Michal Wajdeczko > > Signed-off-by: Matthew Brost > > Cc: Michał Winiarski > > --- > > .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 226 ++ > > 1 file changed, 226 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..1c264819aa03 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,232 @@ > > #ifndef _ABI_GUC_MESSAGES_ABI_H > > #define _ABI_GUC_MESSAGES_ABI_H > > > > +/** > > + * DOC: HXG Message > > These aren't useful if we don't pull them in somewhere in the > Documentation/gpu hierarchy. General comment, and also please check that > it all renders correctly still. > Sure. Let me figure this out before my next rev. > btw if you respin a patch not originally by you we generally add a (v1) to > the original s-o-b line (or whever the version split was) and explain in > the usual changelog in the commit message what was changed. > Still new to this process. Will do. Matt > This holds for the entire series ofc. > -Daniel > > > + * > > + * All messages exchanged with GuC are defined using 32 bit dwords. > > + * First dword is treated as a message header. Remaining dwords are > > optional. > > + * > > + * .. _HXG Message: > > + * > > + * > > +---+---+--+ > > + * | | 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 TYPE) > > | > > + * > > +---+---+--+ > > + * | 1 | 31:0 | optional payload (depends on TYPE) > > | > > + * +---+---+ > > | > > + * |...| | > > | > > + * +---+---+ > > | > > + * | n | 31:0 | > > | > > + * > > +---+---+--+ > > + */ > > + > > +#define GUC_HXG_MSG_MIN_LEN1u > > +#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_BUSY3u > > +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u > > +#define GUC_HXG_TYPE_RESPONSE_FAILURE6u > > +#define GUC_HXG_TYPE_RESPONSE_SUCCESS7u > > +#define GUC_HXG_MSG_0_AUX (0xfff << 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 `H
Re: [RFC PATCH 20/97] drm/i915/guc: Introduce unified HXG messages
On Thu, May 06, 2021 at 12:13:34PM -0700, Matthew Brost wrote: > From: Michal Wajdeczko > > 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: Michal Wajdeczko > Signed-off-by: Matthew Brost > Cc: Michał Winiarski > --- > .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 226 ++ > 1 file changed, 226 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..1c264819aa03 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,232 @@ > #ifndef _ABI_GUC_MESSAGES_ABI_H > #define _ABI_GUC_MESSAGES_ABI_H > > +/** > + * DOC: HXG Message These aren't useful if we don't pull them in somewhere in the Documentation/gpu hierarchy. General comment, and also please check that it all renders correctly still. btw if you respin a patch not originally by you we generally add a (v1) to the original s-o-b line (or whever the version split was) and explain in the usual changelog in the commit message what was changed. This holds for the entire series ofc. -Daniel > + * > + * All messages exchanged with GuC are defined using 32 bit dwords. > + * First dword is treated as a message header. Remaining dwords are optional. > + * > + * .. _HXG Message: > + * > + * > +---+---+--+ > + * | | 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 TYPE) > | > + * > +---+---+--+ > + * | 1 | 31:0 | 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_HOST0u > +#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(0xfff << 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. > + * > + * _HXG Request: > + * > + * > +---+---+--+ > + * | | Bits | Description
[RFC PATCH 20/97] drm/i915/guc: Introduce unified HXG messages
From: Michal Wajdeczko 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: Michal Wajdeczko Signed-off-by: Matthew Brost Cc: Michał Winiarski --- .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 226 ++ 1 file changed, 226 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..1c264819aa03 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,232 @@ #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. + * + * .. _HXG Message: + * + * +---+---+--+ + * | | 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 TYPE) | + * +---+---+--+ + * | 1 | 31:0 | optional payload (depends on TYPE) | + * +---+---+ | + * |...| | | + * +---+---+ | + * | n | 31:0 | | + * +---+---+--+ + */ + +#define GUC_HXG_MSG_MIN_LEN1u +#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_BUSY3u +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u +#define GUC_HXG_TYPE_RESPONSE_FAILURE6u +#define GUC_HXG_TYPE_RESPONSE_SUCCESS7u +#define GUC_HXG_MSG_0_AUX (0xfff << 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. + * + * _HXG Request: + * + * +---+---+--+ + * | | 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 | + * +---+---
