Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
On 11/10/11 20:07, Cousson, Benoit wrote: > 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 > --- >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. Agreed, it will be less readable, because it will be spread among several files. > You will add another level of include hierarchy. Why is adding another level of include hierarchy is a problem? > The point is that each time some new variants will come with less and less > feature, > we will keep de-populating the original file. Here you assume that it will be always *less* features and never *more*? Also, that is the reason, why I think splitting it right now to smaller pieces will do a good job for the future. > > 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. I'm not saying that we should not have a dedicated file for each variant. What I'm saying is that the dedicated file for each variant can include the "pieces" the hardware has, instead of duplicating them or disabling what it does not have. > 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. IMO, that problem can also be avoided by splitting it to smaller pieces. Don't you think so? > > 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. I don't think it falls in the same problem category, but may be I'm missing something... > >>> 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. Or split it to pieces right now, so no one will have to hack on it... > > 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. Yeah, it would be perfect, but it is never been this way and will never be... > But since everything is moving at the same time and with an unknown target, > we should minimize hacking any common file under construction. I think the design of having a common file with data does not scale. Again, having multiple files, each with data per subsystem or per an ip block, does scale and IMO will do a better job, now and in the future. This will mean that common file will only do the includes to assemble all the *right* data together. -- Regards, Igor. -- 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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 --- 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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 >>> --- >>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
+ 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 --- 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? It will be a nightmare for us to maintain a consistent OMAP3 file if every variants force us to change the original file. 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
Re: [PATCH 3/4] dts/omap3: split omap3.dtsi
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
> ---
> 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?
>
> diff --git a/arch/arm/boot/dts/am35xx.dtsi b/arch/arm/boot/dts/am35xx.dtsi
> new file mode 100644
> index 000..0dbc69d
> --- /dev/null
> +++ b/arch/arm/boot/dts/am35xx.dtsi
> @@ -0,0 +1,15 @@
> +/*
> + * Device Tree Source for TI AM35xx SoCs
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + compatible = "ti,am35xx", "ti,omap3";
> +};
> diff --git a/arch/arm/boot/dts/om3xxx.dtsi b/arch/arm/boot/dts/om3xxx.dtsi
> new file mode 100644
> index 000..e8a17dd
> --- /dev/null
> +++ b/arch/arm/boot/dts/om3xxx.dtsi
> @@ -0,0 +1,28 @@
> +/*
> + * Device Tree Source for TI OM3xxx SoCs
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "omap3.dtsi"
> +
> +/ {
> + /*
> + * The soc node represents the soc top level view. It is uses for IPs
> + * that are not memory mapped in the MPU view or for the MPU itself.
> + */
> + soc {
> + iva {
> + compatible = "ti,iva2.2";
> + ti,hwmods = "iva";
> +
> + dsp {
> + compatible = "ti,omap3-c64";
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> index 9486be6..63e4be1 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -7,7 +7,7 @@
> */
> /dts-v1/;
>
> -/include/ "omap3.dtsi"
> +/include/ "om3xxx.dtsi"
>
> / {
> model = "TI OMAP3 BeagleBoard";
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index d202bb5..2b12b0e 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -29,15 +29,6 @@
> compatible = "ti,omap3-mpu";
> ti,hwmods = "mpu";
> };
> -
> - iva {
> - compatible = "ti,iva2.2";
> - ti,hwmods = "iva";
> -
> - dsp {
> - compatible = "ti,omap3-c64";
> - };
> - };
> };
>
> /*
--
Regards,
Igor.
--
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
