From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2137BC433EF for ; Fri, 17 Sep 2021 11:29:25 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 97ED6611F2 for ; Fri, 17 Sep 2021 11:29:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 97ED6611F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7E5CE83216; Fri, 17 Sep 2021 13:29:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=gmx.net header.i=@gmx.net header.b="J8xDQhlX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7E8A4831C8; Fri, 17 Sep 2021 13:29:20 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9124E831C8 for ; Fri, 17 Sep 2021 13:29:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1631878154; bh=wK5AxeM1mTAnsvC+hl+MnbhVKJRlKVYwCfLuTP1e19g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=J8xDQhlXGp8q/zsymz4iyxn6BuYstos/fsV3cB0wP7/A9Qz9Xm7+m8z1bia6qtGe5 QIyJQqr2WyI2UPzhPV/0qZLiYaGI3Luprddc2GPobRuTGujNxh2353qTIdA95R6oXe RS31rU6F9zusuqPjYNk72ONaHIZOYk32ao9DtwTY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.203.198] ([46.114.170.73]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MUXtS-1mII7V3Vvk-00QSot; Fri, 17 Sep 2021 13:29:14 +0200 Subject: Re: [PATCH 2/3] efi_loader: GOP: Add 30bpp support To: Mark Kettenis Cc: kettenis@openbsd.org, u-boot@lists.denx.de, agust@denx.de, agraf@csgraf.de References: <20210916130117.20894-1-kettenis@openbsd.org> <20210916130117.20894-3-kettenis@openbsd.org> <561465f19c71ab5c@bloch.sibelius.xs4all.nl> From: Heinrich Schuchardt Message-ID: <77fcfc8f-ecb6-d503-66b2-d4015b04072e@gmx.de> Date: Fri, 17 Sep 2021 13:29:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <561465f19c71ab5c@bloch.sibelius.xs4all.nl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:aDyz18B2G3zSV2Cl7cK7Mn60xUVhTzIuA4d58vWgKoRx/ivlrEd BJRZxm5i9a3xlTD09vY2lv9qhAmMIeZt6739Zbh6qoNJaR3e7euSqPT8TJ6VxI1r5JeipY9 6Jih7yLy0udGKt5m5JnJieZSigHSmjxYeWu36o4X898COpL/ezCymBgpf7/y0w+b8nX6EJx U99lp+xfbAkmGTiGkybrQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:aA0PtFQ3XfM=:yIneCOunDccf+e3TYYJt2w shaxj5C9puLBDApRkcB2SrWU7BytqdTvYyyc20Mu/02Wq2bNPB9iQnH3KcVoUrRPTUOKia9MC aZ/DJYhMJl09XFtTIz0SObG9mixNcpjD+5/XKVNRuz7y9SWBj+K0hQ/EJyk2oW+z4ybMCrX9D S0rqgp3bw8yXn5JvjVIbFuL98OsT++Wau2uySHJN3I3dfuSUyLMs70NSZnYm4JA/5qFF+hZbU 3lAyzaaIQ3gJjOgKHzVZJziowfNjDMIycpajIwfSzLIpuqPWmxDg/yhg/enR1s2OCnojURpC1 ZRo1miHb7Ch7JwXcHO37QMNFte46J9xs0tf5ztZPLaejdp5kfE+4as59dTDfaR68PWZweBqKq dm0ceOQHyTtnVHnYf8FZDtrLd4zPOUZENqD0D/rYdmvoVVW36Tco9q81EKOGf0QaabqtW0aHM smFCc4VSMYK5eZYhWAD48f3arUg5n1XhWimjkMURnU+JXpTqdNlbloNgbBdaw0viJ9XDdf97i m8U3emxV2lGS6+1QD5Tgb7fhEAZZOHyNv95kcaXPCf8B4KRSeUSv77+MqWLt/wWG5YNdNQBlC 2wCX/EuTtSnEychVOwraasLLR1H6ajDGGBryXp1dJmsgEoS6aoYHZDLyF2WyHisVBsejcZp95 SXDw+6S5ZOMS7Y1KxsoOGBfi4ogc3FWFnXRhPWleB73J9h2b4gySA9PtLJATomeq6SdxCg9nz iTHwMWFslXt+ZTabWM0PIk0+tdqi15LseV3jtm+rmBfpex3iceiqPKSkOEfpVqjO6WcCCBeXC bLbOEz0Z3eKYGZs1UlM05BgI7Bo5m9lZa+kJ9djk2iavyjBDDjKSONUDDqWEtnzHYCqpSJ1/B 0mi6hAI0BFP7SKtGLZSXTwtkfErvOoJYkt2VERV8VnL6tPX9lO9wbdazjvGPmzSfYRm+yvnAI mD8n4sfD3+O84l+ZiFIr9cZMxMnnuYbwwtyiY/frkiY+RLGVrADGyXpdsJJVk23uMByq0MhT4 zflQJf1CjIZjskefb7mykmOwd7UDCjkQVZhX78WqrzSyMdk4DoXjBAyKLqsjzhTJBpKOXDn0w jElIwJ6Y4/LicU= X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 9/17/21 11:23 AM, Mark Kettenis wrote: >> From: Heinrich Schuchardt >> Date: Fri, 17 Sep 2021 04:56:31 +0200 > > Hi Heinrich, > >> On 9/16/21 3:01 PM, Mark Kettenis wrote: >>> Provide correct framebuffer information for 30bpp modes. >> >> This is not enough to get a correct GOP implementation for the 30bpp mo= de. >> >> Have a look at efi_gop_pixel efi_vid16_to_blt_col() and >> efi_blt_col_to_vid16() and where they are used. > > Ah right. This does indeed not support EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt= () > correctly. I shouldn't be too hard to translate between XRGB2101010 > and XRGB8888. Any ideas how I could test that code? setenv efi_selftest block image transfer bootefi selftest should show an animated submarine with yellow portholes similar to https://gist.github.com/xypron/7e1f73408465da71e3ef946250e76776#file-sub-p= ng Best regards Heinrich > >>> Signed-off-by: Mark Kettenis >>> --- >>> lib/efi_loader/efi_gop.c | 10 ++++++++++ >>> 1 file changed, 10 insertions(+) >>> >>> diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c >>> index 1206b2d7a2..42bf49b184 100644 >>> --- a/lib/efi_loader/efi_gop.c >>> +++ b/lib/efi_loader/efi_gop.c >>> @@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *thi= s) >>> >>> switch (gopobj->bpix) { >>> #ifdef CONFIG_DM_VIDEO >>> + case VIDEO_BPP30: >>> case VIDEO_BPP32: >>> #else >>> case LCD_COLOR32: >>> @@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void) >>> switch (bpix) { >>> #ifdef CONFIG_DM_VIDEO >>> case VIDEO_BPP16: >>> + case VIDEO_BPP30: >>> case VIDEO_BPP32: >>> #else >>> case LCD_COLOR32: >>> @@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void) >>> #endif >>> { >>> gopobj->info.pixel_format =3D EFI_GOT_BGRA8; >>> +#ifdef CONFIG_DM_VIDEO >> >> This symbol is not 30bpp specific. Is there a Kconfig variable that we >> can use to hide 30bpp support where it is not needed? > > I quite deliberately didn't add a separate config option for 30bpp as > there is very little code that is added to the already existing 32bpp > code. In a sense 30bpp is just a different submode of the 32bpp > support with just a different color map, so I thought it made sense to > group it under CONFIG_VIDEO_32BPP. I did initially consider adding a > separate config option for it, but it quickly turns into an #ifdef > maze that makes it hard to understand the code. > > The CONFIG_DM_VIDEO check is just there to make sure the 30bpp is only > offered in the DM model. Based on recent discussions I expect the > !CONFIG_DM_VIDEO case to disappear in the near feature so adding 30bpp > support for the non-DM case doesn't make sense. > > The EFI GOP code currently doesn't check the CONFIG_VIDEO_BPP16 and > CONFIG_VIDEO_BPP32 defines to see which of these modes are enabled > within U-Boot, so we don't "hide" 16bpp support on platforms that just > support 32bpp either. > >> Which modes does the M1 support? > > We're not sure. It does support at least 8-bit (32bpp) and 10-bit > (30bpp) color depth modes. But the firmware tends to come up with > 10-bit color depth whenever it can and I'm not planning to add support > for changing the framebuffer mode on the M1, since the interface to do > that is "interesting" [1]. > > [1] See Alyssa Rozenzweig's talk at XDC 2021, > https://www.youtube.com/watch?v=3DuTZISTjqy9Q >> >>> + } else if (bpix =3D=3D VIDEO_BPP30) { >>> + gopobj->info.pixel_format =3D EFI_GOT_BITMASK; >>> + gopobj->info.pixel_bitmask[0] =3D 0x3ff00000; /* red */ >>> + gopobj->info.pixel_bitmask[1] =3D 0x000ffc00; /* green */ >>> + gopobj->info.pixel_bitmask[2] =3D 0x000003ff; /* blue */ >>> + gopobj->info.pixel_bitmask[3] =3D 0xc0000000; /* reserved */ >>> +#endif >>> } else { >>> gopobj->info.pixel_format =3D EFI_GOT_BITMASK; >>> gopobj->info.pixel_bitmask[0] =3D 0xf800; /* red */ >>> >> >>