[{"id":1750697,"web_url":"http://patchwork.ozlabs.org/comment/1750697/","msgid":"<20170818072328.jtvtusdyuzchdm7g@phenom.ffwll.local>","list_archive_url":null,"date":"2017-08-18T07:38:35","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":1959,"url":"http://patchwork.ozlabs.org/api/people/1959/","name":"Daniel Vetter","email":"daniel@ffwll.ch"},"content":"On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:\n> A system without PCI legacy resources (e.g. ARM64) may find that no\n> default/boot VGA device has been marked, because the VGA arbiter\n> checks for legacy resource decoding before marking a card as default.\n> \n> Split the small bit of code that does default VGA handling out from\n> the arbiter. Add a Kconfig option to allow the kernel to be built\n> with just the default handling, or the arbiter and default handling.\n> \n> Add handling for devices that should be marked as default but aren't\n> handled by the vga arbiter by adding a late initcall and a class\n> enable hook. If there is no default from vgaarb then the first card\n> that is enabled, has a driver bound, and can decode memory or I/O\n> will be marked as default.\n> \n> Signed-off-by: Daniel Axtens \n\nLooks reasonable, but I have no clue at all about this. Can you pls get\nsome proper review from pci/platform folks (ppc would be good to)? I can\napply to drm-misc once that's done.\n\nJust documentation comments below.\n\nThanks, Daniel\n> \n> ---\n> \n> v2: Tested on:\n> - x86_64 laptop\n> - arm64 D05 board with hibmc card\n> - qemu powerpc with tcg and bochs std-vga\n> \n> I know this adds another config option and that's a bit sad, but\n> we can't include it unconditionally as it depends on PCI.\n> Suggestions welcome.\n> ---\n> arch/ia64/pci/fixup.c | 2 +-\n> arch/powerpc/kernel/pci-common.c | 2 +-\n> arch/x86/pci/fixup.c | 2 +-\n> arch/x86/video/fbdev.c | 2 +-\n> drivers/gpu/vga/Kconfig | 12 +++\n> drivers/gpu/vga/Makefile | 1 +\n> drivers/gpu/vga/vga_default.c | 159 +++++++++++++++++++++++++++++++++++++++\n> drivers/gpu/vga/vga_switcheroo.c | 2 +-\n> drivers/gpu/vga/vgaarb.c | 41 +---------\n> drivers/pci/pci-sysfs.c | 2 +-\n> include/linux/vga_default.h | 44 +++++++++++\n> include/linux/vgaarb.h | 14 ----\n> 12 files changed, 225 insertions(+), 58 deletions(-)\n> create mode 100644 drivers/gpu/vga/vga_default.c\n> create mode 100644 include/linux/vga_default.h\n> \n> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c\n> index 41caa99add51..b35d1cf4501a 100644\n> --- a/arch/ia64/pci/fixup.c\n> +++ b/arch/ia64/pci/fixup.c\n> @@ -5,7 +5,7 @@\n> \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> \n> #include \n> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c\n> index 341a7469cab8..4fd890a51d18 100644\n> --- a/arch/powerpc/kernel/pci-common.c\n> +++ b/arch/powerpc/kernel/pci-common.c\n> @@ -31,7 +31,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> \n> #include \n> #include \n> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c\n> index 11e407489db0..b1254bc09a45 100644\n> --- a/arch/x86/pci/fixup.c\n> +++ b/arch/x86/pci/fixup.c\n> @@ -5,7 +5,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> #include \n> \n> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c\n> index 9fd24846d094..62cfa74ea86e 100644\n> --- a/arch/x86/video/fbdev.c\n> +++ b/arch/x86/video/fbdev.c\n> @@ -9,7 +9,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> \n> int fb_is_primary_device(struct fb_info *info)\n> {\n> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig\n> index 29437eabe095..81d4105aecf6 100644\n> --- a/drivers/gpu/vga/Kconfig\n> +++ b/drivers/gpu/vga/Kconfig\n> @@ -1,3 +1,14 @@\n> +config VGA_DEFAULT\n> +\tbool \"VGA Default Device Support\" if EXPERT\n> +\tdefault y\n> +\tdepends on PCI\n> +\thelp\n> +\t Some programs find it helpful to know what VGA device is the default.\n> +\t On platforms like x86 this means the device used by the BIOS to show\n> +\t early boot messages. On other platforms this may be an arbitrary PCI\n> +\t graphics card. Select this to have a default device recorded within\n> +\t the kernel and exposed to userspace through sysfs.\n> +\n> config VGA_ARB\n> \tbool \"VGA Arbitration\" if EXPERT\n> \tdefault y\n> @@ -22,6 +33,7 @@ config VGA_SWITCHEROO\n> \tdepends on X86\n> \tdepends on ACPI\n> \tselect VGA_ARB\n> +\tselect VGA_DEFAULT\n> \thelp\n> \t Many laptops released in 2008/9/10 have two GPUs with a multiplexer\n> \t to switch between them. This adds support for dynamic switching when\n> diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile\n> index 14ca30b75d0a..1e30f90d40fb 100644\n> --- a/drivers/gpu/vga/Makefile\n> +++ b/drivers/gpu/vga/Makefile\n> @@ -1,2 +1,3 @@\n> obj-$(CONFIG_VGA_ARB) += vgaarb.o\n> +obj-$(CONFIG_VGA_DEFAULT) += vga_default.o\n> obj-$(CONFIG_VGA_SWITCHEROO) += vga_switcheroo.o\n> diff --git a/drivers/gpu/vga/vga_default.c b/drivers/gpu/vga/vga_default.c\n> new file mode 100644\n> index 000000000000..f6fcb0eb1507\n> --- /dev/null\n> +++ b/drivers/gpu/vga/vga_default.c\n> @@ -0,0 +1,159 @@\n> +/*\n> + * vga_default.c: What is the default/boot PCI VGA device?\n> + *\n> + * (C) Copyright 2005 Benjamin Herrenschmidt \n> + * (C) Copyright 2007 Paulo R. Zanoni \n> + * (C) Copyright 2007, 2009 Tiago Vignatti \n> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens )\n> + *\n> + * (License from vgaarb.c)\n> + * Permission is hereby granted, free of charge, to any person obtaining a\n> + * copy of this software and associated documentation files (the \"Software\"),\n> + * to deal in the Software without restriction, including without limitation\n> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,\n> + * and/or sell copies of the Software, and to permit persons to whom the\n> + * Software is furnished to do so, subject to the following conditions:\n> + *\n> + * The above copyright notice and this permission notice (including the next\n> + * paragraph) shall be included in all copies or substantial portions of the\n> + * Software.\n> + *\n> + * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL\n> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\n> + * DEALINGS\n> + * IN THE SOFTWARE.\n> + */\n> +\n> +/*\n\nPlease make this into a DOC: introduction section.\n\n> + * What device should a graphics system draw to? In order of priority:\n> + *\n> + * 1) Any devices configured specifically by the user (think\n> + * xorg.conf).\n> + *\n> + * 2) If the platform has a concept of a boot device for early boot\n> + * messages (think BIOS displays on x86), that device.\n> + *\n> + * 3) If the platform does not have the concept of a boot device,\n> + * then we still want to pick something. For now, pick the first\n> + * PCI VGA device with a driver bound and with memory or I/O\n> + * control on.\n> + */\n> +\n> +#include \n> +#include \n> +#include \n> +#include \n> +\n> +#include \n> +\n> +static struct pci_dev *vga_default;\n> +/*\n> + * only go active after the late initcall so as not to interfere with\n> + * the arbiter\n> + */\n> +static bool vga_default_active = false;\n> +\n> +/**\n> + * vga_default_device - return the default VGA device\n\nAll the nice kerneldoc, but not pulled into Documentation/gpu. Can you pls\nfix that and make sure the resulting docs look pretty and have all the\nlinks still working?\n\n> + *\n> + * This can be defined by the platform. The default implementation\n> + * is rather dumb and will probably only work properly on single\n> + * vga card setups and/or x86 platforms.\n> + *\n> + * If your VGA default device is not PCI, you'll have to return\n> + * NULL here. In this case, I assume it will not conflict with\n> + * any PCI card. If this is not true, I'll have to define two archs\n> + * hooks for enabling/disabling the VGA default device if that is\n> + * possible. This may be a problem with real _ISA_ VGA cards, in\n> + * addition to a PCI one. I don't know at this point how to deal\n> + * with that card. Can theirs IOs be disabled at all ? If not, then\n> + * I suppose it's a matter of having the proper arch hook telling\n> + * us about it, so we basically never allow anybody to succeed a\n> + * vga_get()...\n\nI'd like reviewers to convert this lore into a solid statement of fact :-)\n\n> + */\n> +\n> +struct pci_dev *vga_default_device(void)\n> +{\n> +\treturn vga_default;\n> +}\n> +EXPORT_SYMBOL_GPL(vga_default_device);\n> +\n> +void vga_set_default_device(struct pci_dev *pdev)\n> +{\n> +\tif (vga_default == pdev)\n> +\t\treturn;\n> +\n> +\tpci_dev_put(vga_default);\n> +\tvga_default = pci_dev_get(pdev);\n> +}\n> +\n> +static bool vga_default_try_device(struct pci_dev *pdev)\n> +{\n> +\tu16 cmd;\n> +\n> +\t/* Only deal with VGA class devices */\n> +\tif ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)\n> +\t\treturn false;\n> +\n> +\t/* Only deal with devices with drivers bound */\n> +\tif (!pdev->driver)\n> +\t\treturn false;\n> +\n> +\t/* Require I/O or memory control */\n> +\tpci_read_config_word(pdev, PCI_COMMAND, &cmd);\n> +\tif (!(cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)))\n> +\t\treturn false;\n> +\n> +\tdev_info(&pdev->dev, \"vga_default: setting as default device\\n\");\n> +\tvga_set_default_device(pdev);\n> +\treturn true;\n> +}\n> +\n> +static int __init vga_default_init(void)\n> +{\n> +\tstruct pci_dev *pdev;\n> +\n> +\tvga_default_active = true;\n> +\n> +\tif (vga_default_device())\n> +\t\treturn 0;\n> +\n> +\tpdev = NULL;\n> +\twhile ((pdev =\n> +\t\tpci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,\n> +\t\t\t PCI_ANY_ID, pdev)) != NULL) {\n> +\t\tif (vga_default_try_device(pdev))\n> +\t\t\treturn 0;\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +late_initcall(vga_default_init);\n> +\n> +/*\n> + * A driver could be loaded much later than late_initcall, for example\n> + * if it's in a module.\n> + *\n> + * We want to pick that up. However, we want to make sure this does\n> + * not interfere with the arbiter - it should only activate if the\n> + * arbiter has already had a chance to operate. To ensure this, we set\n> + * vga_default_active in the late_initcall: as the vga arbiter is a\n> + * subsys initcall, it is guaranteed to fire first.\n> + */\n> +static void vga_default_enable_hook(struct pci_dev *pdev)\n> +{\n> + if (!vga_default_active)\n> +\t return;\n> +\n> + if (vga_default_device())\n> + return;\n> +\n> + vga_default_try_device(pdev);\n> +}\n> +DECLARE_PCI_FIXUP_CLASS_ENABLE(PCI_ANY_ID, PCI_ANY_ID,\n> +\t\t\t PCI_CLASS_DISPLAY_VGA, 8,\n> +\t\t\t vga_default_enable_hook)\n> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c\n> index 3cd153c6d271..6612ec7981b6 100644\n> --- a/drivers/gpu/vga/vga_switcheroo.c\n> +++ b/drivers/gpu/vga/vga_switcheroo.c\n> @@ -41,7 +41,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> \n> /**\n> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c\n> index 76875f6299b8..74683286f5f8 100644\n> --- a/drivers/gpu/vga/vgaarb.c\n> +++ b/drivers/gpu/vga/vgaarb.c\n> @@ -51,6 +51,7 @@\n> \n> #include \n> \n> +#include \n> #include \n> \n> static void vga_arbiter_notify_clients(void);\n> @@ -119,9 +120,6 @@ static int vga_str_to_iostate(char *buf, int str_size, int *io_state)\n> \treturn 1;\n> }\n> \n> -/* this is only used a cookie - it should not be dereferenced */\n> -static struct pci_dev *vga_default;\n> -\n> static void vga_arb_device_card_gone(struct pci_dev *pdev);\n> \n> /* Find somebody in our list */\n> @@ -135,39 +133,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)\n> \treturn NULL;\n> }\n> \n> -/**\n> - * vga_default_device - return the default VGA device, for vgacon\n> - *\n> - * This can be defined by the platform. The default implementation\n> - * is rather dumb and will probably only work properly on single\n> - * vga card setups and/or x86 platforms.\n> - *\n> - * If your VGA default device is not PCI, you'll have to return\n> - * NULL here. In this case, I assume it will not conflict with\n> - * any PCI card. If this is not true, I'll have to define two archs\n> - * hooks for enabling/disabling the VGA default device if that is\n> - * possible. This may be a problem with real _ISA_ VGA cards, in\n> - * addition to a PCI one. I don't know at this point how to deal\n> - * with that card. Can theirs IOs be disabled at all ? If not, then\n> - * I suppose it's a matter of having the proper arch hook telling\n> - * us about it, so we basically never allow anybody to succeed a\n> - * vga_get()...\n> - */\n> -struct pci_dev *vga_default_device(void)\n> -{\n> -\treturn vga_default;\n> -}\n> -EXPORT_SYMBOL_GPL(vga_default_device);\n> -\n> -void vga_set_default_device(struct pci_dev *pdev)\n> -{\n> -\tif (vga_default == pdev)\n> -\t\treturn;\n> -\n> -\tpci_dev_put(vga_default);\n> -\tvga_default = pci_dev_get(pdev);\n> -}\n> -\n> static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)\n> {\n> \tif (vgadev->irq_set_state)\n> @@ -667,7 +632,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)\n> \t/* Deal with VGA default device. Use first enabled one\n> \t * by default if arch doesn't have it's own hook\n> \t */\n> -\tif (vga_default == NULL &&\n> +\tif (vga_default_device() == NULL &&\n> \t ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {\n> \t\tvgaarb_info(&pdev->dev, \"setting as boot VGA device\\n\");\n> \t\tvga_set_default_device(pdev);\n> @@ -704,7 +669,7 @@ static bool vga_arbiter_del_pci_device(struct pci_dev *pdev)\n> \t\tgoto bail;\n> \t}\n> \n> -\tif (vga_default == pdev)\n> +\tif (vga_default_device() == pdev)\n> \t\tvga_set_default_device(NULL);\n> \n> \tif (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))\n> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c\n> index 2f3780b50723..c174b427ea2b 100644\n> --- a/drivers/pci/pci-sysfs.c\n> +++ b/drivers/pci/pci-sysfs.c\n> @@ -27,7 +27,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> #include \n> #include \"pci.h\"\n> diff --git a/include/linux/vga_default.h b/include/linux/vga_default.h\n> new file mode 100644\n> index 000000000000..78df6a2a194c\n> --- /dev/null\n> +++ b/include/linux/vga_default.h\n> @@ -0,0 +1,44 @@\n> +/*\n> + * vga_default.h: What is the default/boot PCI VGA device?\n> + *\n> + * (C) Copyright 2005 Benjamin Herrenschmidt \n> + * (C) Copyright 2007 Paulo R. Zanoni \n> + * (C) Copyright 2007, 2009 Tiago Vignatti \n> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens )\n> + *\n> + * (License from vgaarb.h)\n> + * Permission is hereby granted, free of charge, to any person obtaining a\n> + * copy of this software and associated documentation files (the \"Software\"),\n> + * to deal in the Software without restriction, including without limitation\n> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,\n> + * and/or sell copies of the Software, and to permit persons to whom the\n> + * Software is furnished to do so, subject to the following conditions:\n> + *\n> + * The above copyright notice and this permission notice (including the next\n> + * paragraph) shall be included in all copies or substantial portions of the\n> + * Software.\n> + *\n> + * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL\n> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\n> + * DEALINGS\n> + * IN THE SOFTWARE.\n> + */\n> +\n> +#ifndef LINUX_VGA_DEFAULT_H\n> +#define LINUX_VGA_DEFAULT_H\n> +\n> +struct pci_dev;\n> +\n> +#ifdef CONFIG_VGA_DEFAULT\n> +extern struct pci_dev *vga_default_device(void);\n> +extern void vga_set_default_device(struct pci_dev *pdev);\n> +#else\n> +static inline struct pci_dev *vga_default_device(void) { return NULL; };\n> +static inline void vga_set_default_device(struct pci_dev *pdev) { };\n> +#endif\n> +\n> +#endif\n> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h\n> index ee162e3e879b..953e1955efbe 100644\n> --- a/include/linux/vgaarb.h\n> +++ b/include/linux/vgaarb.h\n> @@ -42,12 +42,6 @@\n> #define VGA_RSRC_NORMAL_IO 0x04\n> #define VGA_RSRC_NORMAL_MEM 0x08\n> \n> -/* Passing that instead of a pci_dev to use the system \"default\"\n> - * device, that is the one used by vgacon. Archs will probably\n> - * have to provide their own vga_default_device();\n> - */\n> -#define VGA_DEFAULT_DEVICE (NULL)\n> -\n> struct pci_dev;\n> \n> /* For use by clients */\n> @@ -122,14 +116,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int rsrc);\n> #endif\n> \n> \n> -#ifdef CONFIG_VGA_ARB\n> -extern struct pci_dev *vga_default_device(void);\n> -extern void vga_set_default_device(struct pci_dev *pdev);\n> -#else\n> -static inline struct pci_dev *vga_default_device(void) { return NULL; };\n> -static inline void vga_set_default_device(struct pci_dev *pdev) { };\n> -#endif\n> -\n> /*\n> * Architectures should define this if they have several\n> * independent PCI domains that can afford concurrent VGA\n> -- \n> 2.11.0\n> \n> _______________________________________________\n> dri-devel mailing list\n> dri-devel@lists.freedesktop.org\n> https://lists.freedesktop.org/mailman/listinfo/dri-devel","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (1024-bit key;\n\tunprotected) header.d=ffwll.ch header.i=@ffwll.ch header.b=\"d8/V0aBD\";\n\tdkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xYZhR0QGzz9s8w\n\tfor ;\n\tFri, 18 Aug 2017 17:38:47 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750846AbdHRHip (ORCPT );\n\tFri, 18 Aug 2017 03:38:45 -0400","from mail-wr0-f193.google.com ([209.85.128.193]:35959 \"EHLO\n\tmail-wr0-f193.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750709AbdHRHio (ORCPT\n\t); Fri, 18 Aug 2017 03:38:44 -0400","by mail-wr0-f193.google.com with SMTP id f8so3697260wrf.3\n\tfor ; Fri, 18 Aug 2017 00:38:43 -0700 (PDT)","from phenom.ffwll.local ([2a02:168:56e6:0:e4bc:76a0:8042:669e])\n\tby smtp.gmail.com with ESMTPSA id\n\ta33sm2949548edd.67.2017.08.18.00.38.40\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tFri, 18 Aug 2017 00:38:41 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google;\n\th=sender:date:from:to:cc:subject:message-id:references:mime-version\n\t:content-disposition:in-reply-to:user-agent;\n\tbh=pPEWr6+Ly0z0kC1MYYNTTig1QT++6tfsrGF9YWdAdr8=;\n\tb=d8/V0aBDQoimuM1YVcxz1WgsdWiagEq7XV/WlflhmmTRtjkKy9k6XRFoGez5hf6XVn\n\tcPL3FXW/Z6U8BLtGiKJjMa+5Q3vpT35E02mjiCOI9LkmitE7/CkSEaVrXiQfBjYO4ezq\n\thQ/rpcKiFVdXBqO8k0vFQGhiW7p+KSzxXUZOs=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:sender:date:from:to:cc:subject:message-id\n\t:references:mime-version:content-disposition:in-reply-to:user-agent; \n\tbh=pPEWr6+Ly0z0kC1MYYNTTig1QT++6tfsrGF9YWdAdr8=;\n\tb=lUsj7tTfHC/HcqTE3m28w+iB69jh/G22Qyq6s3RPKcDn6Ge4feTd8ORjgWgrSd93Jz\n\tr09/84eGThAQj9KXi4b9luiA2JnWESdMxgoSBqxlSyHG53+5678OJ5I4bvRuqQOGajNr\n\taF6NzMOg0sAt+8xsFrv3WdlPfEGWkBvkA15JETxStJ0TcbmwvFe/21Avp3pN8B36jKns\n\tsyfFtn/OvUUXCYsIn7koV18SPUz/0qE93iDgwjeRsET7TJ4FuNH9nHQ+5u9n77GgcM8e\n\tbhOy5BR7v8rceCzC9+XzJJwWGEVYn9VNzLM56M4Bh95jXtOx0YluqSgpLIgDsv/lUCdK\n\tJUFA==","X-Gm-Message-State":"AHYfb5jBZAXT2PHkyHS9NR7AxrBa2I9OeolUDIhsBY4+MpAKpOqb5TBm\n\tlhHFnDAQdzOuzZVV","X-Received":"by 10.80.208.217 with SMTP id g25mr3942108edf.229.1503041922784; \n\tFri, 18 Aug 2017 00:38:42 -0700 (PDT)","Date":"Fri, 18 Aug 2017 09:38:35 +0200","From":"Daniel Vetter ","To":"Daniel Axtens ","Cc":"linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-arm-kernel@lists.infradead.org, gabriele.paoloni@huawei.com,\n\twill.deacon@arm.com, dri-devel@lists.freedesktop.org,\n\tz.liuxinliang@hisilicon.com, bhelgaas@google.com,\n\talex.williamson@redhat.com, catalin.marinas@arm.com,\n\tzourongrong@gmail.com, daniel.vetter@intel.com","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170818072328.jtvtusdyuzchdm7g@phenom.ffwll.local>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170817113028.16853-2-dja@axtens.net>","X-Operating-System":"Linux phenom 4.11.0-2-amd64 ","User-Agent":"NeoMutt/20170609 (1.8.3)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1751887,"web_url":"http://patchwork.ozlabs.org/comment/1751887/","msgid":"<20170819154753.GQ28977@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-19T15:47:53","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:\n> A system without PCI legacy resources (e.g. ARM64)\n\nCan you be a little more specific about what you mean by \"a system\nwithout PCI legacy resources\"? I'm not sure what the connection with\nARM64 as an architecture is.\n\nMy understanding is that \"legacy resources\" are addresses that are\nhard-wired into a device and not discoverable or configurable via a\nBAR [1]. For example,\n\n VGA devices (see [2])\n mem 0xa0000-0xbffff (frame buffer)\n io 0x3b0-0x3bb (plus ISA aliases)\n io 0x3c0-0x3df (plus ISA aliases)\n\n IDE devices in compatibility mode (see [3])\n io 0x170-0x177 (secondary command)\n io 0x1f0-0x1f7 (primary command)\n io 0x376 (secondary control)\n io 0x3f6 (primary control)\n\nThe meaning of these resources in the PCI/PCIe domain is defined by\nthe PCI specs, not the platform arch specs.\n\nSo if ARM64 doesn't have these PCI legacy resources, does that mean an\nARM64 host bridge cannot generate these legacy addresses on PCI? That\nis, there's no host bridge window that maps to those PCI addresses?\nThat seems like a curious restriction on host bridges, but I guess it\nwould be possible.\n\nI think you're fixing an issue related to the HiSilicon [19e5:1610]\nPCI-to-PCI bridge, which doesn't support VGA Enable (I first thought\nthe bridge was broken, but per [4], I think it is legal). With VGA\nEnable not being supported, a downstream VGA device will not work if\nit depends on the legacy VGA resources. But this is merely related to\none PCI-to-PCI bridge in the system; it's not a question of the system\nas a whole or the CPU architecture.\n\nMaybe I'm reading too much into the \"ARM64 has no PCI legacy\nresources\" idea and the point here is simply that the VGA arbiter\npreviously would not mark a VGA device as default if it found that the\nlegacy resources are not routed to it, e.g., because an upstream\nbridge doesn't support VGA ENABLE?\n\nThat's \"safe\" because if the arbiter selects a default VGA device that\ndoes not receive accesses to the legacy VGA resources, that device may\nnot work. For example, it looks like vga16fb.c would not work because\nit depends on VGA_FB_PHYS at 0xA0000. A native driver certainly\n*could* work, but that depends on whether the specific device and\ndriver require the legacy resources.\n\nIIUC, part of what this patch does is relax this so we can set a\ndefault \"VGA device\" that doesn't receive accesses to legacy VGA\nresources. If so, it's probably worth mentioning somehow that some\nVGA things, e.g., vga16fb.c, may not work with this default device.\n\n[1] PCI spec r3.0, sec G\n[2] PCI-to-PCI bridge spec r1.2, sec 3.2.5.18, sec 12.1.1\n[3] PCI IDE Controller spec, r1.0, sec 2.1\n[4] PCI-to-PCI bridge spec r1.2, sec 4.5\n\n> may find that no\n> default/boot VGA device has been marked, because the VGA arbiter\n> checks for legacy resource decoding before marking a card as default.\n> \n> Split the small bit of code that does default VGA handling out from\n> the arbiter. Add a Kconfig option to allow the kernel to be built\n> with just the default handling, or the arbiter and default handling.\n> \n> Add handling for devices that should be marked as default but aren't\n> handled by the vga arbiter by adding a late initcall and a class\n> enable hook. If there is no default from vgaarb then the first card\n> that is enabled, has a driver bound, and can decode memory or I/O\n> will be marked as default.\n\n> + * vga_default_device - return the default VGA device\n> + *\n> + * This can be defined by the platform. The default implementation\n> + * is rather dumb and will probably only work properly on single\n> + * vga card setups and/or x86 platforms.\n\nIn what sense can this be defined by the platform? I guess this\ncomment isn't new and was just moved, but I don't see any arch hook or\nobvious way to do a platform-specific definition.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xZPVR6BZVz9t1t\n\tfor ;\n\tSun, 20 Aug 2017 01:47:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751169AbdHSPr5 (ORCPT );\n\tSat, 19 Aug 2017 11:47:57 -0400","from mail.kernel.org ([198.145.29.99]:52234 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751153AbdHSPr5 (ORCPT );\n\tSat, 19 Aug 2017 11:47:57 -0400","from localhost (unknown [69.71.4.159])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 4526F21A31;\n\tSat, 19 Aug 2017 15:47:56 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 4526F21A31","Date":"Sat, 19 Aug 2017 10:47:53 -0500","From":"Bjorn Helgaas ","To":"Daniel Axtens ","Cc":"linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-arm-kernel@lists.infradead.org, gabriele.paoloni@huawei.com,\n\tairlied@linux.ie, benh@kernel.crashing.org, will.deacon@arm.com,\n\tdri-devel@lists.freedesktop.org, z.liuxinliang@hisilicon.com,\n\tbhelgaas@google.com, alex.williamson@redhat.com, lukas@wunner.de,\n\tcatalin.marinas@arm.com, zourongrong@gmail.com, daniel.vetter@intel.com","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170819154753.GQ28977@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170817113028.16853-2-dja@axtens.net>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1752256,"web_url":"http://patchwork.ozlabs.org/comment/1752256/","msgid":"<1503256100.12059.13.camel@kernel.crashing.org>","list_archive_url":null,"date":"2017-08-20T19:08:20","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":38,"url":"http://patchwork.ozlabs.org/api/people/38/","name":"Benjamin Herrenschmidt","email":"benh@kernel.crashing.org"},"content":"On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote:\n> So if ARM64 doesn't have these PCI legacy resources, does that mean an\n> ARM64 host bridge cannot generate these legacy addresses on PCI? That\n> is, there's no host bridge window that maps to those PCI addresses?\n> That seems like a curious restriction on host bridges, but I guess it\n> would be possible.\n\nIt's rather common. For example on POWER8:\n\n - There is no IO space at all\n\n - We configure the 32-bit MMIO window to be around 3..4G (to avoid\noverlapping with DMA space below it).\n\nSo we effectively have no path to the legacy areas, and that hasn't\nbeen a problem so far.\n\nCheers,\nBen.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xb61N4wzDz9s4q\n\tfor ;\n\tMon, 21 Aug 2017 05:13:44 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753393AbdHTTNn (ORCPT );\n\tSun, 20 Aug 2017 15:13:43 -0400","from gate.crashing.org ([63.228.1.57]:37723 \"EHLO\n\tgate.crashing.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753368AbdHTTNm (ORCPT );\n\tSun, 20 Aug 2017 15:13:42 -0400","from localhost (localhost.localdomain [127.0.0.1])\n\tby gate.crashing.org (8.14.1/8.13.8) with ESMTP id v7KJ8Lk9001017;\n\tSun, 20 Aug 2017 14:08:22 -0500"],"Message-ID":"<1503256100.12059.13.camel@kernel.crashing.org>","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","From":"Benjamin Herrenschmidt ","To":"Bjorn Helgaas , Daniel Axtens ","Cc":"linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-arm-kernel@lists.infradead.org, gabriele.paoloni@huawei.com,\n\tairlied@linux.ie, will.deacon@arm.com,\n\tdri-devel@lists.freedesktop.org, z.liuxinliang@hisilicon.com,\n\tbhelgaas@google.com, alex.williamson@redhat.com, lukas@wunner.de,\n\tcatalin.marinas@arm.com, zourongrong@gmail.com, daniel.vetter@intel.com","Date":"Sun, 20 Aug 2017 12:08:20 -0700","In-Reply-To":"<20170819154753.GQ28977@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170819154753.GQ28977@bhelgaas-glaptop.roam.corp.google.com>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.24.5 (3.24.5-1.fc26) ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1752276,"web_url":"http://patchwork.ozlabs.org/comment/1752276/","msgid":"<20170820215449.GZ28977@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-20T21:54:49","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Sun, Aug 20, 2017 at 12:08:20PM -0700, Benjamin Herrenschmidt wrote:\n> On Sat, 2017-08-19 at 10:47 -0500, Bjorn Helgaas wrote:\n> > So if ARM64 doesn't have these PCI legacy resources, does that mean an\n> > ARM64 host bridge cannot generate these legacy addresses on PCI? That\n> > is, there's no host bridge window that maps to those PCI addresses?\n> > That seems like a curious restriction on host bridges, but I guess it\n> > would be possible.\n> \n> It's rather common. For example on POWER8:\n\nI'm just trying to tease out which things are required by PCI and\nwhich things are required by the arch. It doesn't surprise me at all\nthat some platforms (on any arch) don't provide access to legacy\nresources. That's totally outside the PCI area. Do Power and ARM64\nactively *prohibit* platforms from using legacy resources? I can\nbelieve current platforms don't use them, but I can still conceive of\npossible systems that could.\n\nI think removing the \"(e.g. ARM64)\" from the original changelog would\nhave avoided my questions. That example suggests that ARM64 is\nspecial in some way and *cannot* use PCI legacy resources. It's easy\nto conceive of a system of any arch that can't use them, simply\nbecause it chose to use a host bridge that can't generate PCI\ntransactions to the VGA frame buffer or to I/O space.\n\n> - There is no IO space at all\n> \n> - We configure the 32-bit MMIO window to be around 3..4G (to avoid\n> overlapping with DMA space below it).\n> \n> So we effectively have no path to the legacy areas, and that hasn't\n> been a problem so far.\n\nI assume vga16fb.c and similar things don't work (which isn't a\nproblem as long as that's what everybody expects).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xb9bK6j36z9sPs\n\tfor ;\n\tMon, 21 Aug 2017 07:54:53 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753316AbdHTVyw (ORCPT );\n\tSun, 20 Aug 2017 17:54:52 -0400","from mail.kernel.org ([198.145.29.99]:60908 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1753300AbdHTVyv (ORCPT );\n\tSun, 20 Aug 2017 17:54:51 -0400","from localhost (unknown [69.71.4.159])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 38235218EC;\n\tSun, 20 Aug 2017 21:54:51 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 38235218EC","Date":"Sun, 20 Aug 2017 16:54:49 -0500","From":"Bjorn Helgaas ","To":"Benjamin Herrenschmidt ","Cc":"Daniel Axtens , linux-pci@vger.kernel.org,\n\tlinuxppc-dev@lists.ozlabs.org,\n\tlinux-arm-kernel@lists.infradead.org, gabriele.paoloni@huawei.com,\n\tairlied@linux.ie, will.deacon@arm.com,\n\tdri-devel@lists.freedesktop.org, z.liuxinliang@hisilicon.com,\n\tbhelgaas@google.com, alex.williamson@redhat.com, lukas@wunner.de,\n\tcatalin.marinas@arm.com, zourongrong@gmail.com, daniel.vetter@intel.com","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170820215449.GZ28977@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170819154753.GQ28977@bhelgaas-glaptop.roam.corp.google.com>\n\t<1503256100.12059.13.camel@kernel.crashing.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<1503256100.12059.13.camel@kernel.crashing.org>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1752669,"web_url":"http://patchwork.ozlabs.org/comment/1752669/","msgid":"<20170821105300.GB23287@e107981-lin.cambridge.arm.com>","list_archive_url":null,"date":"2017-08-21T10:53:01","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":5388,"url":"http://patchwork.ozlabs.org/api/people/5388/","name":"Lorenzo Pieralisi","email":"Lorenzo.Pieralisi@arm.com"},"content":"On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:\n> A system without PCI legacy resources (e.g. ARM64) may find that no\n> default/boot VGA device has been marked, because the VGA arbiter\n> checks for legacy resource decoding before marking a card as default.\n\nI do not understand this paragraph, in particular:\n\n- \"A system without PCI legacy resources (e.g. ARM64)\". What does this\n mean ? I take this as \"ARM64 does not support IO space\"; if a PCI host\n bridge supports IO space, there is nothing from an architectural\n point of view that prevents an MMIO based IO space implementation to\n work on ARM64. It is PCI bridge specific, not arch specific.\n- \"the VGA arbiter checks for legacy resources\". Do you mean it checks\n if a VGA class device enabled IO/MEM address spaces (and if the\n bridges upstream forwards those address spaces), correct ?\n\nThe assumption relying on ARM64 not supporting IO space (if that's what\nyou mean by \"a system without PCI legacy resources\") is not correct.\n\nThanks,\nLorenzo\n\n> Split the small bit of code that does default VGA handling out from\n> the arbiter. Add a Kconfig option to allow the kernel to be built\n> with just the default handling, or the arbiter and default handling.\n> \n> Add handling for devices that should be marked as default but aren't\n> handled by the vga arbiter by adding a late initcall and a class\n> enable hook. If there is no default from vgaarb then the first card\n> that is enabled, has a driver bound, and can decode memory or I/O\n> will be marked as default.\n> \n> Signed-off-by: Daniel Axtens \n> \n> ---\n> \n> v2: Tested on:\n> - x86_64 laptop\n> - arm64 D05 board with hibmc card\n> - qemu powerpc with tcg and bochs std-vga\n> \n> I know this adds another config option and that's a bit sad, but\n> we can't include it unconditionally as it depends on PCI.\n> Suggestions welcome.\n> ---\n> arch/ia64/pci/fixup.c | 2 +-\n> arch/powerpc/kernel/pci-common.c | 2 +-\n> arch/x86/pci/fixup.c | 2 +-\n> arch/x86/video/fbdev.c | 2 +-\n> drivers/gpu/vga/Kconfig | 12 +++\n> drivers/gpu/vga/Makefile | 1 +\n> drivers/gpu/vga/vga_default.c | 159 +++++++++++++++++++++++++++++++++++++++\n> drivers/gpu/vga/vga_switcheroo.c | 2 +-\n> drivers/gpu/vga/vgaarb.c | 41 +---------\n> drivers/pci/pci-sysfs.c | 2 +-\n> include/linux/vga_default.h | 44 +++++++++++\n> include/linux/vgaarb.h | 14 ----\n> 12 files changed, 225 insertions(+), 58 deletions(-)\n> create mode 100644 drivers/gpu/vga/vga_default.c\n> create mode 100644 include/linux/vga_default.h\n> \n> diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c\n> index 41caa99add51..b35d1cf4501a 100644\n> --- a/arch/ia64/pci/fixup.c\n> +++ b/arch/ia64/pci/fixup.c\n> @@ -5,7 +5,7 @@\n> \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> \n> #include \n> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c\n> index 341a7469cab8..4fd890a51d18 100644\n> --- a/arch/powerpc/kernel/pci-common.c\n> +++ b/arch/powerpc/kernel/pci-common.c\n> @@ -31,7 +31,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> \n> #include \n> #include \n> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c\n> index 11e407489db0..b1254bc09a45 100644\n> --- a/arch/x86/pci/fixup.c\n> +++ b/arch/x86/pci/fixup.c\n> @@ -5,7 +5,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> #include \n> \n> diff --git a/arch/x86/video/fbdev.c b/arch/x86/video/fbdev.c\n> index 9fd24846d094..62cfa74ea86e 100644\n> --- a/arch/x86/video/fbdev.c\n> +++ b/arch/x86/video/fbdev.c\n> @@ -9,7 +9,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> \n> int fb_is_primary_device(struct fb_info *info)\n> {\n> diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig\n> index 29437eabe095..81d4105aecf6 100644\n> --- a/drivers/gpu/vga/Kconfig\n> +++ b/drivers/gpu/vga/Kconfig\n> @@ -1,3 +1,14 @@\n> +config VGA_DEFAULT\n> +\tbool \"VGA Default Device Support\" if EXPERT\n> +\tdefault y\n> +\tdepends on PCI\n> +\thelp\n> +\t Some programs find it helpful to know what VGA device is the default.\n> +\t On platforms like x86 this means the device used by the BIOS to show\n> +\t early boot messages. On other platforms this may be an arbitrary PCI\n> +\t graphics card. Select this to have a default device recorded within\n> +\t the kernel and exposed to userspace through sysfs.\n> +\n> config VGA_ARB\n> \tbool \"VGA Arbitration\" if EXPERT\n> \tdefault y\n> @@ -22,6 +33,7 @@ config VGA_SWITCHEROO\n> \tdepends on X86\n> \tdepends on ACPI\n> \tselect VGA_ARB\n> +\tselect VGA_DEFAULT\n> \thelp\n> \t Many laptops released in 2008/9/10 have two GPUs with a multiplexer\n> \t to switch between them. This adds support for dynamic switching when\n> diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile\n> index 14ca30b75d0a..1e30f90d40fb 100644\n> --- a/drivers/gpu/vga/Makefile\n> +++ b/drivers/gpu/vga/Makefile\n> @@ -1,2 +1,3 @@\n> obj-$(CONFIG_VGA_ARB) += vgaarb.o\n> +obj-$(CONFIG_VGA_DEFAULT) += vga_default.o\n> obj-$(CONFIG_VGA_SWITCHEROO) += vga_switcheroo.o\n> diff --git a/drivers/gpu/vga/vga_default.c b/drivers/gpu/vga/vga_default.c\n> new file mode 100644\n> index 000000000000..f6fcb0eb1507\n> --- /dev/null\n> +++ b/drivers/gpu/vga/vga_default.c\n> @@ -0,0 +1,159 @@\n> +/*\n> + * vga_default.c: What is the default/boot PCI VGA device?\n> + *\n> + * (C) Copyright 2005 Benjamin Herrenschmidt \n> + * (C) Copyright 2007 Paulo R. Zanoni \n> + * (C) Copyright 2007, 2009 Tiago Vignatti \n> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens )\n> + *\n> + * (License from vgaarb.c)\n> + * Permission is hereby granted, free of charge, to any person obtaining a\n> + * copy of this software and associated documentation files (the \"Software\"),\n> + * to deal in the Software without restriction, including without limitation\n> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,\n> + * and/or sell copies of the Software, and to permit persons to whom the\n> + * Software is furnished to do so, subject to the following conditions:\n> + *\n> + * The above copyright notice and this permission notice (including the next\n> + * paragraph) shall be included in all copies or substantial portions of the\n> + * Software.\n> + *\n> + * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL\n> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\n> + * DEALINGS\n> + * IN THE SOFTWARE.\n> + */\n> +\n> +/*\n> + * What device should a graphics system draw to? In order of priority:\n> + *\n> + * 1) Any devices configured specifically by the user (think\n> + * xorg.conf).\n> + *\n> + * 2) If the platform has a concept of a boot device for early boot\n> + * messages (think BIOS displays on x86), that device.\n> + *\n> + * 3) If the platform does not have the concept of a boot device,\n> + * then we still want to pick something. For now, pick the first\n> + * PCI VGA device with a driver bound and with memory or I/O\n> + * control on.\n> + */\n> +\n> +#include \n> +#include \n> +#include \n> +#include \n> +\n> +#include \n> +\n> +static struct pci_dev *vga_default;\n> +/*\n> + * only go active after the late initcall so as not to interfere with\n> + * the arbiter\n> + */\n> +static bool vga_default_active = false;\n> +\n> +/**\n> + * vga_default_device - return the default VGA device\n> + *\n> + * This can be defined by the platform. The default implementation\n> + * is rather dumb and will probably only work properly on single\n> + * vga card setups and/or x86 platforms.\n> + *\n> + * If your VGA default device is not PCI, you'll have to return\n> + * NULL here. In this case, I assume it will not conflict with\n> + * any PCI card. If this is not true, I'll have to define two archs\n> + * hooks for enabling/disabling the VGA default device if that is\n> + * possible. This may be a problem with real _ISA_ VGA cards, in\n> + * addition to a PCI one. I don't know at this point how to deal\n> + * with that card. Can theirs IOs be disabled at all ? If not, then\n> + * I suppose it's a matter of having the proper arch hook telling\n> + * us about it, so we basically never allow anybody to succeed a\n> + * vga_get()...\n> + */\n> +\n> +struct pci_dev *vga_default_device(void)\n> +{\n> +\treturn vga_default;\n> +}\n> +EXPORT_SYMBOL_GPL(vga_default_device);\n> +\n> +void vga_set_default_device(struct pci_dev *pdev)\n> +{\n> +\tif (vga_default == pdev)\n> +\t\treturn;\n> +\n> +\tpci_dev_put(vga_default);\n> +\tvga_default = pci_dev_get(pdev);\n> +}\n> +\n> +static bool vga_default_try_device(struct pci_dev *pdev)\n> +{\n> +\tu16 cmd;\n> +\n> +\t/* Only deal with VGA class devices */\n> +\tif ((pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA)\n> +\t\treturn false;\n> +\n> +\t/* Only deal with devices with drivers bound */\n> +\tif (!pdev->driver)\n> +\t\treturn false;\n> +\n> +\t/* Require I/O or memory control */\n> +\tpci_read_config_word(pdev, PCI_COMMAND, &cmd);\n> +\tif (!(cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)))\n> +\t\treturn false;\n> +\n> +\tdev_info(&pdev->dev, \"vga_default: setting as default device\\n\");\n> +\tvga_set_default_device(pdev);\n> +\treturn true;\n> +}\n> +\n> +static int __init vga_default_init(void)\n> +{\n> +\tstruct pci_dev *pdev;\n> +\n> +\tvga_default_active = true;\n> +\n> +\tif (vga_default_device())\n> +\t\treturn 0;\n> +\n> +\tpdev = NULL;\n> +\twhile ((pdev =\n> +\t\tpci_get_subsys(PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,\n> +\t\t\t PCI_ANY_ID, pdev)) != NULL) {\n> +\t\tif (vga_default_try_device(pdev))\n> +\t\t\treturn 0;\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +late_initcall(vga_default_init);\n> +\n> +/*\n> + * A driver could be loaded much later than late_initcall, for example\n> + * if it's in a module.\n> + *\n> + * We want to pick that up. However, we want to make sure this does\n> + * not interfere with the arbiter - it should only activate if the\n> + * arbiter has already had a chance to operate. To ensure this, we set\n> + * vga_default_active in the late_initcall: as the vga arbiter is a\n> + * subsys initcall, it is guaranteed to fire first.\n> + */\n> +static void vga_default_enable_hook(struct pci_dev *pdev)\n> +{\n> + if (!vga_default_active)\n> +\t return;\n> +\n> + if (vga_default_device())\n> + return;\n> +\n> + vga_default_try_device(pdev);\n> +}\n> +DECLARE_PCI_FIXUP_CLASS_ENABLE(PCI_ANY_ID, PCI_ANY_ID,\n> +\t\t\t PCI_CLASS_DISPLAY_VGA, 8,\n> +\t\t\t vga_default_enable_hook)\n> diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c\n> index 3cd153c6d271..6612ec7981b6 100644\n> --- a/drivers/gpu/vga/vga_switcheroo.c\n> +++ b/drivers/gpu/vga/vga_switcheroo.c\n> @@ -41,7 +41,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> \n> /**\n> diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c\n> index 76875f6299b8..74683286f5f8 100644\n> --- a/drivers/gpu/vga/vgaarb.c\n> +++ b/drivers/gpu/vga/vgaarb.c\n> @@ -51,6 +51,7 @@\n> \n> #include \n> \n> +#include \n> #include \n> \n> static void vga_arbiter_notify_clients(void);\n> @@ -119,9 +120,6 @@ static int vga_str_to_iostate(char *buf, int str_size, int *io_state)\n> \treturn 1;\n> }\n> \n> -/* this is only used a cookie - it should not be dereferenced */\n> -static struct pci_dev *vga_default;\n> -\n> static void vga_arb_device_card_gone(struct pci_dev *pdev);\n> \n> /* Find somebody in our list */\n> @@ -135,39 +133,6 @@ static struct vga_device *vgadev_find(struct pci_dev *pdev)\n> \treturn NULL;\n> }\n> \n> -/**\n> - * vga_default_device - return the default VGA device, for vgacon\n> - *\n> - * This can be defined by the platform. The default implementation\n> - * is rather dumb and will probably only work properly on single\n> - * vga card setups and/or x86 platforms.\n> - *\n> - * If your VGA default device is not PCI, you'll have to return\n> - * NULL here. In this case, I assume it will not conflict with\n> - * any PCI card. If this is not true, I'll have to define two archs\n> - * hooks for enabling/disabling the VGA default device if that is\n> - * possible. This may be a problem with real _ISA_ VGA cards, in\n> - * addition to a PCI one. I don't know at this point how to deal\n> - * with that card. Can theirs IOs be disabled at all ? If not, then\n> - * I suppose it's a matter of having the proper arch hook telling\n> - * us about it, so we basically never allow anybody to succeed a\n> - * vga_get()...\n> - */\n> -struct pci_dev *vga_default_device(void)\n> -{\n> -\treturn vga_default;\n> -}\n> -EXPORT_SYMBOL_GPL(vga_default_device);\n> -\n> -void vga_set_default_device(struct pci_dev *pdev)\n> -{\n> -\tif (vga_default == pdev)\n> -\t\treturn;\n> -\n> -\tpci_dev_put(vga_default);\n> -\tvga_default = pci_dev_get(pdev);\n> -}\n> -\n> static inline void vga_irq_set_state(struct vga_device *vgadev, bool state)\n> {\n> \tif (vgadev->irq_set_state)\n> @@ -667,7 +632,7 @@ static bool vga_arbiter_add_pci_device(struct pci_dev *pdev)\n> \t/* Deal with VGA default device. Use first enabled one\n> \t * by default if arch doesn't have it's own hook\n> \t */\n> -\tif (vga_default == NULL &&\n> +\tif (vga_default_device() == NULL &&\n> \t ((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {\n> \t\tvgaarb_info(&pdev->dev, \"setting as boot VGA device\\n\");\n> \t\tvga_set_default_device(pdev);\n> @@ -704,7 +669,7 @@ static bool vga_arbiter_del_pci_device(struct pci_dev *pdev)\n> \t\tgoto bail;\n> \t}\n> \n> -\tif (vga_default == pdev)\n> +\tif (vga_default_device() == pdev)\n> \t\tvga_set_default_device(NULL);\n> \n> \tif (vgadev->decodes & (VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM))\n> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c\n> index 2f3780b50723..c174b427ea2b 100644\n> --- a/drivers/pci/pci-sysfs.c\n> +++ b/drivers/pci/pci-sysfs.c\n> @@ -27,7 +27,7 @@\n> #include \n> #include \n> #include \n> -#include \n> +#include \n> #include \n> #include \n> #include \"pci.h\"\n> diff --git a/include/linux/vga_default.h b/include/linux/vga_default.h\n> new file mode 100644\n> index 000000000000..78df6a2a194c\n> --- /dev/null\n> +++ b/include/linux/vga_default.h\n> @@ -0,0 +1,44 @@\n> +/*\n> + * vga_default.h: What is the default/boot PCI VGA device?\n> + *\n> + * (C) Copyright 2005 Benjamin Herrenschmidt \n> + * (C) Copyright 2007 Paulo R. Zanoni \n> + * (C) Copyright 2007, 2009 Tiago Vignatti \n> + * (C) Copyright 2017 Canonical Ltd. (Author: Daniel Axtens )\n> + *\n> + * (License from vgaarb.h)\n> + * Permission is hereby granted, free of charge, to any person obtaining a\n> + * copy of this software and associated documentation files (the \"Software\"),\n> + * to deal in the Software without restriction, including without limitation\n> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,\n> + * and/or sell copies of the Software, and to permit persons to whom the\n> + * Software is furnished to do so, subject to the following conditions:\n> + *\n> + * The above copyright notice and this permission notice (including the next\n> + * paragraph) shall be included in all copies or substantial portions of the\n> + * Software.\n> + *\n> + * THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL\n> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\n> + * DEALINGS\n> + * IN THE SOFTWARE.\n> + */\n> +\n> +#ifndef LINUX_VGA_DEFAULT_H\n> +#define LINUX_VGA_DEFAULT_H\n> +\n> +struct pci_dev;\n> +\n> +#ifdef CONFIG_VGA_DEFAULT\n> +extern struct pci_dev *vga_default_device(void);\n> +extern void vga_set_default_device(struct pci_dev *pdev);\n> +#else\n> +static inline struct pci_dev *vga_default_device(void) { return NULL; };\n> +static inline void vga_set_default_device(struct pci_dev *pdev) { };\n> +#endif\n> +\n> +#endif\n> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h\n> index ee162e3e879b..953e1955efbe 100644\n> --- a/include/linux/vgaarb.h\n> +++ b/include/linux/vgaarb.h\n> @@ -42,12 +42,6 @@\n> #define VGA_RSRC_NORMAL_IO 0x04\n> #define VGA_RSRC_NORMAL_MEM 0x08\n> \n> -/* Passing that instead of a pci_dev to use the system \"default\"\n> - * device, that is the one used by vgacon. Archs will probably\n> - * have to provide their own vga_default_device();\n> - */\n> -#define VGA_DEFAULT_DEVICE (NULL)\n> -\n> struct pci_dev;\n> \n> /* For use by clients */\n> @@ -122,14 +116,6 @@ extern void vga_put(struct pci_dev *pdev, unsigned int rsrc);\n> #endif\n> \n> \n> -#ifdef CONFIG_VGA_ARB\n> -extern struct pci_dev *vga_default_device(void);\n> -extern void vga_set_default_device(struct pci_dev *pdev);\n> -#else\n> -static inline struct pci_dev *vga_default_device(void) { return NULL; };\n> -static inline void vga_set_default_device(struct pci_dev *pdev) { };\n> -#endif\n> -\n> /*\n> * Architectures should define this if they have several\n> * independent PCI domains that can afford concurrent VGA\n> -- \n> 2.11.0\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xbVsM2S81z9s8J\n\tfor ;\n\tMon, 21 Aug 2017 20:53:11 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752482AbdHUKxJ (ORCPT );\n\tMon, 21 Aug 2017 06:53:09 -0400","from foss.arm.com ([217.140.101.70]:54834 \"EHLO foss.arm.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751959AbdHUKxH (ORCPT );\n\tMon, 21 Aug 2017 06:53:07 -0400","from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])\n\tby usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 766E280D;\n\tMon, 21 Aug 2017 03:53:07 -0700 (PDT)","from e107981-lin.cambridge.arm.com (e107981-lin.cambridge.arm.com\n\t[10.1.206.250])\n\tby usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id\n\t76AB63F578; Mon, 21 Aug 2017 03:53:04 -0700 (PDT)"],"Date":"Mon, 21 Aug 2017 11:53:01 +0100","From":"Lorenzo Pieralisi ","To":"Daniel Axtens ","Cc":"linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,\n\tlinux-arm-kernel@lists.infradead.org, benh@kernel.crashing.org,\n\tz.liuxinliang@hisilicon.com, zourongrong@gmail.com,\n\tcatalin.marinas@arm.com, will.deacon@arm.com,\n\tgabriele.paoloni@huawei.com, bhelgaas@google.com, airlied@linux.ie,\n\tdaniel.vetter@intel.com, alex.williamson@redhat.com,\n\tdri-devel@lists.freedesktop.org, lukas@wunner.de","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170821105300.GB23287@e107981-lin.cambridge.arm.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170817113028.16853-2-dja@axtens.net>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1754511,"web_url":"http://patchwork.ozlabs.org/comment/1754511/","msgid":"<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-22T22:19:28","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:\n> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:\n> > A system without PCI legacy resources (e.g. ARM64) may find that no\n> > default/boot VGA device has been marked, because the VGA arbiter\n> > checks for legacy resource decoding before marking a card as default.\n> \n> I do not understand this paragraph, in particular:\n> \n> - \"A system without PCI legacy resources (e.g. ARM64)\". What does this\n> mean ? I take this as \"ARM64 does not support IO space\"; if a PCI host\n> bridge supports IO space, there is nothing from an architectural\n> point of view that prevents an MMIO based IO space implementation to\n> work on ARM64. It is PCI bridge specific, not arch specific.\n\nThis reference to ARM64 is the same thing I stumbled over. Maybe it\ncould be written along the lines of:\n\n The VGA arbiter selects a default VGA device that is enabled and\n reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io\n 0x3b0-0x3bb, io 0x3c0-0x3df, etc).\n\n If there is no such device, e.g., because there's no enabled VGA\n device, the host bridge doesn't support access to those legacy\n resources, or a PCI-PCI bridge doesn't have VGA Enable set, a\n platform may select an arbitrary device by calling\n vga_set_default_device().\n\nThen I think this patch changes the previous behavior by allowing the\narbiter to select a device that is enabled and has a driver but may\nnot be reachable via the legacy VGA resources.\n\nI don't know what all the consequences of that would be, but it does\nmuddy the VGA arbiter waters a bit. AIUI, the main reason for the\narbiter is to allow multiple legacy VGA devices by manipulating bridge\nVGA Enable bits so only one receives the legacy resources at a time.\n\nThese devices that do not need the legacy resources don't need that\nspecial treatment because they don't care about the bridge VGA Enable\nbits and several can coexist in the system with no need for VGA\narbitration.\n\nI guess the powerpc fixup_vga() already selects a device that doesn't\nneed the VGA resources, so we already have that situation.\n\nBjorn","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xcQ2r0pqtz9s7F\n\tfor ;\n\tWed, 23 Aug 2017 08:19:32 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752490AbdHVWTa (ORCPT );\n\tTue, 22 Aug 2017 18:19:30 -0400","from mail.kernel.org ([198.145.29.99]:43010 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752377AbdHVWT3 (ORCPT );\n\tTue, 22 Aug 2017 18:19:29 -0400","from localhost (unknown [69.55.156.165])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 1DF062156A;\n\tTue, 22 Aug 2017 22:19:29 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 1DF062156A","Date":"Tue, 22 Aug 2017 17:19:28 -0500","From":"Bjorn Helgaas ","To":"Lorenzo Pieralisi ","Cc":"Daniel Axtens , catalin.marinas@arm.com,\n\tgabriele.paoloni@huawei.com, airlied@linux.ie,\n\tlinux-pci@vger.kernel.org, will.deacon@arm.com,\n\tdri-devel@lists.freedesktop.org, z.liuxinliang@hisilicon.com,\n\tbhelgaas@google.com, alex.williamson@redhat.com, lukas@wunner.de,\n\tbenh@kernel.crashing.org, zourongrong@gmail.com,\n\tdaniel.vetter@intel.com, linuxppc-dev@lists.ozlabs.org,\n\tlinux-arm-kernel@lists.infradead.org","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170821105300.GB23287@e107981-lin.cambridge.arm.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170821105300.GB23287@e107981-lin.cambridge.arm.com>","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1755221,"web_url":"http://patchwork.ozlabs.org/comment/1755221/","msgid":"","list_archive_url":null,"date":"2017-08-23T13:48:42","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":26857,"url":"http://patchwork.ozlabs.org/api/people/26857/","name":"Ard Biesheuvel","email":"ard.biesheuvel@linaro.org"},"content":"On 22 August 2017 at 23:19, Bjorn Helgaas wrote:\n> On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:\n>> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:\n>> > A system without PCI legacy resources (e.g. ARM64) may find that no\n>> > default/boot VGA device has been marked, because the VGA arbiter\n>> > checks for legacy resource decoding before marking a card as default.\n>>\n>> I do not understand this paragraph, in particular:\n>>\n>> - \"A system without PCI legacy resources (e.g. ARM64)\". What does this\n>> mean ? I take this as \"ARM64 does not support IO space\"; if a PCI host\n>> bridge supports IO space, there is nothing from an architectural\n>> point of view that prevents an MMIO based IO space implementation to\n>> work on ARM64. It is PCI bridge specific, not arch specific.\n>\n> This reference to ARM64 is the same thing I stumbled over. Maybe it\n> could be written along the lines of:\n>\n> The VGA arbiter selects a default VGA device that is enabled and\n> reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io\n> 0x3b0-0x3bb, io 0x3c0-0x3df, etc).\n>\n> If there is no such device, e.g., because there's no enabled VGA\n> device, the host bridge doesn't support access to those legacy\n> resources, or a PCI-PCI bridge doesn't have VGA Enable set, a\n> platform may select an arbitrary device by calling\n> vga_set_default_device().\n>\n> Then I think this patch changes the previous behavior by allowing the\n> arbiter to select a device that is enabled and has a driver but may\n> not be reachable via the legacy VGA resources.\n>\n> I don't know what all the consequences of that would be, but it does\n> muddy the VGA arbiter waters a bit. AIUI, the main reason for the\n> arbiter is to allow multiple legacy VGA devices by manipulating bridge\n> VGA Enable bits so only one receives the legacy resources at a time.\n>\n> These devices that do not need the legacy resources don't need that\n> special treatment because they don't care about the bridge VGA Enable\n> bits and several can coexist in the system with no need for VGA\n> arbitration.\n>\n> I guess the powerpc fixup_vga() already selects a device that doesn't\n> need the VGA resources, so we already have that situation.\n>\n\nPerhaps it is unclear that the whole point of tinkering with the VGA\narbiter is that X may refuse to use a GFX card if it is not tagged as\nthe default VGA device by the arbiter. I have suggested before that\nfixing X may be more appropriate in this case, given that ownership of\nthe legacy VGA resources may not correlate at all with being the\nprimary display device on non-x86 architectures.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"PwcVZxWw\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xcpg15qgtz9rvt\n\tfor ;\n\tWed, 23 Aug 2017 23:48:45 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754025AbdHWNso (ORCPT );\n\tWed, 23 Aug 2017 09:48:44 -0400","from mail-io0-f170.google.com ([209.85.223.170]:33477 \"EHLO\n\tmail-io0-f170.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754011AbdHWNsn (ORCPT\n\t); Wed, 23 Aug 2017 09:48:43 -0400","by mail-io0-f170.google.com with SMTP id o196so656589ioe.0\n\tfor ; Wed, 23 Aug 2017 06:48:43 -0700 (PDT)","by 10.107.162.1 with HTTP; Wed, 23 Aug 2017 06:48:42 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=BsP+3hHNprHcx3QX7DerFsAPm97cpmUV7/YFQmVPAU4=;\n\tb=PwcVZxWw0UtwXaj8/qmwlWT4oAQsNJGgOieyoj/DgQWL7TDg5i5p0XDy7BbWAXne8U\n\thwpOSB4s5bGrZ30hD/ZsBfP7HsrnYJm4vkulZUuj67FvfBJhw6KjV8+CgNSjQcrxv3mM\n\tSvPOaJGnlSAgGu6BJfccJtnNDMt1u9RHPSaKU=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=BsP+3hHNprHcx3QX7DerFsAPm97cpmUV7/YFQmVPAU4=;\n\tb=ENKAWxk8NAgoiRNdRZHALaU3l6MkG+ykv661RxV51PGb9tH5kMSwzU8xRbQuaHUSWO\n\thhP6iQ7dfG32TwRGQm8dhu6MmNb0cDDXjsSq8DH2BKjgh2H8x3z3VJbO4bVw3Hzy/H8I\n\t69YD3bgFcR5qnbzfziFFveYHd4NbBNOgHbNWh5NiCOcxYHaatyfN35HlJ+hw7IQvD3bb\n\teCiSfCRTYKWSsdSaVVwa9lENsKHt19hiALaYI6beVypK3OeRJZkxEMfz7CRaU6xkF8YS\n\tK4l7aqz/gTzKM4S2fsC5VAZcAlg8+ADUwI5InlvJX2NEcVvFzLgJkD15yCEq/oaVv5ZH\n\tMQ5A==","X-Gm-Message-State":"AHYfb5jG7D8z/lelkkt9H/uLS0EEY6LkAH+eDA3UwPFU4wxAEdERhgpv\n\to6YeGZ5YtiCqMXhXfLLkKSVa4C760rWbOqs=","X-Received":"by 10.107.157.206 with SMTP id\n\tg197mr2289140ioe.263.1503496122925; \n\tWed, 23 Aug 2017 06:48:42 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170821105300.GB23287@e107981-lin.cambridge.arm.com>\n\t<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>","From":"Ard Biesheuvel ","Date":"Wed, 23 Aug 2017 14:48:42 +0100","Message-ID":"","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","To":"Bjorn Helgaas ","Cc":"Lorenzo Pieralisi ,\n\tBenjamin Herrenschmidt ,\n\tGabriele Paoloni ,\n\tDavid Airlie ,\n\tCatalin Marinas ,\n\tWill Deacon ,\n\tdri-devel ,\n\t\"Liuxinliang (Matthew Liu)\" ,\n\tZou Rongrong ,\n\tAlex Williamson ,\n\tLukas Wunner , linux-pci ,\n\tBjorn Helgaas , daniel.vetter@intel.com,\n\tlinuxppc-dev ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t, Daniel Axtens ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1755237,"web_url":"http://patchwork.ozlabs.org/comment/1755237/","msgid":"<20170823135734.GB8498@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-23T13:57:34","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Wed, Aug 23, 2017 at 02:48:42PM +0100, Ard Biesheuvel wrote:\n> On 22 August 2017 at 23:19, Bjorn Helgaas wrote:\n> > On Mon, Aug 21, 2017 at 11:53:01AM +0100, Lorenzo Pieralisi wrote:\n> >> On Thu, Aug 17, 2017 at 09:30:28PM +1000, Daniel Axtens wrote:\n> >> > A system without PCI legacy resources (e.g. ARM64) may find that no\n> >> > default/boot VGA device has been marked, because the VGA arbiter\n> >> > checks for legacy resource decoding before marking a card as default.\n> >>\n> >> I do not understand this paragraph, in particular:\n> >>\n> >> - \"A system without PCI legacy resources (e.g. ARM64)\". What does this\n> >> mean ? I take this as \"ARM64 does not support IO space\"; if a PCI host\n> >> bridge supports IO space, there is nothing from an architectural\n> >> point of view that prevents an MMIO based IO space implementation to\n> >> work on ARM64. It is PCI bridge specific, not arch specific.\n> >\n> > This reference to ARM64 is the same thing I stumbled over. Maybe it\n> > could be written along the lines of:\n> >\n> > The VGA arbiter selects a default VGA device that is enabled and\n> > reachable via the legacy VGA resources (mem 0xa0000-0xbffff, io\n> > 0x3b0-0x3bb, io 0x3c0-0x3df, etc).\n> >\n> > If there is no such device, e.g., because there's no enabled VGA\n> > device, the host bridge doesn't support access to those legacy\n> > resources, or a PCI-PCI bridge doesn't have VGA Enable set, a\n> > platform may select an arbitrary device by calling\n> > vga_set_default_device().\n> >\n> > Then I think this patch changes the previous behavior by allowing the\n> > arbiter to select a device that is enabled and has a driver but may\n> > not be reachable via the legacy VGA resources.\n> >\n> > I don't know what all the consequences of that would be, but it does\n> > muddy the VGA arbiter waters a bit. AIUI, the main reason for the\n> > arbiter is to allow multiple legacy VGA devices by manipulating bridge\n> > VGA Enable bits so only one receives the legacy resources at a time.\n> >\n> > These devices that do not need the legacy resources don't need that\n> > special treatment because they don't care about the bridge VGA Enable\n> > bits and several can coexist in the system with no need for VGA\n> > arbitration.\n> >\n> > I guess the powerpc fixup_vga() already selects a device that doesn't\n> > need the VGA resources, so we already have that situation.\n> >\n> \n> Perhaps it is unclear that the whole point of tinkering with the VGA\n> arbiter is that X may refuse to use a GFX card if it is not tagged as\n> the default VGA device by the arbiter. I have suggested before that\n> fixing X may be more appropriate in this case, given that ownership of\n> the legacy VGA resources may not correlate at all with being the\n> primary display device on non-x86 architectures.\n\nYeah, maybe it's time to disconnect the \"default display device\" idea\nfrom the VGA arbiter. I have no idea what (if any) dependencies X has\non the legacy VGA resources. I assume X works fine on power, where it\nsounds like those resources are rarely or never available.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xcpsH0jhxz9s8V\n\tfor ;\n\tWed, 23 Aug 2017 23:57:39 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754076AbdHWN5h (ORCPT );\n\tWed, 23 Aug 2017 09:57:37 -0400","from mail.kernel.org ([198.145.29.99]:54770 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1754075AbdHWN5g (ORCPT );\n\tWed, 23 Aug 2017 09:57:36 -0400","from localhost (unknown [69.55.156.165])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 7702A20C48;\n\tWed, 23 Aug 2017 13:57:35 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 7702A20C48","Date":"Wed, 23 Aug 2017 08:57:34 -0500","From":"Bjorn Helgaas ","To":"Ard Biesheuvel ","Cc":"Lorenzo Pieralisi ,\n\tBenjamin Herrenschmidt ,\n\tGabriele Paoloni ,\n\tDavid Airlie ,\n\tCatalin Marinas ,\n\tWill Deacon ,\n\tdri-devel ,\n\t\"Liuxinliang (Matthew Liu)\" ,\n\tZou Rongrong ,\n\tAlex Williamson ,\n\tLukas Wunner , linux-pci ,\n\tBjorn Helgaas , daniel.vetter@intel.com,\n\tlinuxppc-dev ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t, Daniel Axtens ","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170823135734.GB8498@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170821105300.GB23287@e107981-lin.cambridge.arm.com>\n\t<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1755756,"web_url":"http://patchwork.ozlabs.org/comment/1755756/","msgid":"","list_archive_url":null,"date":"2017-08-24T00:57:26","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":519,"url":"http://patchwork.ozlabs.org/api/people/519/","name":"Dave Airlie","email":"airlied@gmail.com"},"content":"> Yeah, maybe it's time to disconnect the \"default display device\" idea\n> from the VGA arbiter. I have no idea what (if any) dependencies X has\n> on the legacy VGA resources. I assume X works fine on power, where it\n> sounds like those resources are rarely or never available.\n\nThe question on non-x86 archs, is what is the correct device to default to.\n\nOn x86 we use the legacy VGA resources as a pointer, as this is the device\nthe BIOS appeared on at boot so hopefully should be one you can see stuff on.\n\nOn non-x86 I've no idea how to decide if there are multiple devices, maybe the\nfirmware needs to tag something for the kernel if there are. Otherwise\nyou'd just\nbe picking something in probe order.\n\nI think the idea of these patches is to separate default display\ndevice from the arbiter.\n\nX uses the arbiter on x86 if required (it's horrible, and it's rare we\nhave to nowadays),\nbut for finding the default device it justs uses the sysfs boot_vga flag.\n\nDave.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"nOC7VwqQ\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xd5Vd2zHzz9s82\n\tfor ;\n\tThu, 24 Aug 2017 10:57:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750962AbdHXA52 (ORCPT );\n\tWed, 23 Aug 2017 20:57:28 -0400","from mail-ua0-f177.google.com ([209.85.217.177]:38873 \"EHLO\n\tmail-ua0-f177.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750715AbdHXA51 (ORCPT\n\t); Wed, 23 Aug 2017 20:57:27 -0400","by mail-ua0-f177.google.com with SMTP id n29so5994666uai.5\n\tfor ; Wed, 23 Aug 2017 17:57:27 -0700 (PDT)","by 10.103.71.25 with HTTP; Wed, 23 Aug 2017 17:57:26 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=GH06XdXQDRfEJLPs9bNaauTJejxEH/VaRGOR3cLLD8Q=;\n\tb=nOC7VwqQjqEXyXvEaYrqOgQCzvUipTp3/uyXqf4nQ9ZUNDW36lsdFFj/7G8twmVOt3\n\th3AM0dAHimxGgsChmxjPlZzr08Fa6yoeTWoB5W6nkpnG/77tHQ5bJf5ksCqIWFKl1Rhm\n\t54dwSFI+BKMTgpu82dXCNpQ0vwDNPs3wDIjnKO58pGOOP4VIabxBzYH4scIhwsejg9GS\n\trU7UkNMG5mvXnzg+E8nkn5gGzhvwIm3w9deMW8teuOK5DedwL2RAnPRfDqu3ifrBFdB+\n\ttNjbfsih1GMBGBa2T4De9EKwc5sI9WcRWtRQNaG1jse4kLlIyBr5MOepK0wWIrPp3mYA\n\t/jIw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=GH06XdXQDRfEJLPs9bNaauTJejxEH/VaRGOR3cLLD8Q=;\n\tb=HYIYy4pGKb0XRviULcl2Z6tRus0zquvV9ouuhXZlEy2C8vr1U8UW5z57W/W0SbPZfs\n\tx889R5nXSBedIyCSaiBmxDX6zY76cS5T86O1B0Fe8Xy/CWrBJXLU50GK8ymS9e+IpS4T\n\t0VI9K8EPBoCpuUTsisVAgWlMRqMS8WJvXfOE6CawKFaZqnO9u5/aCXYgUafuTORDnpYC\n\tgkwkjvO9DMwMpvCbcRbe4dVfdrEo+gf4pRf2nritrWZ974EyzeUoE3AnDOdAQvU0l+xz\n\tocxugcTdOf9TFuKhnN+qPce4wpRmnaIv2IsSXEF0lcyHBXHX9kAdGoV313Q2+SIL/bBe\n\tZa2Q==","X-Gm-Message-State":"AHYfb5hWcRWqneaAYELdsrp17+8cmqxYPw7WIdqmopJxlz60zr/Wgsee\n\tGyT9AHPoHDWZGCqy0WpE1EH/RKAIzg==","X-Received":"by 10.176.20.112 with SMTP id c45mr3182951uae.161.1503536246535; \n\tWed, 23 Aug 2017 17:57:26 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"<20170823135734.GB8498@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170821105300.GB23287@e107981-lin.cambridge.arm.com>\n\t<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>\n\t\n\t<20170823135734.GB8498@bhelgaas-glaptop.roam.corp.google.com>","From":"Dave Airlie ","Date":"Thu, 24 Aug 2017 10:57:26 +1000","Message-ID":"","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","To":"Bjorn Helgaas ","Cc":"Ard Biesheuvel ,\n\tLorenzo Pieralisi ,\n\tGabriele Paoloni ,\n\tWill Deacon ,\n\tdri-devel ,\n\tlinux-pci ,\n\t\"Liuxinliang (Matthew Liu)\" ,\n\tBjorn Helgaas ,\n\tAlex Williamson ,\n\tCatalin Marinas ,\n\tZou Rongrong ,\n\t\"Vetter, Daniel\" ,\n\tlinuxppc-dev ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t, Daniel Axtens ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1756127,"web_url":"http://patchwork.ozlabs.org/comment/1756127/","msgid":"","list_archive_url":null,"date":"2017-08-24T09:38:14","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":26857,"url":"http://patchwork.ozlabs.org/api/people/26857/","name":"Ard Biesheuvel","email":"ard.biesheuvel@linaro.org"},"content":"On 24 August 2017 at 01:57, Dave Airlie wrote:\n>> Yeah, maybe it's time to disconnect the \"default display device\" idea\n>> from the VGA arbiter. I have no idea what (if any) dependencies X has\n>> on the legacy VGA resources. I assume X works fine on power, where it\n>> sounds like those resources are rarely or never available.\n>\n> The question on non-x86 archs, is what is the correct device to default to.\n>\n> On x86 we use the legacy VGA resources as a pointer, as this is the device\n> the BIOS appeared on at boot so hopefully should be one you can see stuff on.\n>\n> On non-x86 I've no idea how to decide if there are multiple devices, maybe the\n> firmware needs to tag something for the kernel if there are. Otherwise\n> you'd just\n> be picking something in probe order.\n>\n> I think the idea of these patches is to separate default display\n> device from the arbiter.\n>\n> X uses the arbiter on x86 if required (it's horrible, and it's rare we\n> have to nowadays),\n> but for finding the default device it justs uses the sysfs boot_vga flag.\n>\n\nPart of the problem is that X refuses to start if there is only one\ndisplay device to begin with in case it hasn't taken ownership of the\nVGA legacy resources.","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=linaro.org header.i=@linaro.org\n\theader.b=\"kClR2GbZ\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdK3Y4tTwz9sPt\n\tfor ;\n\tThu, 24 Aug 2017 19:38:17 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751285AbdHXJiQ (ORCPT );\n\tThu, 24 Aug 2017 05:38:16 -0400","from mail-it0-f41.google.com ([209.85.214.41]:36785 \"EHLO\n\tmail-it0-f41.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751260AbdHXJiP (ORCPT\n\t); Thu, 24 Aug 2017 05:38:15 -0400","by mail-it0-f41.google.com with SMTP id j62so486486ith.1\n\tfor ; Thu, 24 Aug 2017 02:38:15 -0700 (PDT)","by 10.107.162.1 with HTTP; Thu, 24 Aug 2017 02:38:14 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google;\n\th=mime-version:in-reply-to:references:from:date:message-id:subject:to\n\t:cc; bh=Whiz7kQ1ZLp18NwtVgZa5f1IDrjb/V1sLe50SBT8dJ4=;\n\tb=kClR2GbZ5CCOSbdOUicR8fWgAJwcF9I6DH5J8oeVG8AuuZF/lRKPWL6vP/uJqlHAg2\n\tHi5SIq5XzBiKTF9vBqX1YDA3qr2c9/wRdHCj8yZs5oRTgqrmu3jL3DG+d156csYLH4qa\n\tWrA2uj4fTs6Yr9JjnyF99MQJ4Q1trtYDQM3NA=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:mime-version:in-reply-to:references:from:date\n\t:message-id:subject:to:cc;\n\tbh=Whiz7kQ1ZLp18NwtVgZa5f1IDrjb/V1sLe50SBT8dJ4=;\n\tb=kFzK+Yy549bPg8QqzcqE5h8VZVs3q5r01xyDYc4xCXZ/vMfFjzYLJamDgjSlrL8oI+\n\tcnV4c6H2DblWKiRIFjjNI99JTB3KUVwSknwRbCIx6jU17LRIrVj0ypQXBaErytOnWR5D\n\tl51DR9rtZqwBmO+uD6Gi3gn7Mn5JlaqVdH0wTlT/U/FhMTYvjSuIZVxdgZl3WpG/mUYG\n\t8Zpr3BSbidnnTpZkxKVj6hgPd9Wfq20XiHxypewK0KRyjYw4boWo+Gl0jYc0htR9T+Mw\n\tXw1RwXwspMdIOg42ldr5xq1xW1VVy3lTjPWx3io+2w5tX1WaIu5CW3xZM47lKfNUZhtj\n\tQnsQ==","X-Gm-Message-State":"AHYfb5ha17ChNSay0HXoa89uHPTTTAxJR4bpX+In+2o09ELcL1Ne3K+U\n\tcnyAvF8VtmImSexJwOvKr+P81y6URj2f","X-Received":"by 10.36.43.68 with SMTP id h65mr5381495ita.41.1503567494743;\n\tThu, 24 Aug 2017 02:38:14 -0700 (PDT)","MIME-Version":"1.0","In-Reply-To":"","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170821105300.GB23287@e107981-lin.cambridge.arm.com>\n\t<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>\n\t\n\t<20170823135734.GB8498@bhelgaas-glaptop.roam.corp.google.com>\n\t","From":"Ard Biesheuvel ","Date":"Thu, 24 Aug 2017 10:38:14 +0100","Message-ID":"","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","To":"Dave Airlie ","Cc":"Bjorn Helgaas ,\n\tLorenzo Pieralisi ,\n\tGabriele Paoloni ,\n\tWill Deacon ,\n\tdri-devel ,\n\tlinux-pci ,\n\t\"Liuxinliang (Matthew Liu)\" ,\n\tBjorn Helgaas ,\n\tAlex Williamson ,\n\tCatalin Marinas ,\n\tZou Rongrong ,\n\t\"Vetter, Daniel\" ,\n\tlinuxppc-dev ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t, Daniel Axtens ","Content-Type":"text/plain; charset=\"UTF-8\"","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}},{"id":1756404,"web_url":"http://patchwork.ozlabs.org/comment/1756404/","msgid":"<20170824135721.GB31858@bhelgaas-glaptop.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-24T13:57:21","subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","submitter":{"id":67298,"url":"http://patchwork.ozlabs.org/api/people/67298/","name":"Bjorn Helgaas","email":"helgaas@kernel.org"},"content":"On Thu, Aug 24, 2017 at 10:57:26AM +1000, Dave Airlie wrote:\n> > Yeah, maybe it's time to disconnect the \"default display device\" idea\n> > from the VGA arbiter. I have no idea what (if any) dependencies X has\n> > on the legacy VGA resources. I assume X works fine on power, where it\n> > sounds like those resources are rarely or never available.\n> \n> The question on non-x86 archs, is what is the correct device to default to.\n> \n> On x86 we use the legacy VGA resources as a pointer, as this is the device\n> the BIOS appeared on at boot so hopefully should be one you can see stuff on.\n> \n> On non-x86 I've no idea how to decide if there are multiple devices, maybe the\n> firmware needs to tag something for the kernel if there are. Otherwise\n> you'd just\n> be picking something in probe order.\n> \n> I think the idea of these patches is to separate default display\n> device from the arbiter.\n> \n> X uses the arbiter on x86 if required (it's horrible, and it's rare we\n> have to nowadays),\n> but for finding the default device it justs uses the sysfs boot_vga flag.\n\nThe sysfs boot_vga thing comes from PCI. The name suggests that it's\na VGA device and can use the legacy VGA resources.\n\nIf we want to indicate a general default display device that need not\nbe \"VGA\", it'd be really nice if we could pick a name that did not\ninclude \"vga\".\n\nEven if we could only do it inside the kernel, I think it would reduce\nconfusion if we could separate out the \"VGA\"-specific stuff like the\narbiter and names like \"vga_set_default_device()\" so that systems with\na non-legacy VGA default display device didn't have to use \"VGA\"\ninterfaces that don't make sense for them.\n\nBjorn","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@bilbo.ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=linux-pci-owner@vger.kernel.org;\n\treceiver=)","mail.kernel.org;\n\tdmarc=none (p=none dis=none) header.from=kernel.org","mail.kernel.org;\n\tspf=none smtp.mailfrom=helgaas@kernel.org"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xdQpY6G4Dz9s03\n\tfor ;\n\tThu, 24 Aug 2017 23:57:25 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751140AbdHXN5Y (ORCPT );\n\tThu, 24 Aug 2017 09:57:24 -0400","from mail.kernel.org ([198.145.29.99]:32842 \"EHLO mail.kernel.org\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752801AbdHXN5Y (ORCPT );\n\tThu, 24 Aug 2017 09:57:24 -0400","from localhost (173-25-0-118.client.mchsi.com [173.25.0.118])\n\t(using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))\n\t(No client certificate requested)\n\tby mail.kernel.org (Postfix) with ESMTPSA id 48CBC21A29;\n\tThu, 24 Aug 2017 13:57:23 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mail.kernel.org 48CBC21A29","Date":"Thu, 24 Aug 2017 08:57:21 -0500","From":"Bjorn Helgaas ","To":"Dave Airlie ","Cc":"Ard Biesheuvel ,\n\tLorenzo Pieralisi ,\n\tGabriele Paoloni ,\n\tWill Deacon ,\n\tdri-devel ,\n\tlinux-pci ,\n\t\"Liuxinliang (Matthew Liu)\" ,\n\tBjorn Helgaas ,\n\tAlex Williamson ,\n\tCatalin Marinas ,\n\tZou Rongrong ,\n\t\"Vetter, Daniel\" ,\n\tlinuxppc-dev ,\n\t\"linux-arm-kernel@lists.infradead.org\" \n\t, Daniel Axtens ","Subject":"Re: [PATCH v2 1/1] Split VGA default device handler out of VGA\n\tarbiter","Message-ID":"<20170824135721.GB31858@bhelgaas-glaptop.roam.corp.google.com>","References":"<20170817113028.16853-1-dja@axtens.net>\n\t<20170817113028.16853-2-dja@axtens.net>\n\t<20170821105300.GB23287@e107981-lin.cambridge.arm.com>\n\t<20170822221928.GL6948@bhelgaas-glaptop.roam.corp.google.com>\n\t\n\t<20170823135734.GB8498@bhelgaas-glaptop.roam.corp.google.com>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.21 (2010-09-15)","Sender":"linux-pci-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"linux-pci@vger.kernel.org"}}]