[U-Boot] [PATCH v3 4/4] ARM: tegra: Add support for nyan board

Simon Glass
2014-11-25T16:18:12Z

Hi Stephen,

On 25 November 2014 at 09:14, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/24/2014 04:48 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 24 November 2014 at 10:28, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> On 11/23/2014 09:12 AM, Simon Glass wrote:
>>>>
>>>>
>>>> From: Allen Martin <amartin@nvidia.com>
>>>>
>>>> Nyan is a Tegra124 clamshell board that is very similar to venice2, but
>>>> it
>>>> has a different panel, the sdcard cd and wp sense are flipped, and it
>>>> has
>>>> a different revision of the AS3722 PMIC.
>>>>
>>>> This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
>>>> Tegra K1, 2GB). The display is not currently supported, so it should
>>>> boot on other nyan-based Chromebooks also, but only the device tree for
>>>> nyan-big is provided here.
>>>
>>>
>>>
>>> As Olof explained it to me, Nyan is a family of boards, of which "Nyan
>>> Big"
>>> is a particular member. In other words, "Nyan Big" is the CB5. As such, I
>>> believe the U-Boot board should be named "Nyan Big" not "Nyan", unless we
>>> expect the U-Boot support for work for the various other Nyan family
>>> boards;
>>> I believe the HP Tegra Chromebooks are also in the Nyan family. Either
>>> way
>>> though (i.e. even if nyan.c gets shared between the Acer and HP Tegra
>>> Chromebooks), I still think we want separate top-level U-Boot board names
>>> for the two, so that it's easy for people to build the right DT into
>>> their
>>> U-Boot binary for example.
>>
>>
>> What change are you requesting for this patch?
>
>
> Given Andrew's description of the board naming, I think this patch (patch
> subject/description, filenames, file content) and anything else for this
> board should call it nyan-big not nyan. The Acer Chrombook is apparently
> nyan-big, whereas plain nyan means Norrin.

OK I think there are still a few nyans, so will purge. If we end up
supporting more from this range I'd like to avoid duplicating lots of
code (ideally it would just be a different device tree). But let's
cross that bridge when we come to it.

Regards,
Simon