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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id BC4CCC433F5 for ; Sun, 6 Mar 2022 14:42:25 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1779383A4F; Sun, 6 Mar 2022 15:42:23 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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; unprotected) header.d=chromium.org header.i=@chromium.org header.b="O2JXI9j8"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A600083B8D; Sun, 6 Mar 2022 15:42:20 +0100 (CET) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A1FC283A4F for ; Sun, 6 Mar 2022 15:42:16 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-vs1-xe34.google.com with SMTP id d64so8464167vsd.12 for ; Sun, 06 Mar 2022 06:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wplibB6umQ4NofBLPy8XUIShrUsJqizHRIAlBlTKXpc=; b=O2JXI9j872gajFAG2BdiBYq5gzPEm283lC36uJsxMZjBeRlPIxIenNvbzoG6OMZct3 RCqjTmFY9pRGEDS0f8Ac+MCBRaOvDuhXA1ZD9G0yVP7QFF/EIYMHdokidgQ2BJNm27fH JtKqFcYlayRJjtNQFmUxBq/Rqu28Eh4LIzfdM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wplibB6umQ4NofBLPy8XUIShrUsJqizHRIAlBlTKXpc=; b=DCuQ94xcsdDANX/Y4/AxM2SQXFYhFhLgHKXmkE11O6y/QvtS2Lp0/NHeu86XrtRjOI 5r2Sos2Ys8qXdhJLhYIkzGOPMsXoYhwcX9S6swqLsem4zNDfywdIRDgM/5Y296DBlEtl /T59Vt8EEB/nYD5TYrDQa2seOQT71JsIOkWfV0EeT3xn/rW1E7ts4Xkh3Ugq7rWVS9ao MD53uFVfv6L0zCA2nhsknE4J7e+ql2u0TtEi/7f6mcSuLtf+xLrnVBYjFhCZizW14WTt PhY/V+aYXy5BFsLw/fznBdf84xY7aoIgniF/+glw/fojS2koUtEDq/d34etsDZm/aUlD eJzg== X-Gm-Message-State: AOAM532iQmNL4sYDyjH4CUCLj1pbAhMqXNuoPTCkCm3TVpHfzbbW0rri rapD6ZZ26ceinLetuQ0KUxhFdQ1A42ztAN8vkKV5LQ== X-Google-Smtp-Source: ABdhPJyGJsDs368eTl82c3d2YkpFDgKNCJr9CmO5ShdG2jfCyJlRvnt1ayPNW1+HTwSiKSthR+cfqdYAF1K2+wsfk9Y= X-Received: by 2002:a05:6102:114b:b0:320:a22e:e7c with SMTP id j11-20020a056102114b00b00320a22e0e7cmr1439652vsg.51.1646577734746; Sun, 06 Mar 2022 06:42:14 -0800 (PST) MIME-Version: 1.0 References: <20220216204219.18539-1-pali@kernel.org> <20220217095339.7d950fe3@crub> <20220217122043.nhjd7o467pkcrnas@pali> <20220306115141.gb4y6fsgqmrtg4ce@pali> <20220306141706.k3vfxd4bhzth6duy@pali> In-Reply-To: <20220306141706.k3vfxd4bhzth6duy@pali> From: Simon Glass Date: Sun, 6 Mar 2022 07:42:03 -0700 Message-ID: Subject: Re: [PATCH] WIP: Nokia RX-51: Convert to CONFIG_DM_VIDEO To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: Anatolij Gustschin , Tom Rini , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean Hi Pali, On Sun, 6 Mar 2022 at 07:17, Pali Roh=C3=A1r wrote: > > On Sunday 06 March 2022 05:51:34 Simon Glass wrote: > > Hi Pali, > > > > On Sun, 6 Mar 2022 at 04:51, Pali Roh=C3=A1r wrote: > > > > > > PING? > > > > > > On Thursday 17 February 2022 13:20:43 Pali Roh=C3=A1r wrote: > > > > On Thursday 17 February 2022 09:53:39 Anatolij Gustschin wrote: > > > > > Hi Pali, > > > > > > > > > > On Wed, 16 Feb 2022 21:42:19 +0100 > > > > > Pali Roh=C3=A1r pali@kernel.org wrote: > > > > > > > > > > > --- > > > > > > I had to comment "return -ENOSPC;" in video-uclass.c because wi= thout it > > > > > > DM_VIDEO does not work and I do not know why. This looks like e= ither > > > > > > false-positive test or a bug in DM_VIDEO code. I have already s= et > > > > > > PRE_RELOC flag but it has no effect on that code. > > > > > > > > > > Probably the frame buffer memory allocation did not work. > > > > > Could you please try with a bind callback, i.e.: > > > > > > > > > > static int rx51_video_bind(struct udevice *dev) > > > > > { > > > > > struct video_uc_plat *plat =3D dev_get_uclass_plat(dev); > > > > > > > > > > plat->size =3D 800 * 480 * 2; > > > > > return 0; > > > > > } > > > > > ... > > > > > U_BOOT_DRIVER(rx51_video) =3D { > > > > > .name =3D "rx51_video", > > > > > .id =3D UCLASS_VIDEO, > > > > > .bind =3D rx51_video_bind, > > > > > .probe =3D rx51_video_probe, > > > > > .flags =3D DM_FLAG_PRE_RELOC, > > > > > }; > > > > > > > > Hello! It does not work too. Here is the output: > > > > > > > > U-Boot 2022.04-rc2-00002-ga2c1a9878375-dirty (Jan 01 1970 - 00:00:0= 0 +0000) > > > > > > > > OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz > > > > DRAM: Video frame buffers from 8fe30000 to 8fe30000 > > > > 256 MiB > > > > Video device 'rx51_video' cannot allocate frame buffer memory -ensu= re the device is set up before relocation > > > > > > > > If "return -ENOSPC;" is not commented then this is the last printed > > > > line. If it is commented then output continues with: > > > > > > > > video_post_bind: Claiming 130000 bytes at 8fd00000 for video device= 'rx51_video' > > > > > > > > And framebuffer is working fine like without above rx51_video_bind(= ) > > > > change. > > > > It looks like you are hard-coding the address of the video buffers. Is > > that intentional? If so, you may need to disable U-Boot's automatic > > allocation. > > This is how it works, signed bootloader which loads U-Boot initialize > and prepare framebuffer. > > > One way to do that is to set the frame buffer address and size in your > > bind() routine (post relocation) and update video_post_bind() to check > > if the address is non-zero (plat->base I mean) and skip its allocation > > if so. > > Ok, I have tried it and following change makes framebuffer in qemu > working: > > diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c > index 7d499bcec51d..f4d8d395e714 100644 > --- a/drivers/video/video-uclass.c > +++ b/drivers/video/video-uclass.c > @@ -78,6 +80,9 @@ static ulong alloc_fb(struct udevice *dev, ulong *addrp= ) > if (!plat->size) > return 0; > > + if (plat->base) > + return 0; > + Yes let's go with that. > align =3D plat->align ? plat->align : 1 << 20; > base =3D *addrp - plat->size; > base &=3D ~(align - 1); > > Is this what you mean? > > > > > > > > > > > > > > > > > Second thing is that CONFIG_VIDEO_LOGO is broken and does not w= ork even it > > > > > > is enabled in config file. I do not know why too. > > > > > > > > > > > > Any idea? > > > > > > > > > > Not yet. There were some logo related changes recently, but if I > > > > > remember correctly, I tested them on wandboard and nitrogen6q > > > > > targets and with sandbox, and logo drawing worked there. > > > > Can you be more specific than 'broken'? What is broken about it? > > Does not work, logo is not drown on the screen. See video_bmp_display() - I wonder if the particular depth you are using is not supported? Anyway you should be able to debug it there or using the bmp command. The file is drivers/video/u_boot_logo.bmp Regards, Simon