From: Jani Nikula <jani.nikula@linux.intel.com>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [Intel-gfx] [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices
Date: Mon, 11 Jun 2012 11:42:35 +0300 [thread overview]
Message-ID: <87ipeyp7d0.fsf@intel.com> (raw)
In-Reply-To: <1339172439-9115-1-git-send-email-daniel.vetter@ffwll.ch>
On Fri, 08 Jun 2012, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> There's the neat little problem that some systems die if vga decoding
> isn't decoded anywhere, because linux disabled that pci device.
>
> Atm we solve that problem by simple not calling pci_disable_device at
> driver unregister time for drm pci devices. Which isn't to great
> because it leaks a pci_enable_device reference on module reload and
> also is rather inconsistent, since the driver load codcode in
> drm/drm_pci.c _does_ call pci_disable_device on the load error path.
>
> To fix this issue, let the vga arbiter hold a pci_enable_device
> reference on its own when the vga device decodes anything. This leaves
> the issue still open when the vga arbiter isn't loaded/compiled in,
> but I guess since drm module unload is riddled with dragons it's ok to
> say "just don't do this".
>
> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/vga/vgaarb.c | 27 +++++++++++++++++++++++++--
> 1 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 3df8fc0..82f19a1 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -49,7 +49,11 @@
> static void vga_arbiter_notify_clients(void);
> /*
> * We keep a list of all vga devices in the system to speed
> - * up the various operations of the arbiter
> + * up the various operations of the arbiter. Note that vgaarb keeps a
> + * pci_enable_device reference for all vga devices with owns != 0. This is to
> + * avoid drm devices from killing the system when they call pci_disable_device
> + * on module unload (as they should), because some systems don't like it if no
> + * one decodes vga.
> */
> struct vga_device {
> struct list_head list;
> @@ -171,7 +175,7 @@ static struct vga_device *__vga_tryget(struct vga_device *vgadev,
> {
> unsigned int wants, legacy_wants, match;
> struct vga_device *conflict;
> - unsigned int pci_bits;
> + unsigned int pci_bits, ret;
> u32 flags = 0;
>
> /* Account for "normal" resources to lock. If we decode the legacy,
> @@ -264,6 +268,10 @@ static struct vga_device *__vga_tryget(struct vga_device *vgadev,
>
> pci_set_vga_state(conflict->pdev, false, pci_bits, flags);
> conflict->owns &= ~lwants;
> +
> + if (conflict->owns == 0)
> + pci_disable_device(conflict->pdev);
> +
> /* If he also owned non-legacy, that is no longer the case */
> if (lwants & VGA_RSRC_LEGACY_MEM)
> conflict->owns &= ~VGA_RSRC_NORMAL_MEM;
> @@ -290,6 +298,12 @@ enable_them:
> if (!!(wants & VGA_RSRC_LEGACY_MASK))
> flags |= PCI_VGA_STATE_CHANGE_BRIDGE;
>
> + if (vgadev->owns == 0) {
> + ret = pci_enable_device(vgadev->pdev);
> + if (ret)
> + return ERR_PTR(ret);
Hi Daniel, I think unsigned ret will result in a positive ERR_PTR, which
won't be caught by IS_ERR_VALUE(). (Either that, or I need more coffee
to get the promotion rules right. Better use signed int no matter what.)
BR,
Jani.
> + }
> +
> pci_set_vga_state(vgadev->pdev, true, pci_bits, flags);
>
> if (!vgadev->bridge_has_one_vga) {
> @@ -376,6 +390,8 @@ int vga_get(struct pci_dev *pdev, unsigned int rsrc, int interruptible)
> if (conflict == NULL)
> break;
>
> + if (IS_ERR(conflict))
> + return PTR_ERR(conflict);
>
> /* We have a conflict, we wait until somebody kicks the
> * work queue. Currently we have one work queue that we
> @@ -513,6 +529,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
> unsigned long flags;
> struct pci_bus *bus;
> struct pci_dev *bridge;
> + int ret;
> u16 cmd;
>
> /* Only deal with VGA class devices */
> @@ -582,6 +599,12 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
>
> vga_arbiter_check_bridge_sharing(vgadev);
>
> + if (vgadev->owns != 0) {
> + ret = pci_enable_device(vgadev->pdev);
> + if (ret)
> + goto fail;
> + }
> +
> /* Add to the list */
> list_add(&vgadev->list, &vga_list);
> vga_count++;
> --
> 1.7.7.6
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2012-06-11 8:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-08 16:20 [PATCH] vgaarb: call pci_disable|enable_device on decoding vga devices Daniel Vetter
2012-06-11 8:42 ` Jani Nikula [this message]
2012-06-11 7:59 ` Daniel Vetter
2012-06-11 8:44 ` Daniel Vetter
2012-07-18 16:03 ` Daniel Vetter
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=87ipeyp7d0.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.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.