Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp569776ybk; Wed, 13 May 2020 07:28:38 -0700 (PDT) X-Google-Smtp-Source: APiQypLRy7mDHvcDy/h5Nu/9E3JknnkeZbmCj9BGa/tY9A3EombYquhiQxKWXjI9SB5vPJUkKnWd X-Received: by 2002:a17:906:7f13:: with SMTP id d19mr22562578ejr.57.1589380118438; Wed, 13 May 2020 07:28:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589380118; cv=none; d=google.com; s=arc-20160816; b=zRRLbUPC67FCR7PtiaHH6bbmqVmzTYEJKVH5SEC0wk+brP/12qvbhXZ7wMiFP6iDfS InAiQFtkzqjF2rHq7275aTYSLve+L0D8ntI4602Sjy1r3IHKnwZH7e7YL1k/6jUD++R8 alRYi3rUPlcIO4J5W+J5EJoY4lFa7+B5knOjLuXWBehe6NerT3ucusdFLcD4RfpW22MH 0tropcDupdMtxFCSU0vfy7Ze7T8BAhO/lvtAXYjOpdR8btNoYfOvv1ZFRusvUH4LcJXR EypiSDsNpKC9KNG7DpEt7RS80Lfr+WLc+hCvbLHMsq6ouxkZBDgT009yyBmvHgpsPOtn 1sTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=x1UAKVn8+/u2cz6MzDi8dZRv1jolqDgwkL4uosH9XXA=; b=iBYF7SLLj3OwofL0ng13naIXcdkKfVl4RZR0kGQwLyCffWLWPR3CA2Ckk2qWTbNvHS pmst77zS/sARSkl3aEPC3o7/jb2O9k+kx1r20HzclTeecHhtHUYYcGhkoYW5H9b1MS8k MSp84IAjfgvPPfl1LHFcbzGCxr7llUEh3DmrLYaoXp1EYY+6BDPVBMtwqwSVMDEuGNwu IM3FzZ2MSjnNyq5n4gsJ6fAE5UrHSX9ZqCpiP+spZXVW+0eQuF8WQtew1lzTyi5E4fJ0 jNZH/8iB97PcmXPwB/GYUuEh0W43TtXctHjto+lvaDlclBZNxatCdXpNvlCg10v7nMEY HMWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=cW+1fl8G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si9305899ejr.422.2020.05.13.07.28.12; Wed, 13 May 2020 07:28:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=cW+1fl8G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388986AbgEMO0a (ORCPT + 99 others); Wed, 13 May 2020 10:26:30 -0400 Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:8391 "EHLO hqnvemgate24.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388827AbgEMO03 (ORCPT ); Wed, 13 May 2020 10:26:29 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 13 May 2020 07:24:12 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Wed, 13 May 2020 07:26:28 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Wed, 13 May 2020 07:26:28 -0700 Received: from [10.40.103.138] (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 13 May 2020 14:26:19 +0000 Subject: Re: RE: [PATCH v6 09/10] arm64: efi: Export screen_info To: Michael Kelley , Arnd Bergmann CC: Will Deacon , Ard Biesheuvel , Catalin Marinas , Mark Rutland , Marc Zyngier , Linux ARM , gregkh , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , linux-efi , linux-arch , "olaf@aepfle.de" , Andy Whitcroft , vkuznets , Jason Wang , "marcelo.cerri@canonical.com" , KY Srinivasan , Sunil Muthuswamy , Boqun Feng References: <1584200119-18594-1-git-send-email-mikelley@microsoft.com> <1584200119-18594-10-git-send-email-mikelley@microsoft.com>

From: Nikhil Mahale Message-ID: Date: Wed, 13 May 2020 19:56:14 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1589379852; bh=x1UAKVn8+/u2cz6MzDi8dZRv1jolqDgwkL4uosH9XXA=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=cW+1fl8Ga69Q1QXp46sGezHshzti2A6hHcqXU68jSAv0HbHLeJQvepipXJ0eSuDBo 51KMndVzf/sPPYlWVGm/bE21jU3XJS+EeiVEM2ruDJCnu64Jz80k49jv2OjlI7Vnjj DhPtiz/99TQ94aCjvD+0pTQoBQQ/lwcbhEddYghMCPLZE9sM9eXPYXm18cFxeGfTO2 15ETxGo1tsLmjRLBCgkqhz7TYdryxI170K82U/Oez6e+yjci90BE8uVyGq0TXp/K63 ks9G06QTA88P3fNC9kzZfxZonCfJndFQz5TkuaWAKoONJmCQ+9rIQ5hxcdLWAb+Cng 7pKiTeecW804A== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/20/20 3:16 AM, Michael Kelley wrote: > From: Arnd Bergmann Sent: Wednesday, March 18, 2020 2:27 AM >> >> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley wrote: >>> From: Arnd Bergmann >>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley wrote: >>>>> >>>>> The Hyper-V frame buffer driver may be built as a module, and >>>>> it needs access to screen_info. So export screen_info. >>>>> >>>>> Signed-off-by: Michael Kelley >>>> >>>> Is there any chance of using a more modern KMS based driver for the screen >>>> than the old fbdev subsystem? I had hoped to one day completely remove >>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern >>>> architectures. >>>> >>> >>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V >>> frame buffer device. That driver builds and runs on both ARM64 and x86. >>> >>> I'm not knowledgeable about video/graphics drivers, but when you >>> say "a more modern KMS based driver", are you meaning one based on >>> DRM & KMS? Does DRM make sense for a "dumb" frame buffer device? >>> Are there any drivers that would be a good pattern to look at? >> >> It used to be a lot harder to write a DRM driver compared to an fbdev >> driver, but this has changed to the opposite over the years. >> >> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c >> or anything in drivers/gpu/drm/tiny/, but you may want to look at the >> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c, >> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c, >> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c. >> > > Thanks for the pointers, especially for the other hypervisors. > Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times. I had configured by email client incorrectly to reply. screen_info is still useful with a modern KMS-based driver. It exposes the mode parameters that the GOP driver chose. This information is needed to implement seamless or glitchless boot, by both ensuring that the scanout parameters don't change and being able to read back the scanout image to populate the initial contents of the new surface. This works today on arches which implement (U)EFI and export screen_info, including x86 and powerpc, but doesn't work on arm or arm64. As arm64 systems that implement UEFI with real GOP drivers become more prevalent, it would be nice to be have these features there as well. Thanks, Nikhil Mahale > Michael >