[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
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list