From patchwork Fri Apr 1 23:11:31 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jake Oshins X-Patchwork-Id: 605041 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qcF623MSCz9sf6 for ; Sat, 2 Apr 2016 08:35:06 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752340AbcDAVey (ORCPT ); Fri, 1 Apr 2016 17:34:54 -0400 Received: from p3plsmtps2ded03.prod.phx3.secureserver.net ([208.109.80.60]:43456 "EHLO p3plsmtps2ded03.prod.phx3.secureserver.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755258AbcDAVe1 (ORCPT ); Fri, 1 Apr 2016 17:34:27 -0400 Received: from linuxonhyperv.com ([72.167.245.219]) by : HOSTING RELAY : with SMTP id m6f8aXWyPetyNm6f8anJ0G; Fri, 01 Apr 2016 14:31:26 -0700 x-originating-ip: 72.167.245.219 Received: by linuxonhyperv.com (Postfix, from userid 520) id 174BC190331; Fri, 1 Apr 2016 16:11:58 -0700 (PDT) From: Jake Oshins To: linux-pci@vger.kernel.org, gregkh@linuxfoundation.org, kys@microsoft.com, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com, haiyangz@microsoft.com, haddenh@microsoft.com Cc: Jake Oshins Subject: [PATCH v3 6/7] drivers:hv: Record MMIO range in use by frame buffer Date: Fri, 1 Apr 2016 16:11:31 -0700 Message-Id: <1459552292-1297-7-git-send-email-jakeo@microsoft.com> X-Mailer: git-send-email 1.7.4.1 In-Reply-To: <1459552292-1297-1-git-send-email-jakeo@microsoft.com> References: <1459552292-1297-1-git-send-email-jakeo@microsoft.com> X-CMAE-Envelope: MS4wfF3+YPEMrcWOugT5MzZ09z2lCw7XaiwW5G35WYUkID4xUIIQRMp7SuSN8hxyRypxck2tmbXvQa5N2QKu3pAASxOijv3K1cdsnXZ5u+AMy4nqOgFXYtG7 sLsr0Lk+ahII2kBPYpWEJQ/6r8Yl7lXsMX5mSuZgzhZ0XkOTIj7KOXE6Q1VoI9SUQOR3hHYL9mUmCkk/RoipeHyOrKGnG9PI/SAn3p0Vy1odcHGpoMYkwU0T 51hCeAN1NLHEQOZypydR/EdDrri39Wu7H01pfh8ibCggh+rtmkDtqz1fIJRi30Vb1L4dJCaAYmC6pUcTidurF0qOcTftXwBW/gj3vy9XA2yKx8RbiV/K5ubm kFkq8JzrPnSPuPGKaVD0+f58B1LSyM1vmxBw1+w1O0QdRdMaCI/WNoVNJ+j5ZFxRC0znA46/IS4uNRtD0FtxedHonARK3+80UAWkjLXXJdKo4DNfZkMrFsOW oAj/xeLlwUOIOEXvaEzBJALXKPtfxNRAqrau1JsJOEcpfLzYBWa2EaDJOds= Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Later in the boot sequence, we need to figure out which memory ranges can be given out to various paravirtual drivers. The hyperv_fb driver should, ideally, be placed right on top of the frame buffer, without some other device getting plopped on top of this range in the meantime. Recording this now allows that to be guaranteed. Signed-off-by: Jake Oshins --- drivers/hv/vmbus_drv.c | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index dfc6149..df59bfb 100644 --- a/drivers/hv/vmbus_drv.c +++ b/drivers/hv/vmbus_drv.c @@ -41,6 +41,7 @@ #include #include #include +#include #include "hyperv_vmbus.h" static struct acpi_device *hv_acpi_dev; @@ -101,6 +102,8 @@ static struct notifier_block hyperv_panic_block = { .notifier_call = hyperv_panic_event, }; +static const char *fb_mmio_name = "fb_range"; +static struct resource *fb_mmio; struct resource *hyperv_mmio; DEFINE_SEMAPHORE(hyperv_mmio_lock); @@ -1091,6 +1094,12 @@ static int vmbus_acpi_remove(struct acpi_device *device) struct resource *next_res; if (hyperv_mmio) { + if (fb_mmio) { + __release_region(hyperv_mmio, fb_mmio->start, + fb_mmio->end - fb_mmio->start + 1); + fb_mmio = NULL; + } + for (cur_res = hyperv_mmio; cur_res; cur_res = next_res) { next_res = cur_res->sibling; kfree(cur_res); @@ -1100,6 +1109,30 @@ static int vmbus_acpi_remove(struct acpi_device *device) return 0; } +static void vmbus_reserve_fb(void) +{ + int size; + /* + * Make a claim for the frame buffer in the resource tree under the + * first node, which will be the one below 4GB. The length seems to + * be underreported, particularly in a Generation 1 VM. So start out + * reserving a larger area and make it smaller until it succeeds. + */ + + if (screen_info.lfb_base) { + if (efi_enabled(EFI_BOOT)) + size = max_t(__u32, screen_info.lfb_size, 0x800000); + else + size = max_t(__u32, screen_info.lfb_size, 0x4000000); + + for (; !fb_mmio && (size >= 0x100000); size >>= 1) { + fb_mmio = __request_region(hyperv_mmio, + screen_info.lfb_base, size, + fb_mmio_name, 0); + } + } +} + /** * vmbus_allocate_mmio() - Pick a memory-mapped I/O range. * @new: If successful, supplied a pointer to the @@ -1261,8 +1294,10 @@ static int vmbus_acpi_add(struct acpi_device *device) if (ACPI_FAILURE(result)) continue; - if (hyperv_mmio) + if (hyperv_mmio) { + vmbus_reserve_fb(); break; + } } ret_val = 0;