Thread (25 messages) 25 messages, 2 authors, 2016-09-21

Re: [PATCH 3/4] ARM: tegra: nyan-big: Include compatible revisions for proper detection

From: Jon Hunter <jonathanh@nvidia.com>
Date: 2016-09-21 07:35:57
Also in: linux-arm-kernel, linux-tegra, lkml

On 20/09/16 19:02, Paul Kocialkowski wrote:
* PGP Signed by an unknown key

Le mardi 20 septembre 2016 à 18:56 +0100, Jon Hunter a écrit :
quoted
On 20/09/16 18:53, Paul Kocialkowski wrote:
quoted
quoted
Old Signed by an unknown key
Le mardi 20 septembre 2016 à 18:41 +0100, Jon Hunter a écrit :
quoted
On 28/08/16 18:32, Paul Kocialkowski wrote:
quoted

Depthcharge (the payload used with cros devices) will attempt to detect
boards using their revision. This includes all the known revisions for
the nyan-big board so that the dtb can be selected preferably.
May be I am missing something here, but for the mainline there is only
one dtb available and so why is this needed for the mainline?
There is indeed a single dts in mainline, but depthcharge will use the
revision
to match the compatible string (e.g. it will look for google,nyan-big-rev5,
not
google,nyan-big), so we need to list them all in that single dts. Otherwise,
depthcharge will fall back to the default config, which may or may not be
suitable for nyan.
Is tegra124-nyan-big.dtb not the default?
You can't expect that to always be the case. The image format allows many
different dts to be provided, so I could easily build with multi_v7_defconfig
and have various dts for various devices in the same image, and just select a
random one as default.
Really? Sounds odd. I was hoping that tegra124-nyan-big.dtb would be a
catch all.
Here, default is really a fallback, the right one is expected to be detected by
this mechanism. And it really doesn't hurt to provide that information for
proper detection.

Note that this is done with many other cros devices in mainline (such as rk3288
veyrons).
Yes, I guess the same is true for the tegra210-smaug and we do define
all the revs for that one. May be extend the changelog comment to say
what may happen without this change and the problem that this is fixing.

Jon	

-- 
nvpublic

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help