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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
