Received: by 2002:ac0:b7d5:0:0:0:0:0 with SMTP id v21csp2637ime; Thu, 28 Jul 2022 14:41:54 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tjasJIVAk7Af0cziXBDrkpbtOB16LKnUFrAF+CfjMKduK0IgeGosKWs8ZOO9XWqpgFhg0x X-Received: by 2002:a17:907:2c57:b0:72b:32a8:7afc with SMTP id hf23-20020a1709072c5700b0072b32a87afcmr617604ejc.129.1659044514199; Thu, 28 Jul 2022 14:41:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659044514; cv=none; d=google.com; s=arc-20160816; b=bEppsyuGmlZjrOf4fodjYO832QObSexLDNsUFoyhOVfImxPB12oaOn/aLjAITp0qum s8uQEf5LJTD3NHSrlxNGAAIV+dwSErGG1IPSPQmS+W30wU+W9v8JMRjfcveS7pkHE3r2 H5+qjFB5gLA0UJJLJEZsFt+M9TgzMegtSuztA+ITgUlv+FqatF7oqTivhn+g4JvS8zcr NzeI5wXzy5fBeHCciw84z6kns6j80KQDgb8PfrBTK/vIxHiGq+Zi2nu9okUT73kPq0nn U4gKmf1HMU81ZxwGR6wCvAJiR6XCAfiET7E0weiGMxqSIPHFmKLefuA0dQaI5enQ6030 ZRFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=jAkPCigVLHrBtqVHphR26WDxi2DiUpnm1/Y0dqLKCmQ=; b=SVgj2Zj3M+JDD0h695DIIAoAORKXtERpmxXor9xlYIQrGd2imhy/Kuwe5JUg2hozY6 F7Soa8lWfSVVCQfeLQ8evLsjg++rF718AsYaZ7SCWikF0ndXT5KOXiWoikZA8a+MAbu+ QfJJdpAw7v0DNO4b5WNhJKQUbwE7+cx/nZl4RqnEeI1PPpESP1VoaTPmlX/+Znf1YqrG eaV39tBqheLq4g3IC9QkUUNdLeIFUJzVnTHAOz9IMeFCwoLBEN4LH8ASNCwAtoAgIjy1 fT5S3l6fqF/uctjaU05lvAszGQh0KConVIhRivA6tPxX4beiuCwQ5pSUgA0AQaB4S62/ dDNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=KbVm0qMV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v25-20020a50d099000000b0043bc31ac7d0si1708581edd.211.2022.07.28.14.41.26; Thu, 28 Jul 2022 14:41:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=KbVm0qMV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230357AbiG1VUi (ORCPT + 99 others); Thu, 28 Jul 2022 17:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229620AbiG1VUf (ORCPT ); Thu, 28 Jul 2022 17:20:35 -0400 Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA5DB51434; Thu, 28 Jul 2022 14:20:34 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id ss3so5207032ejc.11; Thu, 28 Jul 2022 14:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=jAkPCigVLHrBtqVHphR26WDxi2DiUpnm1/Y0dqLKCmQ=; b=KbVm0qMVYx6vAxplpGdfXideOWadbCD17AoB6s1oPdJt9SKVU6HKNYR+4upp5Hraox rKn4Zxp0+fUK/toeW5i8cJnWIhfI0ZlJoGYsTejB23pW7LPgvi2BEHFLsCJ30EI6/tpC Ub2FuHYTmWrmJiwVXW5rd62zdJeSf3dY11EDMoJeJs90LjYKh3CbamhFS7B6ycXjB3kp L35BWmWGVi7yBMK/dodfGmDAXhcPMSzTNNe8Eu9EKUMyWYxlTEztLZ+xLdQy1jL+hyX1 lt6JMpN1t2Uam6JuAofdK4MkGDtJ7PppBxIsmz5MPyCUsCNCQeKHqF/tMphkBPD43xWL Nlzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=jAkPCigVLHrBtqVHphR26WDxi2DiUpnm1/Y0dqLKCmQ=; b=XDew0GcjYuavl/cd3wQcgFkuf1xZmb9gBt9MFhTiWhmOTlcvOvQ2AQ5P/IppKurunR K3hrIcICoW7sgeieFzXqiQnm2Wi167NbpIjFV3tmBsnhFuecw75G/KpptR4TkgyHngaN WMcTn6qZTQDbfFt6nUdd9uJct5r7S4a8Sk9Aa+pkUMKyBRebZCAv7KzEI18/A8bmclE/ wgIyg1MM+GWTGzxlatV0LlZcU4IRMp6TYTwp+Bp6lT9vHU0XZ84iKj9hU9JO2aLk4rRM LghoYj+6pB42phIVM9dxV6X3fY5jNNViIpa1aMDXEmVhTdxTGyop8km/uBHZJfA/1g2P Egag== X-Gm-Message-State: AJIora+ZwR2RRYoMFm5nYsb6LoVXg7bVzWfefQ2pFOWEQ0fLjU4pMXOm zjG3GI4/0LPhcMd68o5TfTD6k7EwpEOUS9cg7tg= X-Received: by 2002:a17:907:28d6:b0:72b:7497:76b with SMTP id en22-20020a17090728d600b0072b7497076bmr559720ejc.365.1659043232735; Thu, 28 Jul 2022 14:20:32 -0700 (PDT) MIME-Version: 1.0 References: <20220728142824.3836-1-markuss.broks@gmail.com> <20220728142824.3836-3-markuss.broks@gmail.com> In-Reply-To: <20220728142824.3836-3-markuss.broks@gmail.com> From: Andy Shevchenko Date: Thu, 28 Jul 2022 23:19:55 +0200 Message-ID: Subject: Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem To: Markuss Broks Cc: Linux Kernel Mailing List , ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, Jonathan Corbet , Ard Biesheuvel , Greg Kroah-Hartman , Jiri Slaby , Helge Deller , "Paul E. McKenney" , Borislav Petkov , Andrew Morton , Kees Cook , Randy Dunlap , Damien Le Moal , Thomas Zimmermann , Javier Martinez Canillas , Michal Suchanek , Andy Shevchenko , Arnd Bergmann , Wei Ming Chen , Bartlomiej Zolnierkiewicz , Tony Lindgren , Linux Documentation List , linux-efi , "open list:SERIAL DRIVERS" , "open list:FRAMEBUFFER LAYER" , dri-devel , Rob Herring Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2022 at 4:32 PM Markuss Broks wrote: > > Add early console support for generic linear framebuffer devices. > This driver supports probing from cmdline early parameters > or from the device-tree using information in simple-framebuffer node. > The EFI functionality should be retained in whole. > The driver was disabled on ARM because of a bug in early_ioremap > implementation on ARM. ... > - efifb,[options] > + efifb > Start an early, unaccelerated console on the EFI > - memory mapped framebuffer (if available). On cache > - coherent non-x86 systems that use system memory for > - the framebuffer, pass the 'ram' option so that it is > - mapped with the correct attributes. > + memory mapped framebuffer (if available). If somebody passes those (legacy) options, what will happen? ... > config EFI_EARLYCON > - def_bool y > - depends on SERIAL_EARLYCON && !ARM && !IA64 > - select FONT_SUPPORT > - select ARCH_USE_MEMREMAP_PROT > + bool "EFI early console support" > + depends on FB_EARLYCON && !IA64 This doesn't sound right. Previously on my configuration it was selected automatically, now I need to select it explicitly? I mean that for me EFI_EARLYCON should be selected by default as it was before. ... > +static int __init simplefb_earlycon_remap_fb(void) > +{ > + int is_ram; + blank line. > + /* bail if there is no bootconsole or it has been disabled already */ > + if (!earlycon_console || !(earlycon_console->flags & CON_ENABLED)) > + return 0; > + > + is_ram = region_intersects(info.phys_base, info.size, > + IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE); > + is_ram = is_ram == REGION_INTERSECTS; Was it in the original code? Otherwise, I would go with plain conditional: if (region_intersects()) base = ... else base = ... > + info.virt_base = memremap(info.phys_base, info.size, > + is_ram ? MEMREMAP_WB : MEMREMAP_WC); > + > + return info.virt_base ? 0 : -ENOMEM; > +} ... > +static void simplefb_earlycon_write_char(u8 *dst, unsigned char c, unsigned int h) > +{ > + const u8 *src; > + int m, n, bytes; > + u8 x; > + > + bytes = BITS_TO_BYTES(font->width); > + src = font->data + c * font->height * bytes + h * bytes; > + > + for (m = 0; m < font->width; m++) { > + n = m % 8; > + x = *(src + m / 8); > + if ((x >> (7 - n)) & 1) > + memset(dst, 0xff, (info.depth / 8)); > + else > + memset(dst, 0, (info.depth / 8)); > + dst += (info.depth / 8); > + } > +} Wondering if we already have something like this in DRM/fbdev and can split into a generic helper. ... > + ret = sscanf(device->options, "%u,%u,%u", &info.x, &info.y, &info.depth); > + if (ret != 3) > + return -ENODEV; Don't we have some standard template of this, something like XxYxD, where X, Y, and D are respective decimal numbers? -- With Best Regards, Andy Shevchenko