Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp187123ybr; Fri, 22 May 2020 04:18:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxtLSAtGl70NTXBNK6SqLaEu1EmMKhjxe45WhyNBIUkHhHoji8v8OEfaZZZRd/mFb0GiPX5 X-Received: by 2002:a17:907:1189:: with SMTP id uz9mr7382669ejb.53.1590146318861; Fri, 22 May 2020 04:18:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590146318; cv=none; d=google.com; s=arc-20160816; b=d384WBFoVLT8cvuv9xSqN93WvXJgOpG7WwqkzD4YqEut2KUN+6IsZBqHNk4iwuNGfM //sCmXozkHCaRa0swcFuuG+Q6TOkrgX4G8/ybvikuKrPBLp6mf77LlUQ0NptP05ImbB2 C8s6wVqgrlDdgUmK7Ep1J/YZOOWVhHEgMUY6XNw2hzttoVpeKtnwfNuwHtdBTTO3VZFw YAwzL/eO3Kk6TwW6X181w+xnuG/Ck7pQFyqeR4Dhsk8rhIX6gYvgAr1LT++Pd9aTum6U 09ORpDntUqOJRCdwWrjlbh/ODJH6rx4fHGl+vtlRra0bO5a3CtVu/Jn6hnghBGBkX6mU WC1g== 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:references:cc:to:subject:from; bh=D+sxm7QyezSTd/6mnrR3Kj9TgO+UsRoNxeWl9ewZiu0=; b=saoMVN0OsjqjnqLv3FTNh67OfOXlVpWZbZTgHF8+QU5qJxndgrPEFNl3DquNb5zAiQ GAAnojBiwvs1HcMpddGuBu4sjmxcOY45ywRjv3dnW5+ihLF8fcVdjC3MlHnOV04N2QQ+ lCJF6iLIBUhi7IJ5xaXoeSK8RNGrhlQmLKyOX68dcmI9SuaOJLYrGq17C9YFgq9AWJOC llguti6arh5kYRf0mIAo0ohVC7zptLXQdw9WCnfjEzGWk5KWSw7wlPsGq6++MNITx0QP ZSV3NIdjLzvnQHKN8USIJGB5kIaY0uNoZowmBwcjiypga7KrVg9vkjPo2l5q6dm4E+DU tz7g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=muq4rwqx; 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 b17si3667238ejj.145.2020.05.22.04.18.14; Fri, 22 May 2020 04:18: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=muq4rwqx; 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 S1729204AbgEVLPg (ORCPT + 99 others); Fri, 22 May 2020 07:15:36 -0400 Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:5935 "EHLO hqnvemgate24.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728657AbgEVLPE (ORCPT ); Fri, 22 May 2020 07:15:04 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Fri, 22 May 2020 04:12:37 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Fri, 22 May 2020 04:15:03 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Fri, 22 May 2020 04:15:03 -0700 Received: from [10.40.101.63] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 22 May 2020 11:14:56 +0000 From: Nikhil Mahale Subject: Re: [PATCH v6 09/10] arm64: efi: Export screen_info To: Ard Biesheuvel CC: Michael Kelley , Arnd Bergmann , Will Deacon , 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> <4202ea20-6e51-31d3-44b1-3861798a8158@nvidia.com> X-Nvconfidentiality: Public Message-ID: Date: Fri, 22 May 2020 16:44:52 +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: [10.124.1.5] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) 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=1590145957; bh=D+sxm7QyezSTd/6mnrR3Kj9TgO+UsRoNxeWl9ewZiu0=; h=X-PGP-Universal:From:Subject:To:CC:References:X-Nvconfidentiality: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=muq4rwqxalZ5FKQF8c5wHjaw5/TQNGBmGja2Z1j0zLORzHkTBISY23J0YG3XtuyWx MQAJmBVqg2minxlYHkoTNvpFjWrgHyD8kwsOijHKn8G+Zb7MyZ0kBd93JRl8GmlDth mSaFINv8vXykIucTchvY/pX3jSH7jYJ4Sa4WSDgEFNsGseuw/0N0llHdhgU/GChvrC /c2hJ0ZDtIZb9YvKGSQMB7r0miF0B7/yU1CSUccms3VAEjyrpuf/iDmPbnq3YC2Nl2 siZbZH6yCSWCs+yo8rzhX3EmxitkFm+9l1cEcliR8+tf3McMwuU1LYnMIYMwWO8xbf CN3IVXKH0GvHQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/18/20 6:21 PM, Ard Biesheuvel wrote: > External email: Use caution opening links or attachments > > > On Mon, 18 May 2020 at 06:25, Nikhil Mahale wrote: >> >> On 5/13/20 7:56 PM, Nikhil Mahale wrote: >>> 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. >> >> In addition to this, even if a driver doesn't implement a framebuffer >> console, or if it does but has an option to disable it, the driver still >> needs to know whether the EFI console is using resources on the GPU so >> it can avoid clobbering them. For example screen_info provides information >> like offset and size of EFI console, using this information driver can >> reserve memory used by console and prevent corruption on it. >> >> I think arm64 should export screen_info. >> > > If there are reasons why KMS or fbdev drivers may need to access the > information in screen_info, it should be exported. I don't think that > is under debate here. > Hi Ard, thanks for your feedback. If my understanding is correct, you are agree to export screen_info. Can you provide guidance on how can we proceed here? are you willing to accept this current patch as-is or would you like me to re-submit the patch with the additional rationale provided? Thanks, Nikhil Mahale