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 B265FC433F5 for ; Mon, 14 Mar 2022 22:38:22 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 4DC0E83991; Mon, 14 Mar 2022 23:38:20 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com 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=konsulko.com header.i=@konsulko.com header.b="rKnR+Xft"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 29BCA83B67; Mon, 14 Mar 2022 23:38:18 +0100 (CET) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 0517D83989 for ; Mon, 14 Mar 2022 23:38:13 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf2f.google.com with SMTP id im7so13741985qvb.4 for ; Mon, 14 Mar 2022 15:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=TUQ1xz6UNhSTGj2a6nn/+VEwheIyR0O/MHibJEud36o=; b=rKnR+XftwEHogCo9S7qVaFOM1LKByg8ucVcvjDPu+aak8FEkc1Z0ONlf6/y2JViFaf i8RJ32jYsRLA3vjbZObm6QGfuDKnfp9mdpClnSnMvS+h+Gw6RBVi95hbzQ67r7Ujze6o gYJ1aI9iTGB6hA45ZPzwcb8W+wbOxg8R2oRhk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=TUQ1xz6UNhSTGj2a6nn/+VEwheIyR0O/MHibJEud36o=; b=kIMTm6typniebpKZoyMIC6fs737u22IQ7dRoUFZKEh/mNonumZc5AefeuBd+il0SC6 j3uV2pVc+Qe5ijEd5Atb6AEMBGPchA3CECdzLg4HeQWP/k6YPhIPznYLGv/g7Uv05v1I cctekTWRb3Os2rXZeYyiuCAUN3EZtFFXOrkNL2zM0Nn9JWYRQZ9TB6Cm54eqYNiBqk9C x4gOCFTqx7xyqHiV+5AH97hI+mAGKaLoiZrSLUgOEJbLxFCbFHADUxUxRLJn8bsvM83d T8qNIYv8IGWYiPrxBRBiR9xtKNcyEu+iG55bSYCZyConIR+WqX01187pQZumOZM5fKPz Ce9g== X-Gm-Message-State: AOAM533OIxAPLorE/MANbWpyrxQt3cxGBdJAJwN1cFHnFKeFkeefDwJR 5MB74UOLuXSo84fkEQMNvhFKJw== X-Google-Smtp-Source: ABdhPJwTtBu3ehBRpzcnHGFBe08l1kqqttU4OQJsiCu+8OGIy3wcH3lLZib5mnOoU0PKUjph4lAj8g== X-Received: by 2002:a0c:be8f:0:b0:42c:5083:c6d2 with SMTP id n15-20020a0cbe8f000000b0042c5083c6d2mr19601885qvi.86.1647297491750; Mon, 14 Mar 2022 15:38:11 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-2ef0-5dff-fedb-a8ba.res6.spectrum.com. [2603:6081:7b01:cbda:2ef0:5dff:fedb:a8ba]) by smtp.gmail.com with ESMTPSA id e7-20020ac85987000000b002e1b7fa2201sm9088068qte.56.2022.03.14.15.38.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Mar 2022 15:38:10 -0700 (PDT) Date: Mon, 14 Mar 2022 18:38:09 -0400 From: Tom Rini To: Simon Glass Cc: =?iso-8859-1?Q?S=F6ren?= Moch , Stefano Babic , Fabio Estevam , U-Boot Mailing List Subject: Re: [PATCH 2/2] board: tbs2910: Convert to DM_SERIAL Message-ID: <20220314223809.GT9986@bill-the-cat> References: <20220314082626.96395-1-smoch@web.de> <20220314082626.96395-2-smoch@web.de> <20220314182829.GK9986@bill-the-cat> <0774d566-5c4b-28be-9254-dfadd27c7f40@web.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+qeiGE2Ip5triyhT" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett 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 --+qeiGE2Ip5triyhT Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2022 at 04:20:43PM -0600, Simon Glass wrote: > Hi S=F6ren, >=20 > On Mon, 14 Mar 2022 at 15:51, S=F6ren Moch wrote: > > > > Hi Simon, > > > > On 14.03.22 20:37, Simon Glass wrote: > > > Hi Soeren, > > > > > > On Mon, 14 Mar 2022 at 13:22, Soeren Moch wrote: > > >> > > >> On 14.03.22 19:28, Tom Rini wrote: > > >>> On Mon, Mar 14, 2022 at 12:24:36PM -0600, Simon Glass wrote: > > >>>> Hi Soeren, > > >>>> > > >>>> On Mon, 14 Mar 2022 at 02:26, Soeren Moch wrote: > > >>>>> ... to get rid of the build warning. > > >>>>> Unfortunately we still need the board specific serial pin init co= de. > > >>>>> Otherwise the first boot messages over the serial console are los= t. > > >>>>> > > >>>>> Signed-off-by: Soeren Moch > > >>>>> --- > > >>>>> Cc: Stefano Babic > > >>>>> Cc: Fabio Estevam > > >>>>> Cc: Tom Rini > > >>>>> Cc: Simon Glass > > >>>>> Cc: u-boot@lists.denx.de > > >>>>> > > >>>>> The whole purpose of DM is somewhat defeated when we still need b= oard > > >>>>> specific initializations. Any ideas how we can get all boot messa= ges > > >>>>> without board specific inits? 'u-boot,dm-pre-reloc;' in the uart = device > > >>>>> tree node did not help. > > >>>> You can put that in your serial driver, perhaps? Or in the initial= SoC > > >>>> init code? > > >> Why should I do so? The whole point of DM is initializing devices fr= om > > >> DT. And when I wish to do so pre-relocation, it is advertised in DM = to > > >> add 'u-boot,dm-pre-reloc;' for this purpose. I tried, it did not wor= k. > > >> And this is nothing closely related to the serial driver itself, I j= ust > > >> want the pin setup running pre-relocation and not as late as it is > > >> running now under DM_SERIAL. > > > If you have a pinctrl driver it will be used. I don't really > > > understand your problem. > > My problem is that pin initializations come too late (just before the > > "Core" boot message). > > Apparently I have a pinctrl driver, otherwise the pin init would not be > > done at all, I guess. >=20 > Who knows, why don't you check? >=20 > > >> I also do not want to run this pin setup twice (first in board or SoC > > >> code and again by DM_SERIAL later). Maybe I miss something obvious, = but > > >> duplication of the setup code cannot be a proper solution. > > > Well the pinctrl will be triggered before relocation and after, if > > > enabled. We could solve that but have not tried. > > My problem is not runtime, if initialization is done twice from the same > > code this is probably OK. In my setup pins are _not_ initialized before > > relocation, when not done in board_early_init_f() "by hand", which I > > would like to avoid since this results in code duplication. > > Do I need to enable the before-relocation part somewhere? When yes, how > > exactly? 'u-boot,dm-pre-reloc;' in the uart DT node (as documented) did > > not work. >=20 > You need your driver to be bound before relocation (so needs the tag > as you say). The infrastructure is all there and works on other > boards. It is strange that you don't use SPL, though. How do you init > the DRAM? Probably through the DCD script that CONFIG_IMX_CONFIG sets. > You could enable the debug UART as a starting point, if you don't have > JTAG debugging, since that will allow you to figure out why your > pinctrl driver is not being run. >=20 > In the unlikely event that it helps, see the diff below that was > enough to get the serial going on an mx6 board in SPL about 2 years > ago (so the tags should work the same for U-Boot proper before > relocation). >=20 > If the error checking is working correctly and people have not just > make drivers return 0 when something goes wrong, you can normally > figure out which driver is missing. >=20 > new file mode 100644 > index 00000000000..b83881780c3 > --- /dev/null > +++ b/arch/arm/dts/imx6q-snappermx6-u-boot.dtsi > @@ -0,0 +1,22 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright 2020 Designa Electronics Ltd > + */ > + > +/ { > + chosen { > + stdout-path =3D &uart5; > + }; > +}; > + > +&aips2 { > + u-boot,dm-pre-reloc; > +}; > + > +&soc { > + u-boot,dm-pre-reloc; > +}; > + > +&uart5 { > + u-boot,dm-pre-reloc; > +}; > diff --git a/arch/arm/dts/imx6qdl.dtsi b/arch/arm/dts/imx6qdl.dtsi > index e4daf150881..33e636b2d31 100644 > --- a/arch/arm/dts/imx6qdl.dtsi > +++ b/arch/arm/dts/imx6qdl.dtsi > @@ -139,7 +139,7 @@ > interrupts =3D <0 94 IRQ_TYPE_LEVEL_HIGH>; > }; >=20 > - soc { > + soc: soc { > #address-cells =3D <1>; > #size-cells =3D <1>; > compatible =3D "simple-bus"; > @@ -913,7 +913,7 @@ > }; > }; >=20 > - aips-bus@2100000 { /* AIPS2 */ > + aips2: aips-bus@2100000 { /* AIPS2 */ > compatible =3D "fsl,aips-bus", "simple-bus"; > #address-cells =3D <1>; > #size-cells =3D <1>; >=20 >=20 > > >>>> Another recent way (in -next) is to use events to monitor the > > >>>> EVT_DM_PRE_PROBE event for the serial driver. > > >> I can monitor the probe event, OK. But how can this solve my problem? > > >> Again, maybe I miss something obvious, please tell me when I do so. > > >>> It's just the same thing every single imx platform is doing. > > >>> > > >> Sorry, I don't understand what you mean here. The reference platform= for > > >> my board is mx6sabresd. This is not converted to DM_SERIAL yet. Most= (?) > > >> imx boards use SPL, pin setup is different there. > > >> I looked into imx boards with DM_SERIAL. They either removed the > > >> board-specific setup code (which results in missing early boot messa= ges: > > >> u-boot version, board name, DDR size, ...) or they are playing trick= s in > > >> SPL (not the clean and easy solution that DM promises). Maybe I miss= ed a > > >> better reference for the DM_SERIAL conversion without SPL. Can you p= oint > > >> me to such board? > > > If you want to use pinctrl in SPL, you can do all of this cleanly. If > > > you have code-size constraints, then you may want to do something like > > > rockchip, where only specific peripherals are supported in pinctrl in > > > SPL. > > I do not use SPL, only U-Boot proper. > > > > > > You could look at firefly-rk3288 (or bob/coral/jerry) which I believe > > > is done fully with driver model. > > I want a proper solution without SPL, see above. > > > Perhaps Tom has a better handle on the problem. > > "Great." You are forcing everyone in DM conversions with deadlines. This > > conversion does not work as documented. When asked for help you only > > provide answers to different questions than what was asked. And you > > conclude with "create your own solution or ask someone else", at least > > this is as I understand this. >=20 > Your expectations are way out of whack. U-Boot has supported driver > model for serial for 8 years. U-Boot relies on people digging in and > figuring out their own problems. I have converted more than a dozen > boards to driver model (I am not actually sure how many) but I am just > one person and there are over a thousand boards. >=20 > > > > All this while DM conversions only bring additional work for maintainers > > of existing boards, DM conversions always come with increased code size, > > and only in the best case everything works like before. > > > > On the other hand you complain about slow conversions and maintainers > > that wait for the very end of the deadline. Do you see the relation? > > > > > > So I ask you again, Simon. How is this DM_SERIAL conversion supposed to > > be done properly? In general and especially for imx boards without SPL? > > Or is all this as incomplete as it looks like? In this case the > > conversion probably will again last until the end of the real deadline, > > about 3 years from now. And it will be done as in this patch (with your > > Reviewed-by blessing), papering over the fact that all the old code is > > still active, only the build warning is silenced. Exactly what we want > > to avoid, bigger code not better code. I hope we can clean this up in a > > follow-up patch. >=20 > I would suggest that instead of complaining and accusing people of > things, you would be better to sit down and take a hard look at it. It > is not that difficult to figure out, if you have a debug UART or JTAG. > It looks like 50% of iMX6 boards enable DM_SERIAL so it cannot be > impossible. There really is nothing magical about driver model. It is > just a model for how drivers fit together. It still runs the same > code, just organised in a somewhat more rational way, at the cost of > some extra complexity and code size. Again, DM_SERIAL can be enabled on the board as he's already shown by setting two options, which silences the warning, increases the size and doesn't make anything better. That's likely what the other boards are doing, or they're just having some console output be missing. What would need to be set where, so that serial output isn't missing, without having to manually call setup_iomux_uart() like so many imx platforms are doing. --=20 Tom --+qeiGE2Ip5triyhT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmIvw80ACgkQFHw5/5Y0 tywQMAv8CHkHW85XUJK9cKUI+R4aQ0LfO0w3mL+cgu3mYyhO5JnkCb0FngvQsLHJ Rj1QjnQDjcqDSCvFiSDKXrnhdqrFrkyJ0i2EBoPD+2OTaq0Vaf3mrpuF5DyHhSM3 ekYsZF1/uCWdKJ/YGNYB7BbgJNCqfofVUVz5+FVOfxd7JAGjq5oiiHUk0LcdfBt+ 7TUWz0FfB1sBM/Th8aPGanlguNblGSljlZx+xUBfEsIp5k65ZSSf999muyQ1W6R3 rPWupgpd1zpDjXbDgugE2WnrXU1crW8loHcSEtKXYpLlUwDftjCAmNXMRPoeEIBJ 2WuXSKMdMkI5+nMTjLQaKmQ2ITP0DLaehzCs2uod1wxAKecV7Qx5hww/fV2M7IPD 7GtXdXRDeEymmLEm/h/SRFw6QLroQDHtg1VOWoEPokSZ1NvF/geQLFr2ldphZztc GpLyJrQtAkk/thncm29k5DIf8cTaJdgI6DkUMHaTSPkJ6hbUFEMpLjOh8/AoO6Rk 8VRqkdWR =g0QG -----END PGP SIGNATURE----- --+qeiGE2Ip5triyhT--