[Intel-gfx] [PATCH v3] drm/i915: Fix VGA handling using stop_machine() or mmio

Chris Wilson chris at chris-wilson.co.uk
Mon Oct 7 11:15:16 CEST 2013

On Wed, Oct 02, 2013 at 04:42:55PM +0300, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> We have several problems with out VGA handling:
> - We try to use the GMCH control VGA disable bit even though it may
>   be locked
> - If we manage to disable VGA throuh GMCH control, we're no longer
>   able to correctly disable the VGA plane
> - Taking part in the VGA arbitration is too expensive for X [1]
> So let's treat the GMCH control VGA disable bit as read-only and leave
> it for the BIOS to set, as it was intended. To disable VGA we will use
> the VGA misc register, and to disable VGA IO we will disable IO space
> completely via the PCI command register.
> But we still need VGA register access during resume (and possibly during
> lid event on insane BIOSen) to disable the VGA plane. Also we need to
> re-disable VGA memory decode via the VGA misc register on resume.
> Luckily up to gen4, VGA registers can be accessed through MMIO.
> Unfortunately from gen5 onwards only the legacy VGA IO port range
> works. So on gen5+ we still need IO space to be enabled during those
> few special moments when we need to access VGA registers.
> We still want to opt out of VGA arbitration on gen5+, so we have keep
> IO space disabled most of the time. And when we do need to poke at VGA
> registers, we enable IO space briefly while no one is looking. To
> guarantee that no one is looking we will use stop_machine().
> [1] http://lists.x.org/archives/xorg-devel/2013-September/037763.html
> v2: Use SNB_GMCH_TRL on SNB+
>     Use port IO instead of MMIO on CTG/ELK
>     Add WaEnableVGAAccessThroughIOPort comment
>     Fix the max number of devices on the bus limit
> v3: Allocate the temp space dynamically
>     Print some errors if we fail to execute the vga "op" due to alloc failure

Passes the dGPU test, the SNB laptop, but is doa for CTG.

Chris Wilson, Intel Open Source Technology Centre

More information about the Intel-gfx mailing list