Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	Matt Roper <matthew.d.roper@intel.com>
Subject: [Intel-gfx] [PATCH 0/2] drm/i915/lnl: Assign correct phys
Date: Wed, 18 Oct 2023 15:24:39 -0700	[thread overview]
Message-ID: <20231018222441.4131237-1-lucas.demarchi@intel.com> (raw)

For this series to work, we still need a separate patch on the xe side
so it defines the LNL platform macro to be used by display.

One thing missing for LNL during the previous patches was the
port <-> phy assignment. With the bspec now clarified, this is the
minimum changes needed for LNL.  As the commit messages say and after
looking at the history of the code, it seems we were thinking to go one
direction abstraction-wise with DG2, but reverted course with MTL. The
end result right now is a very confusing mix of port/phy/tc_port.
I was hoping to do a cleanup now, but we probably need some consensus on
the approach as it'd be an intrusive change.

Here are some thoughts after looking again at the current state of the
code:

1) What is the port -> phy conversion for? AFAIR this was because from
the display engine side we want, some registers have bit offsets based
on the port and others are based on the PHY. I think now we can

	a) Remove enum tc_port and have only `enum port` and `enum phy`.
	   Those should be sufficient for all platform needs afaics

	b) Add phy to intel_encoder (or intel_digital_port). It's
	   appalling number of places we convert from port to phy. That
	   would just be initialized during init.

2) It looks we need to better abstract the phy handling. Right now it's
very confusing with dkl, c10/c20 (that leak the abstraction from
intel_cx0_phy.c to everywhere in the driver), snps and the older
combo/tc being a superset of them.  I'm still not sure what to do here.
One thing that we can probably do is to remove the dg2-special case and
let the "is tc" be about the **port being connected to a TC-capable phy**.
Bspec always refer to those as TC<N> / USBC<N>. Then dkl, c10, c20, snps
would all be in the same abstraction layer. Any thoughts?

Lucas De Marchi (2):
  drm/i915/lnl: Extend C10/C20 phy
  drm/i915/lnl: Fix check for TC phy

 drivers/gpu/drm/i915/display/intel_cx0_phy.c |  2 +-
 drivers/gpu/drm/i915/display/intel_display.c | 29 ++++++++++----------
 drivers/gpu/drm/i915/i915_drv.h              |  1 +
 3 files changed, 17 insertions(+), 15 deletions(-)

-- 
2.40.1


             reply	other threads:[~2023-10-18 22:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 22:24 Lucas De Marchi [this message]
2023-10-18 22:24 ` [Intel-gfx] [PATCH 1/2] drm/i915/lnl: Extend C10/C20 phy Lucas De Marchi
2023-10-19 15:58   ` Gustavo Sousa
2023-10-18 22:24 ` [Intel-gfx] [PATCH 2/2] drm/i915/lnl: Fix check for TC phy Lucas De Marchi
2023-10-19 16:04   ` Gustavo Sousa
2023-10-20 16:04     ` Lucas De Marchi
2023-10-23 15:28       ` Gustavo Sousa
2023-10-25 15:44         ` Lucas De Marchi
2023-10-26 15:47           ` Gustavo Sousa
2023-10-19  1:36 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/lnl: Assign correct phys Patchwork
2023-10-19  1:45 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-10-24 16:21 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/lnl: Assign correct phys (rev2) 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=20231018222441.4131237-1-lucas.demarchi@intel.com \
    --to=lucas.demarchi@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox