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;
Date:   Tue, 1 Jun 2021 13:25:16 +0200
From:   Thierry Reding <thierry.reding@gmail.com>
To:     Dmitry Osipenko <digetx@gmail.com>
Cc:     Jonathan Hunter <jonathanh@nvidia.com>,
        Agneli <poczt@protonmail.ch>, Paul Fertser <fercerpav@gmail.com>,
        Svyatoslav Ryhel <clamor95@gmail.com>,
        linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 04/10] ARM: tegra: Add reg property to Tegra20 EMC
 table device-tree nodes
Message-ID: <YLYZHPpjZB9amRBW@orome.fritz.box>
References: <20210510202600.12156-1-digetx@gmail.com>
 <20210510202600.12156-5-digetx@gmail.com>
 <YLSpCXNtut3z8U9a@orome.fritz.box>
 <1ab11cc8-b45a-0c2d-c0c4-fa5779756c05@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="EqnHcgd+ZcjTNu1H"
Content-Disposition: inline
In-Reply-To: <1ab11cc8-b45a-0c2d-c0c4-fa5779756c05@gmail.com>
User-Agent: Mutt/2.0.6 (98f8cb83) (2021-03-06)
Precedence: bulk


--EqnHcgd+ZcjTNu1H
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 31, 2021 at 11:45:19PM +0300, Dmitry Osipenko wrote:
> 31.05.2021 12:14, Thierry Reding =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > On Mon, May 10, 2021 at 11:25:54PM +0300, Dmitry Osipenko wrote:
> >> The reg property is now specified for the emc-tables nodes in the Tegr=
a20
> >> device-tree binding. Add reg property to the EMC table device-tree nod=
es
> >> of Tegra20 board device-trees in order to silence dt_binding_check war=
ning
> >> about the missing property.
> >>
> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> >> ---
> >>  arch/arm/boot/dts/tegra20-acer-a500-picasso.dts | 4 ++++
> >>  arch/arm/boot/dts/tegra20-paz00.dts             | 1 +
> >>  2 files changed, 5 insertions(+)
> >=20
> > In retrospect we should've just used "reg" in the first place rather
> > than adding the custom "nvidia,ram-code". It's a bit redundant to have
> > both of them with the same value. I wonder if we should deprecate the
> > use of "nvidia,ram-code" and at least make the code look at the "reg"
> > property first and only fall back to "nvidia,ram-code" if "reg" does
> > not exist. We probably won't ever be able to get rid of the fallback
> > for backwards-compatibility reasons, but at least that would make the
> > intent a bit clearer.
>=20
> This may be not doable. We have Asus TF101 which doesn't use RAM code
> for the memory identification, instead it uses LPDDR chip info [1]. I
> will send the LPDDR patches later on.
>=20
> [1]
> https://github.com/grate-driver/linux/blob/master/arch/arm/boot/dts/tegra=
20-asus-tf101.dts#L1115

That DTS defines both "jedec,lpddr-manufacturer-id" and "reg" with the
same value, so we could simply use "reg" there. If you plan to support
the JEDEC properties, we'll have to add code for that anyway, so there
is no downside to first trying "reg". And we may not even need to add
support for any of those JEDEC properties if we can just use the "reg"
standard property in the first place.

> The TF101 support mostly in a completed state now, we still need to try
> to figure out why upstream kernel doesn't work using a stock Android
> bootloader, so far bootloader replacement to u-boot is required.

I think it's fine to merge support upstream if there is some sort of
bootloader that it can run with. If that bootloader is open-source like
U-Boot, the better, but I don't think we need to set the bar as high as
being able to boot with any available bootloader. There are all sorts
of reasons why the Android stock bootloader may cause things not to work
and there's probably no way to get it fixed anyway. It's similarly
possible that the kernel may need some outlandish quirk to accomodate
for that breakage and we may not want, or be able, to upstream such
quirks anyway.

So if you want to pursue making upstream Linux work with the stock
Android bootloader, that's a fine goal and I won't object, but it's not
a requirement that I will insist on before merging DTS files.

Thierry

--EqnHcgd+ZcjTNu1H
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmC2GRkACgkQ3SOs138+
s6G7XQ/+PYR7uRtcQUTZVILyxP1ZYlkd/mic87hEjc1Rnxw5HTbGq56zUAeRtSah
dUoXyv9hcCc8Ls4s8Mg0jw6xmeiOUIItemD7+mJ8GFtWpN/5QJ5Gi7wCl2Nwqqyk
O79AmwgJQou37KFhUnKTUDazLQfBQ9ouAklKPk6wH11y+5vjVp6/CdGLLOR+efBN
xF2IofEZNVNAJVOaLdw3L2wsIfUW0YgW6MrRbofYOX3Vnz0K1jUst9Wt6FqiQIIS
C9Cbbi/APTmQUxPrTgbLE8nnpRzsxT9pOvPiErv5AYL5/iXL9fpENZ5Dq9Wk8a+c
yqNaYua0CRF0VuOJCITHOHpfqZ9Z2ADv+fF2bqvavWxYnD0wDMc17hmsJvN9P8UV
5/Np8R8wVrc+hWUjXNvUvNRjdGeEXGjlATKakIc2IdsBszYVB+qFU8pOawNZKzPB
SnheKmDsqhYc5sivYItvOkP8a6JIpXpy1hfVKJv2phZ/23+4HIw+CyGvthiCJGX0
Nmb/+qfFvPYQ0zcFGQ+qN7qLWsYpMhGfiAo+/EtUfMxbmyBOZVvKd7TP9voJuunh
ux3alcGXWKEjMLgnMgU63CPvEXH7sWUA7T5pHX+RbIea2yXv6QXTyarh53KU2kOT
OvcXsJm3IQgDk7gvA6YMUlxmZvOhZgggelRuVJcUlgMCHjGqxD4=
=1La0
-----END PGP SIGNATURE-----

--EqnHcgd+ZcjTNu1H--