From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v2] ARM: tegra: add Acer Chromebook 13 device tree
Date: Tue, 19 Aug 2014 15:47:41 -0600 [thread overview]
Message-ID: <53F3C5FD.4050808@wwwdotorg.org> (raw)
In-Reply-To: <CAL1qeaFnfLDOXq07fY4xLfdRpG8FQ63ya+-0Hk+ewA1wXkLOLw@mail.gmail.com>
On 08/18/2014 06:11 PM, Andrew Bresticker wrote:
> On Mon, Aug 18, 2014 at 4:43 PM, Stephen Warren <swarren@wwwdotorg•org> wrote:
>> On 08/18/2014 05:24 PM, Andrew Bresticker wrote:
>>>
>>> On Mon, Aug 18, 2014 at 9:10 AM, Stephen Warren <swarren@wwwdotorg•org>
>>> wrote:
>>>>
>>>> On 08/16/2014 09:20 AM, Andreas F?rber wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am 13.08.2014 21:14, schrieb Dylan Reid:
>>>>>>
>>>>>>
>>>>>> 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.
>>>>
>>>>
>>>>
>>>>>> 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.
>
> The ChromeOS bootloader ("depthcharge") boots FIT images and selects
> the appropriate device-tree from the image based on the compatible
> string. On Big boards, it looks for "google,nyan-big". This only
> becomes an issue if there are multiple device-trees in the FIT image.
> If there's only a single configuration (or you chain-load U-Boot),
> then the bootloader will boot with that configuration. If you build a
> kernel image in the ChromiumOS environment, however, you'll end up
> with multiple device-trees (all those built by the kernel config at
> least) in the FIT image - this is what allows us to boot the same
> binary on different boards.
This just makes me dislike FIT (and DT ABIs) even more, although I
suppose the same issue would arise if the DTBs were stored in separate
files and looked up by filename.
I have to say this sucks, because it means that a downstream bootloader
is imposing an ABI on the mainline kernel without a chance to fix things
during upstreaming. For all other boards, we've concentrated on mainline
U-Boot as the bootloader precisely so that strange behaviour of our
downstream product kernels don't force the hand of the mainline kernel
design.
Still, I suppose I have no choice but to drop my objection here.
next prev parent reply other threads:[~2014-08-19 21:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 19:14 [PATCH v2] ARM: tegra: add Acer Chromebook 13 device tree Dylan Reid
2014-08-16 15:20 ` Andreas Färber
2014-08-18 16:10 ` Stephen Warren
2014-08-18 17:03 ` Andreas Färber
2014-08-18 23:24 ` Andrew Bresticker
2014-08-18 23:43 ` Stephen Warren
2014-08-19 0:11 ` Andrew Bresticker
2014-08-19 21:47 ` Stephen Warren [this message]
2014-08-20 5:36 ` Thierry Reding
2014-08-20 13:37 ` Olof Johansson
2014-08-20 15:25 ` Thierry Reding
2014-08-20 17:25 ` Andrew Bresticker
2014-08-20 13:29 ` Olof Johansson
2014-08-20 14:32 ` Thierry Reding
2014-08-20 15:40 ` Olof Johansson
2014-08-21 7:19 ` Thierry Reding
2014-08-18 23:05 ` Andrew Bresticker
2014-09-04 19:40 ` Stephen Warren
2014-09-04 20:33 ` Dylan Reid
2014-09-04 21:04 ` Stephen Warren
2014-09-04 21:08 ` Dylan Reid
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53F3C5FD.4050808@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox