[RFC 0/7] Promote GuC ABI headers to shared location

[Lucas De Marchi]

On Tue, Jun 11, 2024 at 06:12:20PM GMT, Rodrigo Vivi wrote:
>On Tue, Jun 11, 2024 at 11:45:17PM +0200, Michal Wajdeczko wrote:
>>
>>
>> On 11.06.2024 22:32, John Harrison wrote:
>> > On 6/11/2024 07:30, Michal Wajdeczko wrote:
>> >> There are many GuC ABI definitions named in the same way by the i915
>> >> and Xe drivers, preventing proper generation of the documentation.
>> >>
>> >> Promote GuC ABI definitions to shared location that can be used by
>> >> both drivers and can be included in documentation.
>> > I still very strongly feel that this is the wrong place for such
>> > documentation. We do not document any of the hardware registers in the
>> > driver, nor the MI_ instructions, etc. Why is this any different? The
>> > GuC ABI is not under the control of the Linux kernel driver, either i915
>> > or Xe. It is effectively a hardware interface no different to any other
>> > hardware interface. It is already fully documented by the owners of that
>> > interface. Rather than just copying random chunks of that documentation
>> > into the kernel driver, we should just be publishing the official
>> > document itself. Same as we do for the rest of the hardware.
>>
>> so go publish this official document
>>
>> in the meantime IMO it is useful to show, with really little effort, on
>> what grounds the communication between i915/Xe and GuC works, so
>> everyone, not just selected engineers, can understand and review our
>> implementation and check its correctness
>>
>> furthermore, if you don't like any hw documentation then we should
>> revisit what is already in gpu/i915 section and also reconsider all our
>> efforts to document all non-static driver functions, as those functions
>> are still internal to the driver, not to be used outside
>
>I second that. This is useful documentation internal to our driver.
>Specially with a fw which has an ABI that demands version compatibility
>with the driver like this.

I too think it's very much appreciated to document the interface we
are using between kernel and firmware.

Lucas De Marchi