From patchwork Fri Sep 1 07:27:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 9933665 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5DA1E6016C for ; Fri, 1 Sep 2017 07:28:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4F79B2857D for ; Fri, 1 Sep 2017 07:28:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 43D7628582; Fri, 1 Sep 2017 07:28:42 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AB3C32857D for ; Fri, 1 Sep 2017 07:28:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751404AbdIAH2l (ORCPT ); Fri, 1 Sep 2017 03:28:41 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36290 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751354AbdIAH2k (ORCPT ); Fri, 1 Sep 2017 03:28:40 -0400 Received: by mail-pf0-f196.google.com with SMTP id k3so1181132pfc.3 for ; Fri, 01 Sep 2017 00:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=hKzZfZDxftC+GlONhJGQ7yGmTJlbWNbWPAwxJaUYBVc=; b=qM/nOp5FZaawNCNnWSpsG7BUzb5cBysXhQwYxANeZzLaQP/nDTmYTd4C8mq/dpOCLQ QyjwcpMwGhY6Wm7TONFXPYKBXAGZkpOz+9sExyovvb1KwBOX7g9KKjhYP3RB/2SKnzBc g4fEnZbqhdr7S5REuGwXZqeab+2RBOiQ0aL2E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=hKzZfZDxftC+GlONhJGQ7yGmTJlbWNbWPAwxJaUYBVc=; b=XICbOfClwEEZfU2Lk9iG+PfWgMhObi+33TA9AEQYAkGIto4c6uttHcW8r8BO9x79KA wpGPiEyMG8PY+tA3zuH5xKe8myD3V72Fs+uvOUdSyCEHRDJnzl+FjDiuOc6HcI9W1wCi j+Msas0GQnfH4GohMs1v9mIc8b5u9hSj2+XoB7BP9Z9VatXoaTiMlAlX3zR5aTIx0RxC uL4oowPauaIzG15l1JnXyds/t16BxG/iKFEGm6/9C545fzdpO3XzpznIFeaXqlMY8E8S 9U4sqtSNG+DkWSzIDDVEpihb5Hv5EOZHgxpM8Vy3+yqCgvBIgtBWBxdnWWXL3Tynj3U5 fcsw== X-Gm-Message-State: AHPjjUjPJy8/eyXTKTENYRHehJB1VyVbhINV3TaRJm4+K1KkIUJMffZm PhznGszpPaTra6cEYFM1QQ== X-Google-Smtp-Source: ADKCNb6SF8U4xLPhDN5082K2s+rZHv9cIgmOjvpK88ENEdDVpBCDGexEJAjpJltfhWWUboNsqrIBjQ== X-Received: by 10.84.236.79 with SMTP id h15mr1314458pln.393.1504250919790; Fri, 01 Sep 2017 00:28:39 -0700 (PDT) Received: from localhost.localdomain (124-171-202-56.dyn.iinet.net.au. [124.171.202.56]) by smtp.gmail.com with ESMTPSA id l30sm2430300pgc.61.2017.09.01.00.28.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 00:28:39 -0700 (PDT) From: Daniel Axtens To: linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Cc: benh@kernel.crashing.org, z.liuxinliang@hisilicon.com, zourongrong@gmail.com, catalin.marinas@arm.com, will.deacon@arm.com, gabriele.paoloni@huawei.com, helgaas@kernel.org, airlied@linux.ie, daniel.vetter@intel.com, alex.williamson@redhat.com, dri-devel@lists.freedesktop.org, lukas@wunner.de, ard.biesheuvel@linaro.org, lorenzo.pieralisi@arm.com, Daniel Axtens Subject: [PATCH v3 3/3] drm: documentation for default display device Date: Fri, 1 Sep 2017 17:27:44 +1000 Message-Id: <20170901072744.2409-4-dja@axtens.net> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20170901072744.2409-1-dja@axtens.net> References: <20170901072744.2409-1-dja@axtens.net> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP We have refactored and extended this - document it. Signed-off-by: Daniel Axtens --- Documentation/gpu/default_display.rst | 93 +++++++++++++++++++++++++++++++++++ Documentation/gpu/index.rst | 1 + 2 files changed, 94 insertions(+) create mode 100644 Documentation/gpu/default_display.rst diff --git a/Documentation/gpu/default_display.rst b/Documentation/gpu/default_display.rst new file mode 100644 index 000000000000..3c190611564e --- /dev/null +++ b/Documentation/gpu/default_display.rst @@ -0,0 +1,93 @@ +======================= +Default Display Devices +======================= + +Overview +======== + +.. kernel-doc:: drivers/gpu/vga/default_display.c + :doc: overview + + +Why do we need this? +==================== + +The default device is used to set the ``boot_vga`` per-device sysfs +file, which is used by user-space. Most notably, Xorg reads this file +via libpciaccess in order to facilitate auto-configuration. + + +History +======= + +When the VGA arbiter was introduced, it would pick a default device on +boot. As the arbiter exists to arbitrate access to legacy resources, +it would only pick a card that could be accessed through legacy areas. +(See the :doc:`vgaarbiter` documentation for more.) + +The arbiter was later extended on x86 and IA64 to consider the EFI +framebuffer. + +This is all well and good if you have legacy resources or +EFI. However, some systems do not have either of those. For example, +on POWER8: [0]_ + + - 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 effectively, there is no path to the legacy areas. + +This means the VGA arbiter will not pick a default device on these +platforms. So, on powerpc, a class hook was added to mark a default +device (``arch/powerpc/kernel/pci-common.c``), independent of the +arbiter. + +When this issue arose on an arm64 system, it was decided that a generic +approach would be better than more special cases. Therefore, the +default device selection was factored out, and it now operates using +the priority list described in the Overview. + +API +=== + +Public +------ + +.. kernel-doc:: drivers/gpu/vga/default_display.c + :export: + +Private +------- + +.. kernel-doc:: drivers/gpu/vga/default_display.c + :internal: + +Future Work +=========== + +There is no support for non-PCI VGA devices being marked as default. +The following comment, extracted from an earlier version of +:c:func:`pci_default_display()` might help: + + If your VGA default device is not PCI, you'll have to override this + and 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()``... + +Currently there is also no way to support non-VGA-class PCI devices as +default display devices. + + +References +========== + +.. [0] https://www.spinics.net/lists/linux-pci/msg64142.html diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 35d673bf9b56..8083d84f2334 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -16,6 +16,7 @@ Linux GPU Driver Developer's Guide tegra tinydrm vc4 + default_display vga-switcheroo vgaarbiter bridge/dw-hdmi