On 11/14/2011 10:20 AM, Stephen Warren wrote:

Peter De Schrijver wrote at Monday, November 14, 2011 9:07 AM:

quoted

On Mon, Nov 14, 2011 at 04:41:13PM +0100, Rob Herring wrote:

quoted

On 11/14/2011 09:25 AM, Peter De Schrijver wrote:

quoted

On Sat, Nov 12, 2011 at 04:26:30AM +0100, Rob Herring wrote:

quoted

On 11/11/2011 05:22 AM, Peter De Schrijver wrote:

quoted

This patch adds the initial device tree for tegra30

...

quoted

quoted

quoted

quoted

quoted

+	interrupt-parent = <&intc>;
+
+	intc: interrupt-controller at 50041000 {
+		compatible = "nvidia,tegra30-gic", "nvidia,tegra20-gic";
+		interrupt-controller;
+		#interrupt-cells = <1>;

Is the Tegra GIC really different from a standard A9 gic? You need to
update to use the gic binding. The cells should be 3 for example.

It has an extra 'legacy' interrupt controller like tegra20 has. This is used
when waking up the CPU from power off mode.

Although that is probably not part of the GIC h/w (i.e. at a different
address) and should be described in the dts separately. That doesn't
change the GIC binding or the fact that you are using
arch/arm/common/gic.c though. Whether you have a different compatible
string or not is not really the issue. That can already be supported if
necessary. The issue is you are not using the existing GIC binding as a
starting point and that has implications on every node using a GIC
interrupt.

The GIC is the same as the one used on tegra20. So I copied the binding from
tegra20.dtsi. Is that one wrong too then?

The existing Tegra20 .dtsi file doesn't use the new GIC bindings yet
either, which as Peter points out is where he copied the GIC node from.
My suggestion is that we merge the Tegra30 .dtsi as shown above, and then
do a single pass to convert both tegra20.dtsi and tegra30.dtsi over to the
new GIC binding, to prevent blocking the merge of tegra30.dtsi on the GIC
binding rework. Does that sound fair?

If the change was complex to address then I would agree, but it's not.
In fact, the code to enable GIC DT binding is shorter than the
additional copy of a wrong/incomplete/unused binding. I think it is
needless churn doing as you suggest.

Rob