All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: jani.nikula@intel.com, lucas.demarchi@intel.com,
	rodrigo.vivi@intel.com, matthew.d.roper@intel.com
Subject: [Intel-gfx] [RFC 0/3] drm/i915: split display from drm_i915_private and i915_drv.h
Date: Tue, 26 Sep 2023 20:15:40 +0300	[thread overview]
Message-ID: <cover.1695747484.git.jani.nikula@intel.com> (raw)

We've been gradually separating display code from the rest of the i915
driver code over the past few years. We can't get much further than this
without some more drastic changes.

One of them is separating struct drm_i915_private and struct
intel_display almost completely. The former would remain for core driver
code and gem, while the latter would be for display. Long term, i915
display code would not include i915_drv.h, and would not have access to
struct drm_i915_private definion.

For display code, struct drm_i915_private would be opaque, and for the
rest of the driver, struct intel_display would be opaque.

Naturally, such separation helps the upcoming xe driver integration with
i915 display code. It's basically a requirement if (and that's still an
if) we decide to use aux-bus to have a i915.ko/xe.ko <->
intel-display.ko split. Regardless of that, I think this is a big
maintainability plus on its own too. The everything-includes-everything
model is really a nightmare.

Here are some draft ideas how this could be started. It will be a lot of
churn especially in the display code, but I believe the end result will
be cleaner.

BR,
Jani.


Jani Nikula (3):
  drm/i915: rough ideas for further separating display code from the
    rest
  drm/i915/hdmi: drafting what struct intel_display usage would look
    like
  drm/i915: draft what feature test macros would look like

 .../gpu/drm/i915/display/intel_display_core.h    | 16 ++++++++++++++++
 .../gpu/drm/i915/display/intel_display_device.c  | 13 +++++++++++++
 .../gpu/drm/i915/display/intel_display_device.h  |  4 ++++
 drivers/gpu/drm/i915/display/intel_hdmi.c        | 15 ++++++++++-----
 drivers/gpu/drm/i915/i915_drv.h                  | 11 ++++++++++-
 5 files changed, 53 insertions(+), 6 deletions(-)

-- 
2.39.2


             reply	other threads:[~2023-09-26 17:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 17:15 Jani Nikula [this message]
2023-09-26 17:15 ` [Intel-gfx] [RFC 1/3] drm/i915: rough ideas for further separating display code from the rest Jani Nikula
2023-09-26 17:15 ` [Intel-gfx] [RFC 2/3] drm/i915/hdmi: drafting what struct intel_display usage would look like Jani Nikula
2023-09-26 17:15 ` [Intel-gfx] [RFC 3/3] drm/i915: draft what feature test macros " Jani Nikula
2023-09-27  0:13 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: split display from drm_i915_private and i915_drv.h Patchwork
2023-09-27  0:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-09-27  0:32 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-10-20 23:04 ` [Intel-gfx] [RFC 0/3] " Matt Roper
2023-10-24 11:51   ` Jani Nikula

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.1695747484.git.jani.nikula@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@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.