[Intel-xe] [PATCH 00/21] xe & i915 display integration ifdef cleanups

[Daniel Vetter]

On Thu, 13 Apr 2023 at 14:20, Tvrtko Ursulin
<tvrtko.ursulin at linux.intel.com> wrote:
>
>
> On 05/04/2023 16:38, Jani Nikula wrote:
> > Hey all, here's my first batch of #ifdef cleanups for xe and i915
> > display integration.
> >
> > Many of the patches in this series break the build, and will get fixed
> > by subsequent changes. It's pretty much unavoidable as many of the
> > changes are standalone to i915, and others are fixups.
> >
> > This is pretty straightforward stuff for starters, really. The idea is
> > that in the next rebase, the drm/i915 changes here go *before* any of
> > the current i915 changes.
> >
> > Adding the static inline stubs for xe build in i915 (the !I915 parts) is
> > very helpful in not sprinkling #ifdefs all over the place. A lot of the
> > time, the compiler is able to just compile out lots and lots of
> > unreachable static functions and data without explicitly conditionally
> > building them out. We can leave a lot of it out from "drm/i915/display:
> > Remaining changes to make xe compile". This is crucial especially while
> > upstreaming by keeping the changes to i915 minimal.
> >
> > Also, I think the conditional build and stubs in headers is the least
> > intrusive way of going about this before xe is actually upstream, and it
> > also follows the usual patterns for CONFIG_FOO=n code paths, albeit I915
> > is defined in the Makefile, not in kconfig.
>
> I think the sheer amount of static inline dummies is not nice at all and
> I certainly wouldn't support it for the long term, or proper solution.
> Not to mention it is catering for out of tree code which is quite an
> atypical accommodation.
>
> So sadly no ack from me but given DRM maintainers approve this approach
> I don't intend to attempt to block it either. FWIW and for the record only.

The big difference we tend to make (inconsistently at that) is whether
it's prep work for code that everyone expects to land, or is there
just no way it'll ever land.

So like prep work for all the compute/hpc stuff for i915-gem is
no-way, because there's no path to upstream for that.

But prep work for display to reuse i915-display in xe is fine, because
the expectation is that xe (at least for client, I'm not very
optimistic about hpc tbf) will land in upstream. Even if it's a year
or something like that, we've done that before for various reasons.
Even if it's more than a year (I'm still trying to get at least one
vendor to upstream their pre-si infra, no one's biting thus far for
the kernel, mesa otoh has quite a few sim layers already), when it's
really something that makes sense long-term for the overall
community/ecosystem.

Hence my question: Do you think this is also no-go once xe is merged,
and what should it look like instead to make it not no-go?

Cheers, Daniel

> Regards,
>
> Tvrtko
>
> >
> > BR,
> > Jani.
> >
> >
> >
> > Jani Nikula (21):
> >    fixup! drm/i915/display: Set DISPLAY_MMIO_BASE to 0 for xe
> >    drm/i915: define I915 during i915 driver build
> >    drm/i915/display: add I915 conditional build to intel_lvds.h
> >    fixup! drm/xe/display: Implement display support
> >    drm/i915/display: add I915 conditional build to hsw_ips.h
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    fixup! drm/xe/display: Implement display support
> >    drm/i915/display: add I915 conditional build to i9xx_plane.h
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    drm/i915/display: add I915 conditional build to intel_lpe_audio.h
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    drm/i915/display: add I915 conditional build to intel_pch_refclk.h
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    drm/i915/display: add I915 conditional build to intel_pch_display.h
> >    drm/i915/display: add I915 conditional build to intel_sprite.h
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    fixup! drm/xe/display: Implement display support
> >    drm/i915/display: add I915 conditional build to intel_overlay.h
> >    fixup! drm/i915/display: Remaining changes to make xe compile
> >    fixup! drm/xe/display: Implement display support
> >
> >   drivers/gpu/drm/i915/display/hsw_ips.h        | 35 +++++++++++
> >   drivers/gpu/drm/i915/display/i9xx_plane.h     | 23 +++++++
> >   drivers/gpu/drm/i915/display/intel_cdclk.c    |  4 +-
> >   drivers/gpu/drm/i915/display/intel_crtc.c     |  6 +-
> >   drivers/gpu/drm/i915/display/intel_display.c  | 15 +----
> >   .../gpu/drm/i915/display/intel_lpe_audio.h    | 20 ++++--
> >   drivers/gpu/drm/i915/display/intel_lvds.h     | 19 ++++++
> >   drivers/gpu/drm/i915/display/intel_overlay.h  | 35 +++++++++++
> >   .../gpu/drm/i915/display/intel_pch_display.h  | 63 +++++++++++++++----
> >   .../gpu/drm/i915/display/intel_pch_refclk.h   | 25 ++++++--
> >   drivers/gpu/drm/i915/display/intel_sprite.c   | 20 +-----
> >   drivers/gpu/drm/i915/display/intel_sprite.h   |  8 +++
> >   drivers/gpu/drm/xe/Makefile                   |  2 -
> >   .../gpu/drm/xe/compat-i915-headers/i915_drv.h |  7 +--
> >   14 files changed, 211 insertions(+), 71 deletions(-)
> >



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch