Re: [PATCH] drm/i915/display: Stop touching vga on post enable

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Nov 19, 2025 at 10:28:20PM -0600, Lucas De Marchi wrote:
> On Thu, Nov 20, 2025 at 02:41:22AM +0200, Ville Syrjälä wrote:
> >On Wed, Nov 19, 2025 at 12:04:38PM -0800, Lucas De Marchi wrote:
> >> Touching VGA_MIS_W goes back to commit f9dcb0dfee98 ("drm/i915: touch
> >> VGA MSR after we enable the power well"). That case doesn't seem to be
> >> reproduced anymore, even considering that the unclaimed accesses are now
> >> printed with debug log level. Also note that the original issue was
> >> reproduced with vgacon, but that is not used anymore on x86 when booted
> >> with EFI.
> >>
> >> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> >> ---
> >> WIP to drop the VGA accesses and allow xe driver to be used with
> >> non-x86 platforms. There are multiple patches floating around, some
> >> disabling code for non-x86, some disabling for !CONFIG_VGA_CONSOLE.
> >>
> >> For this v1, I think the entire workaround can be removed. Sending it
> >> for CI while I look into the other cases.
> >
> >I think this would need to be tested on a machine that has a
> >second VGA card in it to make the the iGPU doesn't end up eating
> >the VGA memory accesses when they should be going to the other
> >card.
> >
> >I was perusing the CPU/chipset docs for this a bit, in the hopes
> >of finding some sane way to turn off VGA decoding for the iGPU.
> >Alas no such luck. According to the docs the iGPU always has the
> >highest decode priority, and the accesses won't get forwarded
> >to PCIe/DMI/PCI if the iGPU grabs them.
> >
> >IIRC the docs say that the reset state for the VGA memory decode
> >should be "off". But I don't think that's quite true given that
> >we had to add this workaround.
> 
> confused... What are you are saying seems to be something about
> the vga accesses in intel_vga_disable(). 
> 
> commit f9dcb0dfee98 ("drm/i915: touch VGA MSR after we enable the power well")
> describes it as: 
> 
> 	- 1 igpu with eDP + HDMI
> 	- after power well is enabled/disabled, drop the drm, and unbind
> 	  vtcon (note it's not unbinding the module). Note that it's not
> 	  about unbinding the module.
> 
> And that was caused by our printk from inside the irq handler causing
> things to be printed via vgacon and that generating an interrupt that
> print something again, creating a loop. I'm not sure what platform that
> was about back in 2013, but looking around at the code I suppose it was
> Ironlake and in the irq handler calling intel_uncore_check_errors().

It was hsw or bdw. Earlier platforms don't have power wells.

> 
> 12 years later we have a few different things:
> 
> 	- I don't see us handling intel_uncore_check_errors() the way we
> 	  were before, inside the irq handler. It seems commit
> 	  7571494004d8 ("drm/i915: Do one shot unclaimed mmio detection
> 	  less frequently") moved it out from the irq path (it makes
> 	  sense not printing to the console from inside the irq handler)

On some platforms there is an actual error interrupt that
gets triggered by unclaimed mmio acceses.

> 	- vgacon is not really used anymore. If it was only this, we
> 	  could add a check and do it conditionally, but to me it seems
> 	  we can completely drop this

It's not really only about vgacon. If anyone actually wants VGA
memory accesses to go to some external GPU then the iGPU has to
be told to not claim them. And that can only be done by poking
that particular VGA register.

And the power well reset state is apparently somehow screwed up
to cause the iGPU to enable VGA memory decode even though it
should be off by default. Or at least that's how it looks to me.

I supose I might have to stick an extra graphics card to my
hsw and see what's really going on. Hmm, except I'm not sure
the BIOS on that machine lets me have two GPUs...

-- 
Ville Syrjälä
Intel