[PATCH 1/2] ARM: tegra: add Acer Chromebook 13 device tree

[Stephen Warren]

On 08/13/2014 11:37 AM, Olof Johansson wrote:
> On Wed, Aug 13, 2014 at 10:31 AM, Stephen Warren <swarren at 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 at 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...