Re: [PATCH v1 1/3] ARM: dts: am335x-bone: add support for beaglebone NAND cape

[Nishanth Menon <nm@ti.com>]

On 03/13/2014 01:19 AM, Gupta, Pekon wrote:
[..]
>> diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>> new file mode 100644
>> index 0000000..7ab088d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
>>
> From discussions, option I could think are..
> 
> (a) NAND cape node added in both 'am335x-bone.dts' and
>    'am335x-boneblack.dts' but "disabled" by default.
> 
> (b) NAND cape node in new '.dts' file (as mentioned above), and generate
>    a separate blob individual for cape.
> 
> (c) NAND cape node in existing 'am335x-bone-common.dtsi', "disabled"
>    by default. But there is no guarantee that future boards remain
>    compatible and same 'common_xx.dtsi' can be reused later.
> 
> I'll wait for Tony/Benoit-C. to decide on what suits them, as they are the
> ones who have to maintain all these. Tony ?
> 

Key for us is that we'd have to live with what ever we introduce in
the interest of backward dtb compatibility. both (a) and (c) requires
hand modification by user of nand cape - considering this might be the
strategy for "most common capes", we might end up with confusing
entries that in many cases will require additional documentation
example: option a, c: consider both audio cape (which needs hdmi
disabled) and nand cape (which needs mmc2 disabled) - how'd the user
know which entries to enable/disable for the user of the cape -
documentation needed and potentially user error prone implementation
as well.

There is as well a option (d) where we wait for FDT overlay to mature,
write up a resource manager and support all level capes.

-- 
Regards,
Nishanth Menon