All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Cc: rodrigo.vivi@intel.com, lucas.demarchi@intel.com,
	ville.syrjala@linux.intel.com, jani.nikula@intel.com
Subject: [RFC v2 0/4] drm/i915: better high level abstraction for display
Date: Wed,  6 Mar 2024 14:24:34 +0200	[thread overview]
Message-ID: <cover.1709727127.git.jani.nikula@intel.com> (raw)

This is v2 of [1]. Improve the abstractions for display code.

The main goals are:

1) The display code does not access struct drm_i915_private or struct
   xe_device. It only uses its own struct intel_display instead.

2) The i915 and xe driver cores do not access struct intel_display
   directly. It becomes an opaque pointer to them, stored in struct
   drm_i915_private and struct xe_device, and passed to display code.

This will mean a lot of churn, unfortunately. But it will better
separate the display code from the xe and i915 driver cores, and pave
the way for a) removing -Ddrm_i915_private=xe_device from xe Makefile,
and b) stop building the display code twice.

What's presented here goes a long way, and could get us started. But
there are still opens, such as:

1) How to handle platform checks such as IS_TIGERLAKE().

2) How to handle access to non-display members of i915/xe, such as
   i915->uncore.

There are other similar things, but I believe those are the most
prevalent, and are the biggest blockers for converting a lot of
functions over from i915 -> intel_display.


BR,
Jani.

[1] https://lore.kernel.org/r/cover.1695747484.git.jani.nikula@intel.com


Jani Nikula (4):
  drm/i915/display: ideas for further separating display code from the
    rest
  drm/i915/display: add generic to_intel_display() macro
  drm/i915/display: accept either i915 or display for feature tests
  drm/i915/display: test various to_intel_display() scenarios

 .../gpu/drm/i915/display/intel_display_core.h |  3 ++
 .../drm/i915/display/intel_display_device.c   | 13 ++++++
 .../drm/i915/display/intel_display_device.h   | 10 +++-
 .../drm/i915/display/intel_display_types.h    | 46 +++++++++++++++++++
 drivers/gpu/drm/i915/display/intel_dp.c       |  6 +--
 drivers/gpu/drm/i915/display/intel_hdmi.c     | 13 +++---
 drivers/gpu/drm/i915/i915_drv.h               | 11 ++++-
 drivers/gpu/drm/xe/xe_device_types.h          | 15 +++++-
 8 files changed, 103 insertions(+), 14 deletions(-)

-- 
2.39.2


             reply	other threads:[~2024-03-06 12:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 12:24 Jani Nikula [this message]
2024-03-06 12:24 ` [RFC v2 1/4] drm/i915/display: ideas for further separating display code from the rest Jani Nikula
2024-03-06 12:42   ` Jani Nikula
2024-03-06 12:24 ` [RFC v2 2/4] drm/i915/display: add generic to_intel_display() macro Jani Nikula
2024-03-06 18:16   ` Rodrigo Vivi
2024-03-07 11:28     ` Jani Nikula
2024-03-07 13:43       ` Rodrigo Vivi
2024-03-06 12:24 ` [RFC v2 3/4] drm/i915/display: accept either i915 or display for feature tests Jani Nikula
2024-03-06 12:24 ` [RFC v2 4/4] drm/i915/display: test various to_intel_display() scenarios Jani Nikula
2024-03-06 12:29 ` ✓ CI.Patch_applied: success for drm/i915: better high level abstraction for display Patchwork
2024-03-06 12:29 ` ✗ CI.checkpatch: warning " Patchwork
2024-03-06 12:30 ` ✓ CI.KUnit: success " Patchwork
2024-03-06 12:41 ` ✓ CI.Build: " Patchwork
2024-03-06 12:41 ` ✗ CI.Hooks: failure " Patchwork
2024-03-06 12:43 ` ✗ CI.checksparse: warning " Patchwork
2024-03-06 13:11 ` ✓ CI.BAT: success " Patchwork
2024-03-06 18:23 ` [RFC v2 0/4] " Rodrigo Vivi
2024-03-06 21:13 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2024-03-06 21:14 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-03-06 21:27 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-07 15:25 ` ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1709727127.git.jani.nikula@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.