[igt-dev] [PATCH i-g-t v3 1/8] drm-uapi/xe_drm: Add Xe uAPI

[Mauro Carvalho Chehab]

On Tue, 28 Feb 2023 07:08:52 -0800
Lucas De Marchi <lucas.demarchi at intel.com> wrote:

> On Tue, Feb 28, 2023 at 09:25:43AM +0100, Zbigniew Kempczyński wrote:
> >On Fri, Feb 24, 2023 at 06:57:52PM +0100, Michal Wajdeczko wrote:  
> >>
> >>
> >> On 24.02.2023 11:44, Zbigniew Kempczyński wrote:  
> >> > Introduce uAPI contract for Xe IGT.
> >> >
> >> > Signed-off-by: Jason Ekstrand <jason at jlekstrand.net>
> >> > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> >> > Signed-off-by: Matthew Brost <matthew.brost at intel.com>
> >> > Signed-off-by: Philippe Lecluse <philippe.lecluse at intel.com>
> >> > Signed-off-by: Zbigniew Kempczyński <zbigniew.kempczynski at intel.com>
> >> > ---
> >> >  include/drm-uapi/xe_drm.h | 807 ++++++++++++++++++++++++++++++++++++++
> >> >  1 file changed, 807 insertions(+)
> >> >  create mode 100644 include/drm-uapi/xe_drm.h  
> >>
> >> is it really necessary to copy this buggy header to IGT right now?
> >>
> >> maybe we can wait until this header will be properly reviewed and
> >> cleaned up in the kernel repo first ?  
> >
> >+Lucas
> >
> >We discussed yesterday about this header - from IGT perspective it
> >is not a blocker, after fixing in xe kernel we'll copy it here.
> >Xe-igt repository had sense during early development stage, but now
> >we want to migrate it here. Code still requires fixups and cleanup
> >but we may do it here. Otherwise workflow would require sending to
> >igt ml (squashed patches with some of them removed [kunit]), then
> >fixup to xe-igt and repeat squash/send. Very time consuming we want
> >to avoid. Fixing that later in igt is acceptable for us as xe driver
> >is not production ready.  
> 
> yep, any fix to this file should be done in the kernel side. igt only
> copies this file so it doesn't depend on any kernel-headers package.

Agreed.

Acked-by: Mauro Carvalho Chehab <mchehab at kernel.org>

> 
> The obvious issues I see are in the comments/docs where we have
> leftovers from i915. Michal, is this what you are referring to or there
> is something else?  If you can send a patch cleaning that up or creating
> an issue in gitlab it would be appreciated
> 
> 
> Acked-by: Lucas De Marchi <lucas.demarchi at intel.com>
> 
> Lucas De Marchi