All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@gmail.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	Dave Airlie <airlied@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i915: Update VGA arbiter support for newer devices
Date: Fri, 16 Aug 2013 13:20:17 +0300	[thread overview]
Message-ID: <20130816102017.GK7159@intel.com> (raw)
In-Reply-To: <1376607255.13642.155.camel@ul30vt.home>

On Thu, Aug 15, 2013 at 04:54:15PM -0600, Alex Williamson wrote:
> On Fri, 2013-08-16 at 08:49 +1000, Dave Airlie wrote:
> > On Fri, Aug 16, 2013 at 8:43 AM, Alex Williamson
> > <alex.williamson@redhat.com> wrote:
> > > This is intended to add VGA arbiter support for Intel HD graphics on
> > > Core processors.  The old GMCH registers no longer exist, so even
> > > though it appears that i915 participates in VGA arbitration, it doesn't
> > > work.  On Intel HD graphics we already attempt to disable VGA regions
> > > of the device.  This makes registering as a VGA client unnecessary since
> > > we don't intend to operate differently depending on how many VGA devices
> > > are present.  We can disable VGA memory regions by clearing a memory
> > > enable bit in the VGA MSR.  That only leaves VGA IO, which we update
> > > the VGA arbiter to know that we don't participate in VGA memory
> > > arbitration.  We also add a hook on unload to re-enable memory and
> > > reinstate VGA memory arbitration.
> > 
> > I would think there is still a VGA disable bit on the Intel device
> > somewhere, we'd just need
> > Intel to look in the docs and find it. A bit that can nuke both i/o
> > and cmd regs.
> 
> The only bit available is in the GGC and is a keyed/locked register that
> not only disables VGA memory and I/O, but also modifies the class code
> of the device.  Early Core processors didn't lock this, but it's
> untouchable in newer ones AFAICT.  Thanks,

I've not found anything else in the docs. And also we _need_ VGA I/O
access to make i915_disable_vga() work. It's not 100% clear whether
we really need to poke at the sequencer register in modern hardware,
but the docs do still list it as a mandatory step. So even if we were
to have a global "disable VGA I/O and mem bit" we'd need to make sure
we already disabled VGA eg. after resume when the BIOS had a chance to
turn the VGA display back on. I think there were also some BIOSen that
turned VGA display back on when closing/opening the laptop lid. Not
sure what would even happen with those if totally disabled VGA I/O
access. I'm not sure they actually frob with the VGA regs though.
Could be they just turn on the VGA display bit in the VGA_CONTROL
register.

-- 
Ville Syrjälä
Intel OTC

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i915: Update VGA arbiter support for newer devices
Date: Fri, 16 Aug 2013 13:20:17 +0300	[thread overview]
Message-ID: <20130816102017.GK7159@intel.com> (raw)
In-Reply-To: <1376607255.13642.155.camel@ul30vt.home>

On Thu, Aug 15, 2013 at 04:54:15PM -0600, Alex Williamson wrote:
> On Fri, 2013-08-16 at 08:49 +1000, Dave Airlie wrote:
> > On Fri, Aug 16, 2013 at 8:43 AM, Alex Williamson
> > <alex.williamson@redhat.com> wrote:
> > > This is intended to add VGA arbiter support for Intel HD graphics on
> > > Core processors.  The old GMCH registers no longer exist, so even
> > > though it appears that i915 participates in VGA arbitration, it doesn't
> > > work.  On Intel HD graphics we already attempt to disable VGA regions
> > > of the device.  This makes registering as a VGA client unnecessary since
> > > we don't intend to operate differently depending on how many VGA devices
> > > are present.  We can disable VGA memory regions by clearing a memory
> > > enable bit in the VGA MSR.  That only leaves VGA IO, which we update
> > > the VGA arbiter to know that we don't participate in VGA memory
> > > arbitration.  We also add a hook on unload to re-enable memory and
> > > reinstate VGA memory arbitration.
> > 
> > I would think there is still a VGA disable bit on the Intel device
> > somewhere, we'd just need
> > Intel to look in the docs and find it. A bit that can nuke both i/o
> > and cmd regs.
> 
> The only bit available is in the GGC and is a keyed/locked register that
> not only disables VGA memory and I/O, but also modifies the class code
> of the device.  Early Core processors didn't lock this, but it's
> untouchable in newer ones AFAICT.  Thanks,

I've not found anything else in the docs. And also we _need_ VGA I/O
access to make i915_disable_vga() work. It's not 100% clear whether
we really need to poke at the sequencer register in modern hardware,
but the docs do still list it as a mandatory step. So even if we were
to have a global "disable VGA I/O and mem bit" we'd need to make sure
we already disabled VGA eg. after resume when the BIOS had a chance to
turn the VGA display back on. I think there were also some BIOSen that
turned VGA display back on when closing/opening the laptop lid. Not
sure what would even happen with those if totally disabled VGA I/O
access. I'm not sure they actually frob with the VGA regs though.
Could be they just turn on the VGA display bit in the VGA_CONTROL
register.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-08-16 10:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 22:43 [PATCH] i915: Update VGA arbiter support for newer devices Alex Williamson
2013-08-15 22:49 ` Dave Airlie
2013-08-15 22:54   ` Alex Williamson
2013-08-16 10:20     ` Ville Syrjälä [this message]
2013-08-16 10:20       ` Ville Syrjälä
2013-08-16 18:22       ` Alex Williamson
2013-08-16 18:22         ` Alex Williamson
2013-08-20 19:46         ` Ville Syrjälä
2013-08-23 18:21           ` [Intel-gfx] " Ville Syrjälä
2013-08-23 21:18             ` Alex Williamson
2013-08-23 21:53               ` Alex Williamson

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=20130816102017.GK7159@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=airlied@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.