From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/2] ARM: tegra: add Acer Chromebook 13 device tree
Date: Wed, 13 Aug 2014 14:17:08 -0600 [thread overview]
Message-ID: <53EBC7C4.4050601@wwwdotorg.org> (raw)
In-Reply-To: <CAOesGMgeLbuURwA1VVxkLp=vH9PB_VdUHFJthH=ae-_ZDVYyAA@mail.gmail.com>
On 08/13/2014 11:37 AM, Olof Johansson wrote:
> On Wed, Aug 13, 2014 at 10:31 AM, Stephen Warren <swarren@wwwdotorg•org> wrote:
>> On 08/13/2014 11:23 AM, Olof Johansson wrote:
>>>
>>> On Wed, Aug 13, 2014 at 10:10 AM, Stephen Warren <swarren@wwwdotorg•org>
>>> wrote:
>>>>
>>>> On 08/12/2014 07:56 PM, Dylan Reid wrote:
>>>>>
>>>>>
>>>>> 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 1366x768 models. I haven't tried on the HD systems
>>>>> yet.
>>>>>
>>>>> WiFi does not yet work, 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 refresh and power at the same time.
>>>>
>>>>
>>>>
>>>>> diff --git a/arch/arm/boot/dts/tegra124-big.dts
>>>>> b/arch/arm/boot/dts/tegra124-big.dts
>>>>
>>>>
>>>>
>>>> I think we need to include the SKU name in the filename and compatible
>>>> value
>>>> below, or at least plan out that for other SKUs, we'll add the SKU name
>>>> on.
>>>>
>>>>
>>>>> +/ {
>>>>> + model = "Google Big";
>>>>> + compatible = "google,nyan-big", "nvidia,tegra124";
>>>>
>>>>
>>>>
>>>> I think it'd be more user-friendly if the filename and compatible value
>>>> more
>>>> obviously tied to the end-user-visible product name.
>>>
>>>
>>> We didn't prefix the reference platform on the very first one we
>>> shipped (snow), but for the peach platforms we used peach-pit and
>>> peach-pi. Those had different SoCs inside (albeit very similar ones),
>>> so there was a reason for separate DTS files.
>>>
>>> Here, we should probably prefix with nyan (so tegra124-nyan-big.dts).
>>> Users have shown themselves to be quite happy to use the internal
>>> names, they also tend to be less confusing (since we can't rely on the
>>> vendor to rename the product when the internals change, so we would
>>> need a separate namespace anyway).
>>
>>
>> I can see that the vendor might change the internals without changing the
>> product name. That kind of thing happens too frequently across all kinds of
>> products. So, there are certainly disadvantages using consumer marketing
>> names here.
>>
>> Presumably though the name "big" would no longer apply to any modified HW?
>> Hence, I can't understand the need to say "nyan-big" rather than just "big".
>> Is "nyan-" really needed to fully qualify the name? Also, the board isn't a
>> Nyan, albeit the design may have been strongly derived from the reference
>> board named Nyan.
>
> it's more about partitioning the namespace and showing similarities
> (nyan-big and nyan-foo might be able to share a common dtsi for most
> of the platform, for example).
I don't think the files need to have a common prefix to include common
content.
In other words, assuming the naming made sense, the following would be
fine if it represented reality:
tegra124-nyan.dtsi represents common parts of a reference design
tegra124-foo.dts includes tegra124-foo.dts
tegra124-bar.dts includes tegra124-foo.dts
> See https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chromeos-3.10/arch/arm/boot/dts/
> for how it's done in the product tree (some of those bindings are of
> course divergent from upstream, so it's more about the file structure
> in this case).
I've actually disliked the fact that the Venice2 board was represented
as tegra124-nyan-rev0.dts rather than tegra124-venice2.dts there...
next prev parent reply other threads:[~2014-08-13 20:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 1:56 [PATCH 1/2] ARM: tegra: add Acer Chromebook 13 device tree Dylan Reid
2014-08-13 8:53 ` Thierry Reding
2014-08-13 16:23 ` Andrew Bresticker
2014-08-13 16:51 ` Olof Johansson
2014-08-13 16:57 ` Stephen Warren
2014-08-13 16:51 ` Stephen Warren
2014-08-13 16:55 ` Olof Johansson
2014-08-13 17:04 ` Andrew Bresticker
2014-08-13 17:12 ` Stephen Warren
2014-08-13 17:17 ` Andrew Bresticker
2014-08-13 18:42 ` Dylan Reid
2014-08-13 17:10 ` Stephen Warren
2014-08-13 17:23 ` Olof Johansson
2014-08-13 17:31 ` Stephen Warren
2014-08-13 17:37 ` Olof Johansson
2014-08-13 20:17 ` Stephen Warren [this message]
2014-08-13 19:07 ` Dylan Reid
2014-08-13 19:56 ` Stephen Warren
2014-08-14 8:40 ` Dylan Reid
2015-01-13 17:49 ` Tomeu Vizoso
2015-01-14 0:32 ` Dylan Reid
2015-01-14 7:02 ` Tomeu Vizoso
2015-01-15 7:50 ` Thierry Reding
2015-01-15 12:18 ` Tomeu Vizoso
2015-01-15 17:18 ` Stephen Warren
2015-01-19 9:01 ` Tomeu Vizoso
2015-01-19 19:29 ` Andrew Bresticker
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=53EBC7C4.4050601@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