Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>
Subject: Re: [PATCH 1/2] drm/{i915,xe}: Move intel_pch under display
Date: Tue, 18 Feb 2025 17:57:00 +0200	[thread overview]
Message-ID: <Z7StzI4OHWACh32c@intel.com> (raw)
In-Reply-To: <f37c9a532c6dd18ffae8264305d6b1e3b63f2155.camel@intel.com>

On Tue, Feb 18, 2025 at 03:34:14PM +0000, Vivi, Rodrigo wrote:
> On Tue, 2025-02-18 at 17:27 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 18, 2025 at 09:45:46AM -0500, Rodrigo Vivi wrote:
> > > On Tue, Feb 18, 2025 at 02:19:38PM +0200, Jani Nikula wrote:
> > > > On Mon, 17 Feb 2025, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > > > > The only usage of the "PCH" infra is to detect which South
> > > > > Display
> > > > > Engine we should be using. Move it under display so we can
> > > > > convert
> > > > > all its callers towards intel_display struct later.
> > > > 
> > > > Yeah, PCH is becoming a blocker to finishing the conversions of
> > > > many
> > > > files from drm_i915_private to intel_display. We'll need to do
> > > > something
> > > > like this.
> > > 
> > > First of all, I'm sorry for not sending a cover letter explaining
> > > more about
> > > my thoughts here and also for not tagging this as an RFC. And thank
> > > you very
> > > much for jumping in the discussion.
> > > 
> > > I started this, exactly because my consolidation of display pm now
> > > is
> > > blocked in some HPD calls. Then I checked the IRQ code and I have
> > > some
> > > ideas do organize that, but that got blocked on the PCH, then I
> > > moved
> > > towards seeing what could and should be done to PCH and these 2
> > > patches
> > > is the initial of my conclusion.
> > > 
> > > > 
> > > > I was eyeing the PCH checks outside of display, and frankly many
> > > > of them
> > > > are plain wrong (done to check stuff that's unrelated to PCH, but
> > > > happens to match desired platforms), or should be in display
> > > > (e.g. gt_record_display_regs()). But there are also legitimate
> > > > checks, I
> > > > think in clock gating.
> > > 
> > > Yes, this one in GPU hang was one of the most strange ones, but
> > > then
> > > I noticed it is inside this function that should be moved to the
> > > display
> > > side anyway.
> > > 
> > > Other cases are:
> > > drivers/gpu/drm/i915/intel_clock_gating.c:
> > > 
> > > This entire file should be in the display side.
> > 
> > Mostly, but it still has bunch of gt workarounds in it.
> > Those all should be moved into the gt w/a framework.
> 
> hmm... indeed. But anyway, all that I saw using PCH is related
> to display.
> 
> > 
> > > But I got super
> > > scared now because it looks like it is not getting called from
> > > nowhere.
> > > So we might be missing many display workarounds. I will investigate
> > > this more later.
> > 
> > It's hidden behind some confusing macro stuff.
> 
> oh no! someone is reading too much i915-guc related code :(
> 
> > 
> > > 
> > > drivers/gpu/drm/i915/i915_irq.c:
> > > This is exactly where I got blocked. All the PCH calls inside it
> > > are display related that I need to move to the display side in
> > > order to have a proper split and make the display to stop using
> > > the irq spin locks directly.
> > > 
> > > drivers/gpu/drm/i915/i915_gpu_error.c:
> > > good idea on moving that entire function to display anyway.
> > 
> > That seems like a random set of stuff no one actually cares about.
> > Should just nuke the whole thing, apart from DERRMR because that
> > one is actually relevant for GPU hangs. Though that one doesn't
> > exist on VLV/CHV so currently some random garbage is being read
> > into it on those platforms.
> 
> Indeed. Let's see what we can kill without breaking decode tools.
> But moving the function entirely to display is the easiest for now.
> 
> So, about the PCH stuff itself moving to inside display, no objection
> from your side, right Ville?

Seems mostly doable.

The one thing I'm not quite sure how to deal with is the
SDEIER hack in ilk_irq_handler(). Maybe we can move it into
{ilk,ivb}_display_irq_handler(), just need to think about
the ordering a bit.

Hmm, the whole ilk+ irq handling still looks fairly dodgy.
I should probably resurrect my old irq ack+handle split
series and finally get that code into proper form...

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-02-18 15:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18  1:02 [PATCH 1/2] drm/{i915,xe}: Move intel_pch under display Rodrigo Vivi
2025-02-18  1:02 ` [PATCH 2/2] drm/i915/display: Convert intel_pch towards intel_display Rodrigo Vivi
2025-02-18  1:12 ` ✓ CI.Patch_applied: success for series starting with [1/2] drm/{i915,xe}: Move intel_pch under display Patchwork
2025-02-18  1:12 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-18  1:13 ` ✓ CI.KUnit: success " Patchwork
2025-02-18  1:30 ` ✓ CI.Build: " Patchwork
2025-02-18  1:32 ` ✓ CI.Hooks: " Patchwork
2025-02-18  1:34 ` ✓ CI.checksparse: " Patchwork
2025-02-18  1:53 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-18 12:19 ` [PATCH 1/2] " Jani Nikula
2025-02-18 14:45   ` Rodrigo Vivi
2025-02-18 15:27     ` Ville Syrjälä
2025-02-18 15:34       ` Vivi, Rodrigo
2025-02-18 15:57         ` Ville Syrjälä [this message]
2025-02-18 15:51       ` Lucas De Marchi
2025-02-18 19:05 ` ✗ Xe.CI.Full: failure for series starting with [1/2] " 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=Z7StzI4OHWACh32c@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox