* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-17 11:30 ` [PATCH v2 1/1] Split VGA default device handler out of " Daniel Axtens
@ 2017-08-18 7:38 ` Daniel Vetter
2017-08-19 15:47 ` Bjorn Helgaas
2017-08-21 10:53 ` Lorenzo Pieralisi
2 siblings, 0 replies; 13+ messages in thread
From: Daniel Vetter @ 2017-08-18 7:38 UTC (permalink / raw)
To: Daniel Axtens
Cc: linux-pci, linuxppc-dev, linux-arm-kernel, gabriele.paoloni,
will.deacon, dri-devel, z.liuxinliang, bhelgaas, alex.williamson,
catalin.marinas, zourongrong, daniel.vetter
On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> A system without PCI legacy resources (e.g. ARM64) may find that no
> default/boot VGA device has been marked, because the VGA arbiter
> checks for legacy resource decoding before marking a card as default.
>
> Split the small bit of code that does default VGA handling out from
> the arbiter. Add a Kconfig option to allow the kernel to be built
> with just the default handling, or the arbiter and default handling.
>
> Add handling for devices that should be marked as default but aren't
> handled by the vga arbiter by adding a late initcall and a class
> enable hook. If there is no default from vgaarb then the first card
> that is enabled, has a driver bound, and can decode memory or I/O
> will be marked as default.
>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
Looks reasonable, but I have no clue at all about this. Can you pls get
some proper review from pci/platform folks (ppc would be good to)? I can
apply to drm-misc once that's done.
Just documentation comments below.
Thanks, Daniel
>
> ---
>
> v2: Tested on:
> - x86_64 laptop
> - arm64 D05 board with hibmc card
> - qemu powerpc with tcg and bochs std-vga
>
> I know this adds another config option and that's a bit sad, but
> we can't include it unconditionally as it depends on PCI.
> Suggestions welcome.
> ---
> arch/ia64/pci/fixup.c | 2 +-
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/x86/pci/fixup.c | 2 +-
> arch/x86/video/fbdev.c | 2 +-
> drivers/gpu/vga/Kconfig | 12 +++
> drivers/gpu/vga/Makefile | 1 +
> drivers/gpu/vga/vga_default.c | 159 +++++++++++++++++++++++++++++++++++++++
> drivers/gpu/vga/vga_switcheroo.c | 2 +-
> drivers/gpu/vga/vgaarb.c | 41 +---------
> drivers/pci/pci-sysfs.c | 2 +-
> include/linux/vga_default.h | 44 +++++++++++
> include/linux/vgaarb.h | 14 ----
> 12 files changed, 225 insertions(+), 58 deletions(-)
> create mode 100644 drivers/gpu/vga/vga_default.c
> create mode 100644 include/linux/vga_default.h
>
> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
> index 41caa99add51..b35d1cf4501a 100644
> --- a/arch/ia64/pci/fixup.c
> +++ b/arch/ia64/pci/fixup.c
> @@ -5,7 +5,7 @@
>
> #include <linux/pci.h>
> #include <linux/init.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <linux/screen_info.h>
>
> #include <asm/machvec.h>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index 341a7469cab8..4fd890a51d18 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -31,7 +31,7 @@
> #include <linux/irq.h>
> #include <linux/vmalloc.h>
> #include <linux/slab.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
>
> #include <asm/processor.h>
> #include <asm/io.h>
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 11e407489db0..b1254bc09a45 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -5,7 +5,7 @@
> #include <linux/delay.h>
> #include <linux/dmi.h>
> #include <linux/pci.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <asm/hpet.h>
> #include <asm/pci_x86.h>
>
> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c
> index 9fd24846d094..62cfa74ea86e 100644
> --- a/arch/x86/video/fbdev.c
> +++ b/arch/x86/video/fbdev.c
> @@ -9,7 +9,7 @@
> #include <linux/fb.h>
> #include <linux/pci.h>
> #include <linux/module.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
>
> int fb_is_primary_device(struct fb_info *info)
> {
> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
> index 29437eabe095..81d4105aecf6 100644
> --- a/drivers/gpu/vga/Kconfig
> +++ b/drivers/gpu/vga/Kconfig
> @@ -1,3 +1,14 @@
> +config VGA_DEFAULT
> + bool "VGA Default Device Support" if EXPERT
> + default y
> + depends on PCI
> + help
> + Some programs find it helpful to know what VGA device is the default.
> + On platforms like x86 this means the device used by the BIOS to show
> + early boot messages. On other platforms this may be an arbitrary PCI
> + graphics card. Select this to have a default device recorded within
> + the kernel and exposed to userspace through sysfs.
> +
> config VGA_ARB
> bool "VGA Arbitration" if EXPERT
> default y
> @@ -22,6 +33,7 @@ config VGA_SWITCHEROO
> depends on X86
> depends on ACPI
> select VGA_ARB
> + select VGA_DEFAULT
> help
> Many laptops released in 2008/9/10 have two GPUs with a multiplexer
> to switch between them. This adds support for dynamic switching when
> diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile
> index 14ca30b75d0a..1e30f90d40fb 100644
> --- a/drivers/gpu/vga/Makefile
> +++ b/drivers/gpu/vga/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_VGA_ARB) += vgaarb.o
> +obj-$(CONFIG_VGA_DEFAULT) += vga_default.o
> obj-$(CONFIG_VGA_SWITCHEROO) += vga_switcheroo.o
> diff --git a/drivers/gpu/vga/vga_default.c b/drivers/gpu/vga/vga_default.c
> new file mode 100644
> index 000000000000..f6fcb0eb1507
> --- /dev/null
> +++ b/drivers/gpu/vga/vga_default.c
> @@ -0,0 +1,159 @@
> +/*
> + * vga_default.c: What is the default/boot PCI VGA device?
> + *
> + * (C) Copyright 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + * (C) Copyright 2007 Paulo R. Zanoni <przanoni@gmail.com>
> + * (C) Copyright 2007, 2009 Tiago Vignatti <vignatti@freedesktop.org>
> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens <dja@axtens.net>)
> + *
> + * (License from vgaarb.c)
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +/*
Please make this into a DOC: introduction section.
> + * What device should a graphics system draw to? In order of priority:
> + *
> + * 1) Any devices configured specifically by the user (think
> + * xorg.conf).
> + *
> + * 2) If the platform has a concept of a boot device for early boot
> + * messages (think BIOS displays on x86), that device.
> + *
> + * 3) If the platform does not have the concept of a boot device,
> + * then we still want to pick something. For now, pick the first
> + * PCI VGA device with a driver bound and with memory or I/O
> + * control on.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/init.h>
> +
> +#include <linux/vga_default.h>
> +
> +static struct pci_dev *vga_default;
> +/*
> + * only go active after the late initcall so as not to interfere with
> + * the arbiter
> + */
> +static bool vga_default_active = false;
> +
> +/**
> + * vga_default_device - return the default VGA device
All the nice kerneldoc, but not pulled into Documentation/gpu. Can you pls
fix that and make sure the resulting docs look pretty and have all the
links still working?
> + *
> + * This can be defined by the platform. The default implementation
> + * is rather dumb and will probably only work properly on single
> + * vga card setups and/or x86 platforms.
> + *
> + * If your VGA default device is not PCI, you'll have to return
> + * NULL here. In this case, I assume it will not conflict with
> + * any PCI card. If this is not true, I'll have to define two archs
> + * hooks for enabling/disabling the VGA default device if that is
> + * possible. This may be a problem with real _ISA_ VGA cards, in
> + * addition to a PCI one. I don't know at this point how to deal
> + * with that card. Can theirs IOs be disabled at all ? If not, then
> + * I suppose it's a matter of having the proper arch hook telling
> + * us about it, so we basically never allow anybody to succeed a
> + * vga_get()...
I'd like reviewers to convert this lore into a solid statement of fact :-)
> + */
> +
> +struct pci_dev *vga_default_device(void)
> +{
> + return vga_default;
> +}
> +EXPORT_SYMBOL_GPL(vga_default_device);
> +
> +void vga_set_default_device(struct pci_dev *pdev)
> +{
> + if (vga_default == pdev)
> + return;
> +
> + pci_dev_put(vga_default);
> + vga_default = pci_dev_get(pdev);
> +}
> +
> +static bool vga_default_try_device(struct pci_dev *pdev)
> +{
> + u16 cmd;
> +
> + /* Only deal with VGA class devices */
> + if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> + return false;
> +
> + /* Only deal with devices with drivers bound */
> + if (!pdev->driver)
> + return false;
> +
> + /* Require I/O or memory control */
> + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> + if (!(cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)))
> + return false;
> +
> + dev_info(&pdev->dev, "vga_default: setting as default device\n");
> + vga_set_default_device(pdev);
> + return true;
> +}
> +
> +static int __init vga_default_init(void)
> +{
> + struct pci_dev *pdev;
> +
> + vga_default_active = true;
> +
> + if (vga_default_device())
> + return 0;
> +
> + pdev = NULL;
> + while ((pdev =
> + pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> + PCI_ANY_ID, pdev)) != NULL) {
> + if (vga_default_try_device(pdev))
> + return 0;
> + }
> +
> + return 0;
> +}
> +late_initcall(vga_default_init);
> +
> +/*
> + * A driver could be loaded much later than late_initcall, for example
> + * if it's in a module.
> + *
> + * We want to pick that up. However, we want to make sure this does
> + * not interfere with the arbiter - it should only activate if the
> + * arbiter has already had a chance to operate. To ensure this, we set
> + * vga_default_active in the late_initcall: as the vga arbiter is a
> + * subsys initcall, it is guaranteed to fire first.
> + */
> +static void vga_default_enable_hook(struct pci_dev *pdev)
> +{
> + if (!vga_default_active)
> + return;
> +
> + if (vga_default_device())
> + return;
> +
> + vga_default_try_device(pdev);
> +}
> +DECLARE_PCI_FIXUP_CLASS_ENABLE(PCI_ANY_ID, PCI_ANY_ID,
> + PCI_CLASS_DISPLAY_VGA, 8,
> + vga_default_enable_hook)
> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
> index 3cd153c6d271..6612ec7981b6 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -41,7 +41,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/seq_file.h>
> #include <linux/uaccess.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <linux/vga_switcheroo.h>
>
> /**
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 76875f6299b8..74683286f5f8 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -51,6 +51,7 @@
>
> #include <linux/uaccess.h>
>
> +#include <linux/vga_default.h>
> #include <linux/vgaarb.h>
>
> static void vga_arbiter_notify_clients(void);
> @@ -119,9 +120,6 @@ static int vga_str_to_iostate(char *buf, int str_size, int *io_state)
> return 1;
> }
>
> -/* this is only used a cookie - it should not be dereferenced */
> -static struct pci_dev *vga_default;
> -
> static void vga_arb_device_card_gone(struct pci_dev *pdev);
>
> /* Find somebody in our list */
> @@ -135,39 +133,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
> return NULL;
> }
>
> -/**
> - * vga_default_device - return the default VGA device, for vgacon
> - *
> - * This can be defined by the platform. The default implementation
> - * is rather dumb and will probably only work properly on single
> - * vga card setups and/or x86 platforms.
> - *
> - * If your VGA default device is not PCI, you'll have to return
> - * NULL here. In this case, I assume it will not conflict with
> - * any PCI card. If this is not true, I'll have to define two archs
> - * hooks for enabling/disabling the VGA default device if that is
> - * possible. This may be a problem with real _ISA_ VGA cards, in
> - * addition to a PCI one. I don't know at this point how to deal
> - * with that card. Can theirs IOs be disabled at all ? If not, then
> - * I suppose it's a matter of having the proper arch hook telling
> - * us about it, so we basically never allow anybody to succeed a
> - * vga_get()...
> - */
> -struct pci_dev *vga_default_device(void)
> -{
> - return vga_default;
> -}
> -EXPORT_SYMBOL_GPL(vga_default_device);
> -
> -void vga_set_default_device(struct pci_dev *pdev)
> -{
> - if (vga_default == pdev)
> - return;
> -
> - pci_dev_put(vga_default);
> - vga_default = pci_dev_get(pdev);
> -}
> -
> static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
> {
> if (vgadev->irq_set_state)
> @@ -667,7 +632,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
> /* Deal with VGA default device. Use first enabled one
> * by default if arch doesn't have it's own hook
> */
> - if (vga_default == NULL &&
> + if (vga_default_device() == NULL &&
> ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
> vgaarb_info(&pdev->dev, "setting as boot VGA device\n");
> vga_set_default_device(pdev);
> @@ -704,7 +669,7 @@ static bool vga_arbiter_del_pci_device(struct pci_dev *pdev)
> goto bail;
> }
>
> - if (vga_default == pdev)
> + if (vga_default_device() == pdev)
> vga_set_default_device(NULL);
>
> if (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 2f3780b50723..c174b427ea2b 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -27,7 +27,7 @@
> #include <linux/security.h>
> #include <linux/pci-aspm.h>
> #include <linux/slab.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> #include "pci.h"
> diff --git a/include/linux/vga_default.h b/include/linux/vga_default.h
> new file mode 100644
> index 000000000000..78df6a2a194c
> --- /dev/null
> +++ b/include/linux/vga_default.h
> @@ -0,0 +1,44 @@
> +/*
> + * vga_default.h: What is the default/boot PCI VGA device?
> + *
> + * (C) Copyright 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + * (C) Copyright 2007 Paulo R. Zanoni <przanoni@gmail.com>
> + * (C) Copyright 2007, 2009 Tiago Vignatti <vignatti@freedesktop.org>
> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens <dja@axtens.net>)
> + *
> + * (License from vgaarb.h)
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef LINUX_VGA_DEFAULT_H
> +#define LINUX_VGA_DEFAULT_H
> +
> +struct pci_dev;
> +
> +#ifdef CONFIG_VGA_DEFAULT
> +extern struct pci_dev *vga_default_device(void);
> +extern void vga_set_default_device(struct pci_dev *pdev);
> +#else
> +static inline struct pci_dev *vga_default_device(void) { return NULL; };
> +static inline void vga_set_default_device(struct pci_dev *pdev) { };
> +#endif
> +
> +#endif
> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> index ee162e3e879b..953e1955efbe 100644
> --- a/include/linux/vgaarb.h
> +++ b/include/linux/vgaarb.h
> @@ -42,12 +42,6 @@
> #define VGA_RSRC_NORMAL_IO 0x04
> #define VGA_RSRC_NORMAL_MEM 0x08
>
> -/* Passing that instead of a pci_dev to use the system "default"
> - * device, that is the one used by vgacon. Archs will probably
> - * have to provide their own vga_default_device();
> - */
> -#define VGA_DEFAULT_DEVICE (NULL)
> -
> struct pci_dev;
>
> /* For use by clients */
> @@ -122,14 +116,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int rsrc);
> #endif
>
>
> -#ifdef CONFIG_VGA_ARB
> -extern struct pci_dev *vga_default_device(void);
> -extern void vga_set_default_device(struct pci_dev *pdev);
> -#else
> -static inline struct pci_dev *vga_default_device(void) { return NULL; };
> -static inline void vga_set_default_device(struct pci_dev *pdev) { };
> -#endif
> -
> /*
> * Architectures should define this if they have several
> * independent PCI domains that can afford concurrent VGA
> --
> 2.11.0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-17 11:30 ` [PATCH v2 1/1] Split VGA default device handler out of " Daniel Axtens
2017-08-18 7:38 ` Daniel Vetter
@ 2017-08-19 15:47 ` Bjorn Helgaas
2017-08-20 19:08 ` Benjamin Herrenschmidt
2017-08-21 10:53 ` Lorenzo Pieralisi
2 siblings, 1 reply; 13+ messages in thread
From: Bjorn Helgaas @ 2017-08-19 15:47 UTC (permalink / raw)
To: Daniel Axtens
Cc: linux-pci, linuxppc-dev, linux-arm-kernel, gabriele.paoloni,
airlied, benh, will.deacon, dri-devel, z.liuxinliang, bhelgaas,
alex.williamson, lukas, catalin.marinas, zourongrong,
daniel.vetter
On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> A system without PCI legacy resources (e.g. ARM64)
Can you be a little more specific about what you mean by "a system
without PCI legacy resources"? I'm not sure what the connection with
ARM64 as an architecture is.
My understanding is that "legacy resources" are addresses that are
hard-wired into a device and not discoverable or configurable via a
BAR [1]. For example,
VGA devices (see [2])
mem 0xa0000-0xbffff (frame buffer)
io 0x3b0-0x3bb (plus ISA aliases)
io 0x3c0-0x3df (plus ISA aliases)
IDE devices in compatibility mode (see [3])
io 0x170-0x177 (secondary command)
io 0x1f0-0x1f7 (primary command)
io 0x376 (secondary control)
io 0x3f6 (primary control)
The meaning of these resources in the PCI/PCIe domain is defined by
the PCI specs, not the platform arch specs.
So if ARM64 doesn't have these PCI legacy resources, does that mean an
ARM64 host bridge cannot generate these legacy addresses on PCI? That
is, there's no host bridge window that maps to those PCI addresses?
That seems like a curious restriction on host bridges, but I guess it
would be possible.
I think you're fixing an issue related to the HiSilicon [19e5:1610]
PCI-to-PCI bridge, which doesn't support VGA Enable (I first thought
the bridge was broken, but per [4], I think it is legal). With VGA
Enable not being supported, a downstream VGA device will not work if
it depends on the legacy VGA resources. But this is merely related to
one PCI-to-PCI bridge in the system; it's not a question of the system
as a whole or the CPU architecture.
Maybe I'm reading too much into the "ARM64 has no PCI legacy
resources" idea and the point here is simply that the VGA arbiter
previously would not mark a VGA device as default if it found that the
legacy resources are not routed to it, e.g., because an upstream
bridge doesn't support VGA ENABLE?
That's "safe" because if the arbiter selects a default VGA device that
does not receive accesses to the legacy VGA resources, that device may
not work. For example, it looks like vga16fb.c would not work because
it depends on VGA_FB_PHYS at 0xA0000. A native driver certainly
*could* work, but that depends on whether the specific device and
driver require the legacy resources.
IIUC, part of what this patch does is relax this so we can set a
default "VGA device" that doesn't receive accesses to legacy VGA
resources. If so, it's probably worth mentioning somehow that some
VGA things, e.g., vga16fb.c, may not work with this default device.
[1] PCI spec r3.0, sec G
[2] PCI-to-PCI bridge spec r1.2, sec 3.2.5.18, sec 12.1.1
[3] PCI IDE Controller spec, r1.0, sec 2.1
[4] PCI-to-PCI bridge spec r1.2, sec 4.5
> may find that no
> default/boot VGA device has been marked, because the VGA arbiter
> checks for legacy resource decoding before marking a card as default.
>
> Split the small bit of code that does default VGA handling out from
> the arbiter. Add a Kconfig option to allow the kernel to be built
> with just the default handling, or the arbiter and default handling.
>
> Add handling for devices that should be marked as default but aren't
> handled by the vga arbiter by adding a late initcall and a class
> enable hook. If there is no default from vgaarb then the first card
> that is enabled, has a driver bound, and can decode memory or I/O
> will be marked as default.
> + * vga_default_device - return the default VGA device
> + *
> + * This can be defined by the platform. The default implementation
> + * is rather dumb and will probably only work properly on single
> + * vga card setups and/or x86 platforms.
In what sense can this be defined by the platform? I guess this
comment isn't new and was just moved, but I don't see any arch hook or
obvious way to do a platform-specific definition.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-19 15:47 ` Bjorn Helgaas
@ 2017-08-20 19:08 ` Benjamin Herrenschmidt
2017-08-20 21:54 ` Bjorn Helgaas
0 siblings, 1 reply; 13+ messages in thread
From: Benjamin Herrenschmidt @ 2017-08-20 19:08 UTC (permalink / raw)
To: Bjorn Helgaas, Daniel Axtens
Cc: linux-pci, linuxppc-dev, linux-arm-kernel, gabriele.paoloni,
airlied, will.deacon, dri-devel, z.liuxinliang, bhelgaas,
alex.williamson, lukas, catalin.marinas, zourongrong,
daniel.vetter
On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote:
> So if ARM64 doesn't have these PCI legacy resources, does that mean an
> ARM64 host bridge cannot generate these legacy addresses on PCI? That
> is, there's no host bridge window that maps to those PCI addresses?
> That seems like a curious restriction on host bridges, but I guess it
> would be possible.
It's rather common. For example on POWER8:
- There is no IO space at all
- We configure the 32-bit MMIO window to be around 3..4G (to avoid
overlapping with DMA space below it).
So we effectively have no path to the legacy areas, and that hasn't
been a problem so far.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-20 19:08 ` Benjamin Herrenschmidt
@ 2017-08-20 21:54 ` Bjorn Helgaas
0 siblings, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2017-08-20 21:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Daniel Axtens, linux-pci, linuxppc-dev, linux-arm-kernel,
gabriele.paoloni, airlied, will.deacon, dri-devel, z.liuxinliang,
bhelgaas, alex.williamson, lukas, catalin.marinas, zourongrong,
daniel.vetter
On Sun, Aug 20, 2017 at 12:08:20PM -0700, Benjamin Herrenschmidt wrote:
> On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote:
> > So if ARM64 doesn't have these PCI legacy resources, does that mean an
> > ARM64 host bridge cannot generate these legacy addresses on PCI? That
> > is, there's no host bridge window that maps to those PCI addresses?
> > That seems like a curious restriction on host bridges, but I guess it
> > would be possible.
>
> It's rather common. For example on POWER8:
I'm just trying to tease out which things are required by PCI and
which things are required by the arch. It doesn't surprise me at all
that some platforms (on any arch) don't provide access to legacy
resources. That's totally outside the PCI area. Do Power and ARM64
actively *prohibit* platforms from using legacy resources? I can
believe current platforms don't use them, but I can still conceive of
possible systems that could.
I think removing the "(e.g. ARM64)" from the original changelog would
have avoided my questions. That example suggests that ARM64 is
special in some way and *cannot* use PCI legacy resources. It's easy
to conceive of a system of any arch that can't use them, simply
because it chose to use a host bridge that can't generate PCI
transactions to the VGA frame buffer or to I/O space.
> - There is no IO space at all
>
> - We configure the 32-bit MMIO window to be around 3..4G (to avoid
> overlapping with DMA space below it).
>
> So we effectively have no path to the legacy areas, and that hasn't
> been a problem so far.
I assume vga16fb.c and similar things don't work (which isn't a
problem as long as that's what everybody expects).
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-17 11:30 ` [PATCH v2 1/1] Split VGA default device handler out of " Daniel Axtens
2017-08-18 7:38 ` Daniel Vetter
2017-08-19 15:47 ` Bjorn Helgaas
@ 2017-08-21 10:53 ` Lorenzo Pieralisi
2017-08-22 22:19 ` Bjorn Helgaas
2 siblings, 1 reply; 13+ messages in thread
From: Lorenzo Pieralisi @ 2017-08-21 10:53 UTC (permalink / raw)
To: Daniel Axtens
Cc: linux-pci, linuxppc-dev, linux-arm-kernel, benh, z.liuxinliang,
zourongrong, catalin.marinas, will.deacon, gabriele.paoloni,
bhelgaas, airlied, daniel.vetter, alex.williamson, dri-devel,
lukas
On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> A system without PCI legacy resources (e.g. ARM64) may find that no
> default/boot VGA device has been marked, because the VGA arbiter
> checks for legacy resource decoding before marking a card as default.
I do not understand this paragraph, in particular:
- "A system without PCI legacy resources (e.g. ARM64)". What does this
mean ? I take this as "ARM64 does not support IO space"; if a PCI host
bridge supports IO space, there is nothing from an architectural
point of view that prevents an MMIO based IO space implementation to
work on ARM64. It is PCI bridge specific, not arch specific.
- "the VGA arbiter checks for legacy resources". Do you mean it checks
if a VGA class device enabled IO/MEM address spaces (and if the
bridges upstream forwards those address spaces), correct ?
The assumption relying on ARM64 not supporting IO space (if that's what
you mean by "a system without PCI legacy resources") is not correct.
Thanks,
Lorenzo
> Split the small bit of code that does default VGA handling out from
> the arbiter. Add a Kconfig option to allow the kernel to be built
> with just the default handling, or the arbiter and default handling.
>
> Add handling for devices that should be marked as default but aren't
> handled by the vga arbiter by adding a late initcall and a class
> enable hook. If there is no default from vgaarb then the first card
> that is enabled, has a driver bound, and can decode memory or I/O
> will be marked as default.
>
> Signed-off-by: Daniel Axtens <dja@axtens.net>
>
> ---
>
> v2: Tested on:
> - x86_64 laptop
> - arm64 D05 board with hibmc card
> - qemu powerpc with tcg and bochs std-vga
>
> I know this adds another config option and that's a bit sad, but
> we can't include it unconditionally as it depends on PCI.
> Suggestions welcome.
> ---
> arch/ia64/pci/fixup.c | 2 +-
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/x86/pci/fixup.c | 2 +-
> arch/x86/video/fbdev.c | 2 +-
> drivers/gpu/vga/Kconfig | 12 +++
> drivers/gpu/vga/Makefile | 1 +
> drivers/gpu/vga/vga_default.c | 159 +++++++++++++++++++++++++++++++++++++++
> drivers/gpu/vga/vga_switcheroo.c | 2 +-
> drivers/gpu/vga/vgaarb.c | 41 +---------
> drivers/pci/pci-sysfs.c | 2 +-
> include/linux/vga_default.h | 44 +++++++++++
> include/linux/vgaarb.h | 14 ----
> 12 files changed, 225 insertions(+), 58 deletions(-)
> create mode 100644 drivers/gpu/vga/vga_default.c
> create mode 100644 include/linux/vga_default.h
>
> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
> index 41caa99add51..b35d1cf4501a 100644
> --- a/arch/ia64/pci/fixup.c
> +++ b/arch/ia64/pci/fixup.c
> @@ -5,7 +5,7 @@
>
> #include <linux/pci.h>
> #include <linux/init.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <linux/screen_info.h>
>
> #include <asm/machvec.h>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index 341a7469cab8..4fd890a51d18 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -31,7 +31,7 @@
> #include <linux/irq.h>
> #include <linux/vmalloc.h>
> #include <linux/slab.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
>
> #include <asm/processor.h>
> #include <asm/io.h>
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 11e407489db0..b1254bc09a45 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -5,7 +5,7 @@
> #include <linux/delay.h>
> #include <linux/dmi.h>
> #include <linux/pci.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <asm/hpet.h>
> #include <asm/pci_x86.h>
>
> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c
> index 9fd24846d094..62cfa74ea86e 100644
> --- a/arch/x86/video/fbdev.c
> +++ b/arch/x86/video/fbdev.c
> @@ -9,7 +9,7 @@
> #include <linux/fb.h>
> #include <linux/pci.h>
> #include <linux/module.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
>
> int fb_is_primary_device(struct fb_info *info)
> {
> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
> index 29437eabe095..81d4105aecf6 100644
> --- a/drivers/gpu/vga/Kconfig
> +++ b/drivers/gpu/vga/Kconfig
> @@ -1,3 +1,14 @@
> +config VGA_DEFAULT
> + bool "VGA Default Device Support" if EXPERT
> + default y
> + depends on PCI
> + help
> + Some programs find it helpful to know what VGA device is the default.
> + On platforms like x86 this means the device used by the BIOS to show
> + early boot messages. On other platforms this may be an arbitrary PCI
> + graphics card. Select this to have a default device recorded within
> + the kernel and exposed to userspace through sysfs.
> +
> config VGA_ARB
> bool "VGA Arbitration" if EXPERT
> default y
> @@ -22,6 +33,7 @@ config VGA_SWITCHEROO
> depends on X86
> depends on ACPI
> select VGA_ARB
> + select VGA_DEFAULT
> help
> Many laptops released in 2008/9/10 have two GPUs with a multiplexer
> to switch between them. This adds support for dynamic switching when
> diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile
> index 14ca30b75d0a..1e30f90d40fb 100644
> --- a/drivers/gpu/vga/Makefile
> +++ b/drivers/gpu/vga/Makefile
> @@ -1,2 +1,3 @@
> obj-$(CONFIG_VGA_ARB) += vgaarb.o
> +obj-$(CONFIG_VGA_DEFAULT) += vga_default.o
> obj-$(CONFIG_VGA_SWITCHEROO) += vga_switcheroo.o
> diff --git a/drivers/gpu/vga/vga_default.c b/drivers/gpu/vga/vga_default.c
> new file mode 100644
> index 000000000000..f6fcb0eb1507
> --- /dev/null
> +++ b/drivers/gpu/vga/vga_default.c
> @@ -0,0 +1,159 @@
> +/*
> + * vga_default.c: What is the default/boot PCI VGA device?
> + *
> + * (C) Copyright 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + * (C) Copyright 2007 Paulo R. Zanoni <przanoni@gmail.com>
> + * (C) Copyright 2007, 2009 Tiago Vignatti <vignatti@freedesktop.org>
> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens <dja@axtens.net>)
> + *
> + * (License from vgaarb.c)
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +/*
> + * What device should a graphics system draw to? In order of priority:
> + *
> + * 1) Any devices configured specifically by the user (think
> + * xorg.conf).
> + *
> + * 2) If the platform has a concept of a boot device for early boot
> + * messages (think BIOS displays on x86), that device.
> + *
> + * 3) If the platform does not have the concept of a boot device,
> + * then we still want to pick something. For now, pick the first
> + * PCI VGA device with a driver bound and with memory or I/O
> + * control on.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/pci.h>
> +#include <linux/init.h>
> +
> +#include <linux/vga_default.h>
> +
> +static struct pci_dev *vga_default;
> +/*
> + * only go active after the late initcall so as not to interfere with
> + * the arbiter
> + */
> +static bool vga_default_active = false;
> +
> +/**
> + * vga_default_device - return the default VGA device
> + *
> + * This can be defined by the platform. The default implementation
> + * is rather dumb and will probably only work properly on single
> + * vga card setups and/or x86 platforms.
> + *
> + * If your VGA default device is not PCI, you'll have to return
> + * NULL here. In this case, I assume it will not conflict with
> + * any PCI card. If this is not true, I'll have to define two archs
> + * hooks for enabling/disabling the VGA default device if that is
> + * possible. This may be a problem with real _ISA_ VGA cards, in
> + * addition to a PCI one. I don't know at this point how to deal
> + * with that card. Can theirs IOs be disabled at all ? If not, then
> + * I suppose it's a matter of having the proper arch hook telling
> + * us about it, so we basically never allow anybody to succeed a
> + * vga_get()...
> + */
> +
> +struct pci_dev *vga_default_device(void)
> +{
> + return vga_default;
> +}
> +EXPORT_SYMBOL_GPL(vga_default_device);
> +
> +void vga_set_default_device(struct pci_dev *pdev)
> +{
> + if (vga_default == pdev)
> + return;
> +
> + pci_dev_put(vga_default);
> + vga_default = pci_dev_get(pdev);
> +}
> +
> +static bool vga_default_try_device(struct pci_dev *pdev)
> +{
> + u16 cmd;
> +
> + /* Only deal with VGA class devices */
> + if ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
> + return false;
> +
> + /* Only deal with devices with drivers bound */
> + if (!pdev->driver)
> + return false;
> +
> + /* Require I/O or memory control */
> + pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> + if (!(cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)))
> + return false;
> +
> + dev_info(&pdev->dev, "vga_default: setting as default device\n");
> + vga_set_default_device(pdev);
> + return true;
> +}
> +
> +static int __init vga_default_init(void)
> +{
> + struct pci_dev *pdev;
> +
> + vga_default_active = true;
> +
> + if (vga_default_device())
> + return 0;
> +
> + pdev = NULL;
> + while ((pdev =
> + pci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
> + PCI_ANY_ID, pdev)) != NULL) {
> + if (vga_default_try_device(pdev))
> + return 0;
> + }
> +
> + return 0;
> +}
> +late_initcall(vga_default_init);
> +
> +/*
> + * A driver could be loaded much later than late_initcall, for example
> + * if it's in a module.
> + *
> + * We want to pick that up. However, we want to make sure this does
> + * not interfere with the arbiter - it should only activate if the
> + * arbiter has already had a chance to operate. To ensure this, we set
> + * vga_default_active in the late_initcall: as the vga arbiter is a
> + * subsys initcall, it is guaranteed to fire first.
> + */
> +static void vga_default_enable_hook(struct pci_dev *pdev)
> +{
> + if (!vga_default_active)
> + return;
> +
> + if (vga_default_device())
> + return;
> +
> + vga_default_try_device(pdev);
> +}
> +DECLARE_PCI_FIXUP_CLASS_ENABLE(PCI_ANY_ID, PCI_ANY_ID,
> + PCI_CLASS_DISPLAY_VGA, 8,
> + vga_default_enable_hook)
> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
> index 3cd153c6d271..6612ec7981b6 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -41,7 +41,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/seq_file.h>
> #include <linux/uaccess.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <linux/vga_switcheroo.h>
>
> /**
> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> index 76875f6299b8..74683286f5f8 100644
> --- a/drivers/gpu/vga/vgaarb.c
> +++ b/drivers/gpu/vga/vgaarb.c
> @@ -51,6 +51,7 @@
>
> #include <linux/uaccess.h>
>
> +#include <linux/vga_default.h>
> #include <linux/vgaarb.h>
>
> static void vga_arbiter_notify_clients(void);
> @@ -119,9 +120,6 @@ static int vga_str_to_iostate(char *buf, int str_size, int *io_state)
> return 1;
> }
>
> -/* this is only used a cookie - it should not be dereferenced */
> -static struct pci_dev *vga_default;
> -
> static void vga_arb_device_card_gone(struct pci_dev *pdev);
>
> /* Find somebody in our list */
> @@ -135,39 +133,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)
> return NULL;
> }
>
> -/**
> - * vga_default_device - return the default VGA device, for vgacon
> - *
> - * This can be defined by the platform. The default implementation
> - * is rather dumb and will probably only work properly on single
> - * vga card setups and/or x86 platforms.
> - *
> - * If your VGA default device is not PCI, you'll have to return
> - * NULL here. In this case, I assume it will not conflict with
> - * any PCI card. If this is not true, I'll have to define two archs
> - * hooks for enabling/disabling the VGA default device if that is
> - * possible. This may be a problem with real _ISA_ VGA cards, in
> - * addition to a PCI one. I don't know at this point how to deal
> - * with that card. Can theirs IOs be disabled at all ? If not, then
> - * I suppose it's a matter of having the proper arch hook telling
> - * us about it, so we basically never allow anybody to succeed a
> - * vga_get()...
> - */
> -struct pci_dev *vga_default_device(void)
> -{
> - return vga_default;
> -}
> -EXPORT_SYMBOL_GPL(vga_default_device);
> -
> -void vga_set_default_device(struct pci_dev *pdev)
> -{
> - if (vga_default == pdev)
> - return;
> -
> - pci_dev_put(vga_default);
> - vga_default = pci_dev_get(pdev);
> -}
> -
> static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)
> {
> if (vgadev->irq_set_state)
> @@ -667,7 +632,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)
> /* Deal with VGA default device. Use first enabled one
> * by default if arch doesn't have it's own hook
> */
> - if (vga_default == NULL &&
> + if (vga_default_device() == NULL &&
> ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
> vgaarb_info(&pdev->dev, "setting as boot VGA device\n");
> vga_set_default_device(pdev);
> @@ -704,7 +669,7 @@ static bool vga_arbiter_del_pci_device(struct pci_dev *pdev)
> goto bail;
> }
>
> - if (vga_default == pdev)
> + if (vga_default_device() == pdev)
> vga_set_default_device(NULL);
>
> if (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index 2f3780b50723..c174b427ea2b 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -27,7 +27,7 @@
> #include <linux/security.h>
> #include <linux/pci-aspm.h>
> #include <linux/slab.h>
> -#include <linux/vgaarb.h>
> +#include <linux/vga_default.h>
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> #include "pci.h"
> diff --git a/include/linux/vga_default.h b/include/linux/vga_default.h
> new file mode 100644
> index 000000000000..78df6a2a194c
> --- /dev/null
> +++ b/include/linux/vga_default.h
> @@ -0,0 +1,44 @@
> +/*
> + * vga_default.h: What is the default/boot PCI VGA device?
> + *
> + * (C) Copyright 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + * (C) Copyright 2007 Paulo R. Zanoni <przanoni@gmail.com>
> + * (C) Copyright 2007, 2009 Tiago Vignatti <vignatti@freedesktop.org>
> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens <dja@axtens.net>)
> + *
> + * (License from vgaarb.h)
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#ifndef LINUX_VGA_DEFAULT_H
> +#define LINUX_VGA_DEFAULT_H
> +
> +struct pci_dev;
> +
> +#ifdef CONFIG_VGA_DEFAULT
> +extern struct pci_dev *vga_default_device(void);
> +extern void vga_set_default_device(struct pci_dev *pdev);
> +#else
> +static inline struct pci_dev *vga_default_device(void) { return NULL; };
> +static inline void vga_set_default_device(struct pci_dev *pdev) { };
> +#endif
> +
> +#endif
> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> index ee162e3e879b..953e1955efbe 100644
> --- a/include/linux/vgaarb.h
> +++ b/include/linux/vgaarb.h
> @@ -42,12 +42,6 @@
> #define VGA_RSRC_NORMAL_IO 0x04
> #define VGA_RSRC_NORMAL_MEM 0x08
>
> -/* Passing that instead of a pci_dev to use the system "default"
> - * device, that is the one used by vgacon. Archs will probably
> - * have to provide their own vga_default_device();
> - */
> -#define VGA_DEFAULT_DEVICE (NULL)
> -
> struct pci_dev;
>
> /* For use by clients */
> @@ -122,14 +116,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int rsrc);
> #endif
>
>
> -#ifdef CONFIG_VGA_ARB
> -extern struct pci_dev *vga_default_device(void);
> -extern void vga_set_default_device(struct pci_dev *pdev);
> -#else
> -static inline struct pci_dev *vga_default_device(void) { return NULL; };
> -static inline void vga_set_default_device(struct pci_dev *pdev) { };
> -#endif
> -
> /*
> * Architectures should define this if they have several
> * independent PCI domains that can afford concurrent VGA
> --
> 2.11.0
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-21 10:53 ` Lorenzo Pieralisi
@ 2017-08-22 22:19 ` Bjorn Helgaas
2017-08-23 13:48 ` Ard Biesheuvel
0 siblings, 1 reply; 13+ messages in thread
From: Bjorn Helgaas @ 2017-08-22 22:19 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Daniel Axtens, catalin.marinas, gabriele.paoloni, airlied,
linux-pci, will.deacon, dri-devel, z.liuxinliang, bhelgaas,
alex.williamson, lukas, benh, zourongrong, daniel.vetter,
linuxppc-dev, linux-arm-kernel
On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> > A system without PCI legacy resources (e.g. ARM64) may find that no
> > default/boot VGA device has been marked, because the VGA arbiter
> > checks for legacy resource decoding before marking a card as default.
>
> I do not understand this paragraph, in particular:
>
> - "A system without PCI legacy resources (e.g. ARM64)". What does this
> mean ? I take this as "ARM64 does not support IO space"; if a PCI host
> bridge supports IO space, there is nothing from an architectural
> point of view that prevents an MMIO based IO space implementation to
> work on ARM64. It is PCI bridge specific, not arch specific.
This reference to ARM64 is the same thing I stumbled over. Maybe it
could be written along the lines of:
The VGA arbiter selects a default VGA device that is enabled and
reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io
0x3b0-0x3bb, io 0x3c0-0x3df, etc).
If there is no such device, e.g., because there's no enabled VGA
device, the host bridge doesn't support access to those legacy
resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
platform may select an arbitrary device by calling
vga_set_default_device().
Then I think this patch changes the previous behavior by allowing the
arbiter to select a device that is enabled and has a driver but may
not be reachable via the legacy VGA resources.
I don't know what all the consequences of that would be, but it does
muddy the VGA arbiter waters a bit. AIUI, the main reason for the
arbiter is to allow multiple legacy VGA devices by manipulating bridge
VGA Enable bits so only one receives the legacy resources at a time.
These devices that do not need the legacy resources don't need that
special treatment because they don't care about the bridge VGA Enable
bits and several can coexist in the system with no need for VGA
arbitration.
I guess the powerpc fixup_vga() already selects a device that doesn't
need the VGA resources, so we already have that situation.
Bjorn
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-22 22:19 ` Bjorn Helgaas
@ 2017-08-23 13:48 ` Ard Biesheuvel
2017-08-23 13:57 ` Bjorn Helgaas
0 siblings, 1 reply; 13+ messages in thread
From: Ard Biesheuvel @ 2017-08-23 13:48 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Lorenzo Pieralisi, Benjamin Herrenschmidt, Gabriele Paoloni,
David Airlie, Catalin Marinas, Will Deacon, dri-devel,
Liuxinliang (Matthew Liu), Zou Rongrong, Alex Williamson,
Lukas Wunner, linux-pci, Bjorn Helgaas, daniel.vetter,
linuxppc-dev, linux-arm-kernel@lists.infradead.org, Daniel Axtens
On 22 August 2017 at 23:19, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
>> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
>> > A system without PCI legacy resources (e.g. ARM64) may find that no
>> > default/boot VGA device has been marked, because the VGA arbiter
>> > checks for legacy resource decoding before marking a card as default.
>>
>> I do not understand this paragraph, in particular:
>>
>> - "A system without PCI legacy resources (e.g. ARM64)". What does this
>> mean ? I take this as "ARM64 does not support IO space"; if a PCI host
>> bridge supports IO space, there is nothing from an architectural
>> point of view that prevents an MMIO based IO space implementation to
>> work on ARM64. It is PCI bridge specific, not arch specific.
>
> This reference to ARM64 is the same thing I stumbled over. Maybe it
> could be written along the lines of:
>
> The VGA arbiter selects a default VGA device that is enabled and
> reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io
> 0x3b0-0x3bb, io 0x3c0-0x3df, etc).
>
> If there is no such device, e.g., because there's no enabled VGA
> device, the host bridge doesn't support access to those legacy
> resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
> platform may select an arbitrary device by calling
> vga_set_default_device().
>
> Then I think this patch changes the previous behavior by allowing the
> arbiter to select a device that is enabled and has a driver but may
> not be reachable via the legacy VGA resources.
>
> I don't know what all the consequences of that would be, but it does
> muddy the VGA arbiter waters a bit. AIUI, the main reason for the
> arbiter is to allow multiple legacy VGA devices by manipulating bridge
> VGA Enable bits so only one receives the legacy resources at a time.
>
> These devices that do not need the legacy resources don't need that
> special treatment because they don't care about the bridge VGA Enable
> bits and several can coexist in the system with no need for VGA
> arbitration.
>
> I guess the powerpc fixup_vga() already selects a device that doesn't
> need the VGA resources, so we already have that situation.
>
Perhaps it is unclear that the whole point of tinkering with the VGA
arbiter is that X may refuse to use a GFX card if it is not tagged as
the default VGA device by the arbiter. I have suggested before that
fixing X may be more appropriate in this case, given that ownership of
the legacy VGA resources may not correlate at all with being the
primary display device on non-x86 architectures.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-23 13:48 ` Ard Biesheuvel
@ 2017-08-23 13:57 ` Bjorn Helgaas
2017-08-24 0:57 ` Dave Airlie
0 siblings, 1 reply; 13+ messages in thread
From: Bjorn Helgaas @ 2017-08-23 13:57 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Lorenzo Pieralisi, Benjamin Herrenschmidt, Gabriele Paoloni,
David Airlie, Catalin Marinas, Will Deacon, dri-devel,
Liuxinliang (Matthew Liu), Zou Rongrong, Alex Williamson,
Lukas Wunner, linux-pci, Bjorn Helgaas, daniel.vetter,
linuxppc-dev, linux-arm-kernel@lists.infradead.org, Daniel Axtens
On Wed, Aug 23, 2017 at 02:48:42PM +0100, Ard Biesheuvel wrote:
> On 22 August 2017 at 23:19, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:
> >> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:
> >> > A system without PCI legacy resources (e.g. ARM64) may find that no
> >> > default/boot VGA device has been marked, because the VGA arbiter
> >> > checks for legacy resource decoding before marking a card as default.
> >>
> >> I do not understand this paragraph, in particular:
> >>
> >> - "A system without PCI legacy resources (e.g. ARM64)". What does this
> >> mean ? I take this as "ARM64 does not support IO space"; if a PCI host
> >> bridge supports IO space, there is nothing from an architectural
> >> point of view that prevents an MMIO based IO space implementation to
> >> work on ARM64. It is PCI bridge specific, not arch specific.
> >
> > This reference to ARM64 is the same thing I stumbled over. Maybe it
> > could be written along the lines of:
> >
> > The VGA arbiter selects a default VGA device that is enabled and
> > reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io
> > 0x3b0-0x3bb, io 0x3c0-0x3df, etc).
> >
> > If there is no such device, e.g., because there's no enabled VGA
> > device, the host bridge doesn't support access to those legacy
> > resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
> > platform may select an arbitrary device by calling
> > vga_set_default_device().
> >
> > Then I think this patch changes the previous behavior by allowing the
> > arbiter to select a device that is enabled and has a driver but may
> > not be reachable via the legacy VGA resources.
> >
> > I don't know what all the consequences of that would be, but it does
> > muddy the VGA arbiter waters a bit. AIUI, the main reason for the
> > arbiter is to allow multiple legacy VGA devices by manipulating bridge
> > VGA Enable bits so only one receives the legacy resources at a time.
> >
> > These devices that do not need the legacy resources don't need that
> > special treatment because they don't care about the bridge VGA Enable
> > bits and several can coexist in the system with no need for VGA
> > arbitration.
> >
> > I guess the powerpc fixup_vga() already selects a device that doesn't
> > need the VGA resources, so we already have that situation.
> >
>
> Perhaps it is unclear that the whole point of tinkering with the VGA
> arbiter is that X may refuse to use a GFX card if it is not tagged as
> the default VGA device by the arbiter. I have suggested before that
> fixing X may be more appropriate in this case, given that ownership of
> the legacy VGA resources may not correlate at all with being the
> primary display device on non-x86 architectures.
Yeah, maybe it's time to disconnect the "default display device" idea
from the VGA arbiter. I have no idea what (if any) dependencies X has
on the legacy VGA resources. I assume X works fine on power, where it
sounds like those resources are rarely or never available.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-23 13:57 ` Bjorn Helgaas
@ 2017-08-24 0:57 ` Dave Airlie
2017-08-24 9:38 ` Ard Biesheuvel
2017-08-24 13:57 ` Bjorn Helgaas
0 siblings, 2 replies; 13+ messages in thread
From: Dave Airlie @ 2017-08-24 0:57 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Ard Biesheuvel, Lorenzo Pieralisi, Gabriele Paoloni, Will Deacon,
dri-devel, linux-pci, Liuxinliang (Matthew Liu), Bjorn Helgaas,
Alex Williamson, Catalin Marinas, Zou Rongrong, Vetter, Daniel,
linuxppc-dev, linux-arm-kernel@lists.infradead.org, Daniel Axtens
> Yeah, maybe it's time to disconnect the "default display device" idea
> from the VGA arbiter. I have no idea what (if any) dependencies X has
> on the legacy VGA resources. I assume X works fine on power, where it
> sounds like those resources are rarely or never available.
The question on non-x86 archs, is what is the correct device to default to.
On x86 we use the legacy VGA resources as a pointer, as this is the device
the BIOS appeared on at boot so hopefully should be one you can see stuff on.
On non-x86 I've no idea how to decide if there are multiple devices, maybe the
firmware needs to tag something for the kernel if there are. Otherwise
you'd just
be picking something in probe order.
I think the idea of these patches is to separate default display
device from the arbiter.
X uses the arbiter on x86 if required (it's horrible, and it's rare we
have to nowadays),
but for finding the default device it justs uses the sysfs boot_vga flag.
Dave.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-24 0:57 ` Dave Airlie
@ 2017-08-24 9:38 ` Ard Biesheuvel
2017-08-24 13:57 ` Bjorn Helgaas
1 sibling, 0 replies; 13+ messages in thread
From: Ard Biesheuvel @ 2017-08-24 9:38 UTC (permalink / raw)
To: Dave Airlie
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Gabriele Paoloni, Will Deacon,
dri-devel, linux-pci, Liuxinliang (Matthew Liu), Bjorn Helgaas,
Alex Williamson, Catalin Marinas, Zou Rongrong, Vetter, Daniel,
linuxppc-dev, linux-arm-kernel@lists.infradead.org, Daniel Axtens
On 24 August 2017 at 01:57, Dave Airlie <airlied@gmail.com> wrote:
>> Yeah, maybe it's time to disconnect the "default display device" idea
>> from the VGA arbiter. I have no idea what (if any) dependencies X has
>> on the legacy VGA resources. I assume X works fine on power, where it
>> sounds like those resources are rarely or never available.
>
> The question on non-x86 archs, is what is the correct device to default to.
>
> On x86 we use the legacy VGA resources as a pointer, as this is the device
> the BIOS appeared on at boot so hopefully should be one you can see stuff on.
>
> On non-x86 I've no idea how to decide if there are multiple devices, maybe the
> firmware needs to tag something for the kernel if there are. Otherwise
> you'd just
> be picking something in probe order.
>
> I think the idea of these patches is to separate default display
> device from the arbiter.
>
> X uses the arbiter on x86 if required (it's horrible, and it's rare we
> have to nowadays),
> but for finding the default device it justs uses the sysfs boot_vga flag.
>
Part of the problem is that X refuses to start if there is only one
display device to begin with in case it hasn't taken ownership of the
VGA legacy resources.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 1/1] Split VGA default device handler out of VGA arbiter
2017-08-24 0:57 ` Dave Airlie
2017-08-24 9:38 ` Ard Biesheuvel
@ 2017-08-24 13:57 ` Bjorn Helgaas
1 sibling, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2017-08-24 13:57 UTC (permalink / raw)
To: Dave Airlie
Cc: Ard Biesheuvel, Lorenzo Pieralisi, Gabriele Paoloni, Will Deacon,
dri-devel, linux-pci, Liuxinliang (Matthew Liu), Bjorn Helgaas,
Alex Williamson, Catalin Marinas, Zou Rongrong, Vetter, Daniel,
linuxppc-dev, linux-arm-kernel@lists.infradead.org, Daniel Axtens
On Thu, Aug 24, 2017 at 10:57:26AM +1000, Dave Airlie wrote:
> > Yeah, maybe it's time to disconnect the "default display device" idea
> > from the VGA arbiter. I have no idea what (if any) dependencies X has
> > on the legacy VGA resources. I assume X works fine on power, where it
> > sounds like those resources are rarely or never available.
>
> The question on non-x86 archs, is what is the correct device to default to.
>
> On x86 we use the legacy VGA resources as a pointer, as this is the device
> the BIOS appeared on at boot so hopefully should be one you can see stuff on.
>
> On non-x86 I've no idea how to decide if there are multiple devices, maybe the
> firmware needs to tag something for the kernel if there are. Otherwise
> you'd just
> be picking something in probe order.
>
> I think the idea of these patches is to separate default display
> device from the arbiter.
>
> X uses the arbiter on x86 if required (it's horrible, and it's rare we
> have to nowadays),
> but for finding the default device it justs uses the sysfs boot_vga flag.
The sysfs boot_vga thing comes from PCI. The name suggests that it's
a VGA device and can use the legacy VGA resources.
If we want to indicate a general default display device that need not
be "VGA", it'd be really nice if we could pick a name that did not
include "vga".
Even if we could only do it inside the kernel, I think it would reduce
confusion if we could separate out the "VGA"-specific stuff like the
arbiter and names like "vga_set_default_device()" so that systems with
a non-legacy VGA default display device didn't have to use "VGA"
interfaces that don't make sense for them.
Bjorn
^ permalink raw reply [flat|nested] 13+ messages in thread