Thread (21 messages) 21 messages, 6 authors, 2014-09-04
STALE4302d

[PATCH v2] ARM: tegra: add Acer Chromebook 13 device tree

From: Olof Johansson <hidden>
Date: 2014-08-20 13:29:14
Also in: linux-tegra

On Mon, Aug 18, 2014 at 4:43 PM, Stephen Warren [off-list ref] wrote:
On 08/18/2014 05:24 PM, Andrew Bresticker wrote:
quoted
On Mon, Aug 18, 2014 at 9:10 AM, Stephen Warren [off-list ref]
wrote:
quoted
On 08/16/2014 09:20 AM, Andreas F?rber wrote:
quoted

Hi,

Am 13.08.2014 21:14, schrieb Dylan Reid:
quoted

The Acer Chromebook 13, codenamed Big, contains an NVIDIA tegra124
processor and is similar to the Venice2 reference platform.

The keyboard, USB 2, audio, HDMI, sdcard, and emmc have been tested
and work on the 1266x768 models.  The HD models haven't yet been
tested.

WiFi does not work yet, it needs at least some PMIC changes to enable
the 32k clock.

The elan trackpad is not yet functional but hopefully will be soon as
there are patches under review.

There is also an issue on reboot because the TPM isn't reset.  It will
cause the stock firmware to enter recovery mode.  This can be worked
around by an EC-reset, press the refresh and power keys at the same
time.

quoted
quoted
diff --git a/arch/arm/boot/dts/tegra124-nyan-big.dts
b/arch/arm/boot/dts/tegra124-nyan-big.dts
new file mode 100644
index 0000000..79f1852
--- /dev/null
+++ b/arch/arm/boot/dts/tegra124-nyan-big.dts
@@ -0,0 +1,1136 @@
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include "tegra124.dtsi"
+
+/ {
+       model = "Acer Chromebook 13";
+       compatible = "google,nyan-big", "nvidia,tegra124";


In light of v1 and the above commit message referring to this as Google
Big, shouldn't this be "google,big", "nvidia,tegra124" and optionally
"google,nyan" as secondary string, independent of the new file name?


Despite this board having been derived from Nyan, it isn't Nyan, so I
don't
think Nyan should be part of any compatible value, nor a separate
compatible
value.

"google,nyan-big" is the compatible string that the bootloader on
these devices looks for.  It's also the convention we are now using
for our ARM devices, as Olof has already mentioned.

I don't understand "that the bootloader looks for"; why is the bootloader
doing anything w.r.t the compatible value in the DT that's passed to the
kernel.

Olof also mentioned that if I had any better ideas on file naming, I should
point them out. As I mentioned in response, there's zero need for all the
files or compatible values to have "nyan" in them in order to include any
common .dtsi file, which was the justification for having "nyan" in the
filename, IIRC.
Yes, I asked for input, not full veto on things that you happened to
not like. I also didn't say that we could change everything depending
on said input -- some of them might be longer-term changes that we'll
have to consider for a future project, etc. Some of them we might even
disagree on! (see below).
Again, this board *isn't* Nyan, so it should pretend that it is.
It is a derivative design of the nyan reference platform, and it is
compatible with it. It is perfectly fine to claim to be compatible
with it. I'm sorry, but you're just wrong here.


-Olof
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help