Hi Igor,
On 11/10/2011 6:26 PM, Igor Grinberg wrote:
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<ya...@emcraft.com>
---
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 ;-))
Yeah, but it will be less readable for my point of view. You will add
another level of include hierarchy. The point is that each time some new
variants will come with less and less feature, we will keep
de-populating the original file.
My other concern is that all these variants are handled by different
people for different products. So by having dedicated file for each
variant, each owner can handle its own stuff without messing up the
original file.
Considering that this omap3.dtsi file is under construction, we can
expect a bunch a dirty merge conflicts if different people from
different organization start adding / removing nodes at the same time.
We already faced that kind of nightmare for our existing clock / hwmod
static data files. So if we can avoid it with DT files, it will be cool.
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 ;-)
Indeed, the best is to avoid any variant :-)
I don't really know what can make it a less scary nightmare.
For my point of view, since I will have to keep hacking on that
omap3.dtsi, having some separate variant files that does not have to
touch this file will be much better.
If all these variants were already there and well defined, we might have
then decided to re-organized that by starting from a common subset.
But since everything is moving at the same time and with an unknown
target, we should minimize hacking any common file under construction.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
