From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: intel-gfx@lists.freedesktop.org, airlied@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] i915: Update VGA arbiter support for newer devices
Date: Mon, 26 Aug 2013 15:23:19 +0300 [thread overview]
Message-ID: <20130826122319.GO11428@intel.com> (raw)
In-Reply-To: <20130824144701.23370.42110.stgit@bling.home>
On Sat, Aug 24, 2013 at 08:53:40AM -0600, Alex Williamson 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 the 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.
>
> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> ---
>
> v2: I915_READ/WRITE accessors don't work in i915_disable_vga, use inb/outb
> directly. Also, on the driver unbind VGA enable path, acquire legacy
> IO to re-enable VGA memory. Correct comment.
>
> As with v1, this depends on "vgaarb: Fixes for partial VGA opt-out". With
> all patches I'm able to assign a discrete PEG VGA device to a guest and
> execute the VBIOS w/o interference from IGD or corruption of the IGD
> framebuffer.
I glanced through those before, but I'll try to do a more thorough
review soon.
>
> drivers/gpu/drm/i915/i915_dma.c | 9 ++++++---
> drivers/gpu/drm/i915/intel_display.c | 24 ++++++++++++++++++++++++
> 2 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index f466980..d9cf216 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1287,9 +1287,12 @@ static int i915_load_modeset_init(struct drm_device *dev)
> * then we do not take part in VGA arbitration and the
> * vga_client_register() fails with -ENODEV.
> */
> - ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode);
> - if (ret && ret != -ENODEV)
> - goto out;
> + if (!HAS_PCH_SPLIT(dev)) {
> + ret = vga_client_register(dev->pdev, dev, NULL,
> + i915_vga_set_decode);
> + if (ret && ret != -ENODEV)
> + goto out;
> + }
I think we should do something to fix i915_redisable_vga() for !pch
platforms too. The MSR method should work for everything, so I'm leaning
towards using it all the time. The other option would be add an mmio
codepath into intel_disable_vga(), but then we have several codepaths
to worry about.
>
> intel_register_dsm_handler();
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 5fb3058..2bb805c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9519,6 +9519,15 @@ static void i915_disable_vga(struct drm_device *dev)
> outb(SR01, VGA_SR_INDEX);
> sr1 = inb(VGA_SR_DATA);
> outb(sr1 | 1<<5, VGA_SR_DATA);
> +
> + /* Disable VGA memory on Intel HD */
> + if (HAS_PCH_SPLIT(dev)) {
> + outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
> + vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
> + VGA_RSRC_NORMAL_IO |
> + VGA_RSRC_NORMAL_MEM);
> + }
> +
> vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
> udelay(300);
>
> @@ -9526,6 +9535,19 @@ static void i915_disable_vga(struct drm_device *dev)
> POSTING_READ(vga_reg);
> }
>
> +static void i915_enable_vga(struct drm_device *dev)
> +{
Not sure we need this actually. We don't re-enable the VGA display
on unload, so you'll never see anything on the display anyway. But
then again, I don't see any real harm in doing this either.
> + /* Enable VGA memory on Intel HD */
> + if (HAS_PCH_SPLIT(dev)) {
> + vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
> + outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
I was thinking we might save the MSR state during driver load and
restore to that same state, but it could be a bit overkill.
> + vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_MASK |
Maybe spell out IO and MEM for legacy too. Otherwise it looks a
bit cryptic.
> + VGA_RSRC_NORMAL_IO |
> + VGA_RSRC_NORMAL_MEM);
> + vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
> + }
> +}
> +
> void intel_modeset_init_hw(struct drm_device *dev)
> {
> intel_init_power_well(dev);
> @@ -9983,6 +10005,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
>
> intel_disable_fbc(dev);
>
> + i915_enable_vga(dev);
> +
> intel_disable_gt_powersave(dev);
>
> ironlake_teardown_rc6(dev);
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-08-26 12:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-24 14:53 [PATCH v2] i915: Update VGA arbiter support for newer devices Alex Williamson
2013-08-26 12:23 ` Ville Syrjälä [this message]
2013-08-26 16:05 ` Alex Williamson
2013-08-26 17:47 ` Ville Syrjälä
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=20130826122319.GO11428@intel.com \
--to=ville.syrjala@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox