[PATCH 0/7] Update GuC ABI definitions

John Harrison john.c.harrison at intel.com
Thu Apr 4 01:10:33 UTC 2024


On 4/1/2024 05:54, Lucas De Marchi wrote:
> On Fri, Mar 29, 2024 at 05:50:32PM +0100, Michal Wajdeczko wrote:
>> On 29.03.2024 17:14, Lucas De Marchi wrote:
>>> On Thu, Mar 28, 2024 at 07:31:40PM +0100, Michal Wajdeczko wrote:
>>>> In upcoming patches we will use additional messages in communication
>>>> with the GuC firmware. Add necessary definitions to our ABI header.
>>>
>>> but it would be better if these additions were done when they are
>>> needed. We don't want to keep updating this with things that may not be
>>> needed at all (plans always change, ABI may change to fix bugs, etc)
>>
>> fully understand that, but...
>>
>> this ABI definitions reflects what current firmware already supports
>> and it is just complementary to what was already pushed in initial
>> driver drop without supporting code:
>> - [1] GuC VGT Policy KLVs
>> - [2] GuC VF Configuration KLVs
>>
>> [1]
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/xe/abi/guc_klvs_abi.h#L114 
>>
>>
>> [2]
>> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/xe/abi/guc_klvs_abi.h#L154 
>>
>>
>> it will also help me lower my pile of pending patches, so maybe there is
>> a chance for a small exception ?
>
> I don't see how it really helps with reviewing your pending changes.
> IMO it will make it harder. When you need these defines, just squash
> them in the commit you are making use of them.
>
> I'm looking at this the same way we handle new registers... we don't
> just dump all the registers the hw knows about into regs/*.h
>
> Lucas De Marchi
We also don't copy the entire bspec definition of a register or MI_ 
instruction into the header file.

John.



More information about the Intel-xe mailing list