On 11/10/11 19:09, Cousson, Benoit wrote: > + devicetree ml > > On 11/10/2011 1:18 PM, Igor Grinberg wrote: >> Hi Ilya, >> >> On 11/09/11 02:12, Ilya Yanok wrote: >>> Split omap3.dtsi file into common part, OM3xxx specific part and >>> AM35xx specific part. For now the only difference is missing IVA node on >>> AM35xx. >>> >>> Signed-off-by: Ilya Yanok<yanok@xxxxxxxxxxx> >>> --- >>> arch/arm/boot/dts/am35xx.dtsi | 15 +++++++++++++++ >>> arch/arm/boot/dts/om3xxx.dtsi | 28 ++++++++++++++++++++++++++++ >>> arch/arm/boot/dts/omap3-beagle.dts | 2 +- >>> arch/arm/boot/dts/omap3.dtsi | 9 --------- >>> 4 files changed, 44 insertions(+), 10 deletions(-) >>> create mode 100644 arch/arm/boot/dts/am35xx.dtsi >>> create mode 100644 arch/arm/boot/dts/om3xxx.dtsi >> >> om3xxx name is confusing - I haven't seen this name >> in any documentation/code before... >> Am I missing something? >> >> What do you think of omap3-iva.dtsi or omap3-dsp.dtsi? > > Cannot we avoid at all hacking the original file and use instead the status = "disabled" field for any variant that will not have the functionality? This might be an option. What I thought of is splitting the original file into "atomic" (none splittable) parts and each OMAP variant will include the ones it has. This way you have all the features available and can make any mixture of them (which, probably will reflect the hardware best ;-)) > > It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file. it will be a nightmare anyway ;-) I don't really know what can make it a less scary nightmare. -- Regards, Igor. -- 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
