Armada 370/XP clocksource fixes

This commit fixes the DT binding for the Armada 370/XP SoC timer. The previous "marvell,armada-370-xp-timer" compatible is removed and two new compatible strings are introduced: "marvell,armada-xp-timer" and "marvell,armada-370-timer".

The rationale behind this change is that the Armada 370 SoC and the Armada XP SoC timers are not really compatible:

* Armada 370 has no 25 MHz fixed timer.

* Armada XP cannot work properly without such 25 MHz fixed timer as doing otherwise leads to using a clocksource whose frequency varies when doing cpufreq frequency changes.

This commit also removes the "marvell,timer-25Mhz" property, given it's now meaningless.

Cc devicetree at vger.kernel.org

Acked-by Jason Cooper <[email protected]>

Signed-off-by Ezequiel Garcia <[email protected]>

---
 .../bindings/timer/marvell,armada-370-xp-timer.txt | 27 ++++++++++++++++++----
 1 file changed, 22 insertions(+), 5 deletions(-)

Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt +22 -5

index 3638112..4c453b2 100644
@@ -2,14 +2,31 @@ Marvell Armada 370 and Armada XP Timers
 ---------------------------------------
 
 Required properties:
-- compatible: Should be "marvell,armada-370-xp-timer"
+- compatible: Should be either "marvell,armada-370-timer" or
+  "marvell,armada-xp-timer" as appropriate.
 - interrupts: Should contain the list of Global Timer interrupts and
   then local timer interrupts
 - reg: Should contain location and length for timers register. First
   pair for the Global Timer registers, second pair for the
   local/private timers.
-- clocks: clock driving the timer hardware
+- clocks: clock driving the timer hardware, only required for
+  "marvell,armada-370-timer";
 
-Optional properties:
-- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
-  Mhz fixed mode (available on Armada XP and not on Armada 370)
+Examples:
+
+- Armada 370:
+
+	timer {
+		compatible = "marvell,armada-370-timer";
+		reg = <0x20300 0x30>, <0x21040 0x30>;
+		interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
+		clocks = <&coreclk 2>;
+	};
+
+- Armada XP:
+
+	timer {
+		compatible = "marvell,armada-xp-timer";
+		reg = <0x20300 0x30>, <0x21040 0x30>;
+		interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
+	};

Signature · 7 lines

1.8.1.5


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 8 lines · Ezequiel Garcia

This commit fixes the DT binding for the Armada 370/XP SoC timer. The previous "marvell,armada-370-xp-timer" compatible is removed and two new compatible strings are introduced: "marvell,armada-xp-timer" and "marvell,armada-370-timer".

The rationale behind this change is that the Armada 370 SoC and the Armada XP SoC timers are not really compatible:

Quoted 8 lines

* Armada 370 has no 25 MHz fixed timer.

* Armada XP cannot work properly without such 25 MHz fixed timer as doing otherwise leads to using a clocksource whose frequency varies when doing cpufreq frequency changes.

This commit also removes the "marvell,timer-25Mhz" property, given it's now meaningless.

Given we have a mechanism already for handling this, I'm not sure. The new binding certainly looks nicer (and if there's no-one using it, then migrating makes sense), but I still have concerns about it. From the description of the problem, and a look at the driver, the timer hardware actually has (at least) two clock inputs:

(a) Wired to a fixed 25MHz clock on the XP, but not described. Not wired to anything on the 370?

(b) Wired to the CPU clock on the XP?
Wired to some external clock on the 370.

If that's the case, this should be described, even if we can't use that information right now. (a) can be a 25MHz fixed-clock on the XP, and just not described on the 370. We can use clock-names to handle the optional presence of any input clock.

Having separate compatible strings may still make sense, but I'd prefer to understand the hardware better first. Not having full visibility over a piece of hardware at review stage is precisely why we get into a mess trying to change bindings later.

Armada XP
---------

Two clock sources are available for timer and watchdog counters:

Just as explained for the Armada 370, the timer and watchdog counters decrement rate is a configurable ratio of the L2/coherency fabric clock.
The current clocksource driver implementation chooses an abritrary ratio.

In addition to this, both timer and watchdog counter rate can be configured to use an (internal) 25 MHz fixed clock.

However, and as explained in this patchset, using the letter fixed clock is in practice the only choice. Once CPUFreq support is implemented for the Armada XP SoC the L2/coherency fabric clock will change its rate, and handling such change will be problematic.

Maybe the most accurate representation would be something like this...

timer {
compatible = "marvell,armada-xp-timer"; reg = ...
interrupts = ...
clocks = ... /* either 25 MHz fixed clock
* or L2/coherency fabric clock */
};

On 08/15/2013 10:27 AM, Ezequiel Garcia wrote:
...

Quoted 10 lines

Armada XP
---------

Two clock sources are available for timer and watchdog counters:

Just as explained for the Armada 370, the timer and watchdog counters decrement rate is a configurable ratio of the L2/coherency fabric clock. The current clocksource driver implementation chooses an abritrary ratio.

Quoted 2 lines

In addition to this, both timer and watchdog counter rate can be configured to use an (internal) 25 MHz fixed clock.

So there are clearly two clocks fed into the HW block here. The DT should reflect that.

Quoted 4 lines

However, and as explained in this patchset, using the letter fixed clock is in practice the only choice. Once CPUFreq support is implemented for the Armada XP SoC the L2/coherency fabric clock will change its rate, and handling such change will be problematic.

It's not mandatory for an OS to implement cpufreq, so it'd be quite possible to still use that variable-rate clock on some HW. What SW may-or-may-not do on HW isn't something that should feed into the DT binding design.

Quoted 4 lines

Maybe the most accurate representation would be something like this...

timer {

Quoted 8 lines

compatible = "marvell,armada-xp-timer";
reg = ...
interrupts = ...
clocks = ... /* either 25 MHz fixed clock

* or L2/coherency fabric clock */

};

I think better would be:

clocks = <&xxx ...> <&yyy ...>;
clock-names = "fabric", "fixed";

In the documentation for this HW block, there's a register that switches between the two clock sources. What names are used for the clocks in the documentation of that register? Those names should be used for clock-names entries.

Is the fact that one of "fabric" and "fixed" is variable and one fixed-rate more a facet of the integration of the IP block into the SoC, and not forced by the design of the IP block itself? If so, perhaps you'd want some additional properties indicating which of those clocks was fixed and which was variable, which would allow SW to make intelligent decisions re: which to use. Perhaps it can be assumed this information can be queried from the source of the clock though?

Quoted 13 lines · On Friday 16 of August 2013 17:29:00 Stephen Warren wrote:

On 08/15/2013 10:27 AM, Ezequiel Garcia wrote:
...

Quoted 10 lines

Armada XP
---------

Two clock sources are available for timer and watchdog counters:

Just as explained for the Armada 370, the timer and watchdog counters decrement rate is a configurable ratio of the L2/coherency fabric clock. The current clocksource driver implementation chooses an abritrary ratio.

Quoted 5 lines

Quoted 2 lines

In addition to this, both timer and watchdog counter rate can be configured to use an (internal) 25 MHz fixed clock.

So there are clearly two clocks fed into the HW block here. The DT should reflect that.

I fully agree. DT should list all the input clocks that are fed into the IP block being described.

Quoted 18 lines · Tomasz Figa

Quoted 17 lines · On Friday 16 of August 2013 17:29:00 Stephen Warren wrote:

On 08/15/2013 10:27 AM, Ezequiel Garcia wrote:
...

Quoted 13 lines

Armada XP
---------

Two clock sources are available for timer and watchdog counters:

Just as explained for the Armada 370, the timer and watchdog counters
decrement rate is a configurable ratio of the L2/coherency fabric clock. The current clocksource driver implementation chooses an abritrary ratio.

In addition to this, both timer and watchdog counter rate can be configured to use an (internal) 25 MHz fixed clock.

Quoted 5 lines

Quoted 2 lines

So there are clearly two clocks fed into the HW block here. The DT should reflect that.

I fully agree. DT should list all the input clocks that are fed into the IP block being described.

I don't object to the above, but strictly speaking the consequence would be, that all nodes require a clocks property.

For A370/XP timer
the fabric clock is configurable and needs to be passed among core clocks and timer, the 25MHz clock is not and _could_ be seen as an extra feature of the core.

Quoted 20 lines · Tomasz Figa

Quoted 18 lines · On Friday 16 of August 2013 17:29:00 Stephen Warren wrote:

On 08/15/2013 10:27 AM, Ezequiel Garcia wrote:
...

Quoted 5 lines

Armada XP
---------

Two clock sources are available for timer and watchdog counters:

Quoted 7 lines

Just as explained for the Armada 370, the timer and watchdog counters decrement rate is a configurable ratio of the L2/coherency fabric clock. The current clocksource driver implementation chooses an abritrary ratio.

In addition to this, both timer and watchdog counter rate can be configured to use an (internal) 25 MHz fixed clock.

So there are clearly two clocks fed into the HW block here. The DT should reflect that.

Quoted 2 lines

I fully agree. DT should list all the input clocks that are fed into the IP block being described.

I don't object to the above, but strictly speaking the consequence would be, that all nodes require a clocks property. For A370/XP timer the fabric clock is configurable and needs to be passed among core clocks and timer, the 25MHz clock is not and _could_ be seen as an extra feature of the core.

But in the end, passing it by DT should be the way to go. I cannot look into the XP datasheet, but I would guess that the exact feature of the ip is not to use _the_ fixed 25MHz clock but XTAL as reference. Maybe one of the free-electrons guys can look it up?

On Sat, Aug 17, 2013 at 02:29:28PM +0200, Sebastian Hesselbarth wrote:

In fact: I'm not sure. I'm slightly inclined towards considering both clocks as clock sources, just as Stephen and Tomasz are proposing.

Quoted 5 lines

But in the end, passing it by DT should be the way to go. I cannot look into the XP datasheet, but I would guess that the exact feature of the ip is not to use _the_ fixed 25MHz clock but XTAL as reference. Maybe one of the free-electrons guys can look it up?

No, the documentation has a register bit for "25Mhz frequency enable", for each timer/watchdog.

---

Anyway, I (almost) agree that the 25Mhz fixed clock must be somehow represented in the device-tree, but I'm not exactly sure how. Gregory: maybe you can help in this?

Quoted 12 lines · Ezequiel Garcia

On Sat, Aug 17, 2013 at 02:29:28PM +0200, Sebastian Hesselbarth wrote:

In fact: I'm not sure. I'm slightly inclined towards considering both clocks as clock sources, just as Stephen and Tomasz are proposing.

Quoted 6 lines

But in the end, passing it by DT should be the way to go. I cannot look
into the XP datasheet, but I would guess that the exact feature of the
ip is not to use _the_ fixed 25MHz clock but XTAL as reference. Maybe one of the free-electrons guys can look it up?

Quoted 8 lines

No, the documentation has a register bit for "25Mhz frequency enable", for each timer/watchdog.

---

Anyway, I (almost) agree that the 25Mhz fixed clock must be somehow represented in the device-tree, but I'm not exactly sure how.
Gregory: maybe you can help in this?

In armada-370-xp.dtsi add a 25MHz ref clock node and modify timer node to reference it:

cpus { ... };

clocks {
	ref25M: timer-clock {
		compatible = "fixed-clock";
		clock-frequency = <25000000>;
	};
}

...

internal-regs {
	timer at 20300 {
		compatible = "marvell,armada-370-xp-timer";
		reg = <0x20300 0x30>, <0x21040 0x30>;
		interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
		clocks = <&coreclk 2>, <&ref25M>;
		clock-names = "fabric", "fixed";

	};
};

Then use of_clk_get_by_name(np, "fabric") and of_clk_get_by_name(np, "fixed") respectively. Clock select strategy should be, (a) fail if no clock, (b) use fabric/fixed if just one clock, (c) use fixed if both clocks.

Quoted 36 lines · On Monday 19 of August 2013 01:33:18 Sebastian Hesselbarth wrote:

Quoted 12 lines · Ezequiel Garcia

On Sat, Aug 17, 2013 at 02:29:28PM +0200, Sebastian Hesselbarth wrote:

In fact: I'm not sure. I'm slightly inclined towards considering both clocks as clock sources, just as Stephen and Tomasz are proposing.

Quoted 6 lines

But in the end, passing it by DT should be the way to go. I cannot look
into the XP datasheet, but I would guess that the exact feature of the
ip is not to use _the_ fixed 25MHz clock but XTAL as reference. Maybe one of the free-electrons guys can look it up?

Quoted 8 lines

No, the documentation has a register bit for "25Mhz frequency enable", for each timer/watchdog.

---

Anyway, I (almost) agree that the 25Mhz fixed clock must be somehow represented in the device-tree, but I'm not exactly sure how.
Gregory: maybe you can help in this?

In armada-370-xp.dtsi add a 25MHz ref clock node and modify timer node to reference it:

cpus { ... };

clocks {
	ref25M: timer-clock {
		compatible = "fixed-clock";
		clock-frequency = <25000000>;
	};
}

...

Quoted 7 lines

internal-regs {
	timer at 20300 {
		compatible = "marvell,armada-370-xp-timer";
		reg = <0x20300 0x30>, <0x21040 0x30>;
		interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
		clocks = <&coreclk 2>, <&ref25M>;
		clock-names = "fabric", "fixed";

These names look more like SoC-level clock names, not clock input names of the IP. Are they referenced by such names in documentation?

Quoted 7 lines

	};
};

Then use of_clk_get_by_name(np, "fabric") and of_clk_get_by_name(np, "fixed") respectively. Clock select strategy should be, (a) fail if no clock, (b) use fabric/fixed if just one clock, (c) use fixed if both clocks.

This basically sounds good, except those names.

Quoted 11 lines · Ezequiel Garcia

On Sat, Aug 17, 2013 at 02:29:28PM +0200, Sebastian Hesselbarth wrote:

In fact: I'm not sure. I'm slightly inclined towards considering both clocks as clock sources, just as Stephen and Tomasz are proposing.

Quoted 5 lines

But in the end, passing it by DT should be the way to go. I cannot look into the XP datasheet, but I would guess that the exact feature of the ip is not to use _the_ fixed 25MHz clock but XTAL as reference. Maybe one of the free-electrons guys can look it up?

Quoted 9 lines

No, the documentation has a register bit for "25Mhz frequency enable", for each timer/watchdog.

---

Anyway, I (almost) agree that the 25Mhz fixed clock must be somehow represented in the device-tree, but I'm not exactly sure how. Gregory: maybe you can help in this?

In armada-370-xp.dtsi add a 25MHz ref clock node and modify timer node to reference it:

cpus { ... };

clocks {
	ref25M: timer-clock {
		compatible = "fixed-clock";
		clock-frequency = <25000000>;
	};
}

...

internal-regs {
	timer at 20300 {
		compatible = "marvell,armada-370-xp-timer";
		reg = <0x20300 0x30>, <0x21040 0x30>;
		interrupts = <37>, <38>, <39>, <40>, <5>, <6>;
		clocks = <&coreclk 2>, <&ref25M>;
		clock-names = "fabric", "fixed";
	};
};

Then use of_clk_get_by_name(np, "fabric") and of_clk_get_by_name(np, "fixed") respectively. Clock select strategy should be, (a) fail if no clock, (b) use fabric/fixed if just one clock, (c) use fixed if both clocks.

Does that answer your questions? :)

On 08/15/2013 10:27 AM, Ezequiel Garcia wrote:
...

Quoted 9 lines

Armada XP
---------

Two clock sources are available for timer and watchdog counters:

Just as explained for the Armada 370, the timer and watchdog counters decrement rate is a configurable ratio of the L2/coherency fabric clock.
The current clocksource driver implementation chooses an abritrary ratio.

Quoted 2 lines

In addition to this, both timer and watchdog counter rate can be configured to use an (internal) 25 MHz fixed clock.

So there are clearly two clocks fed into the HW block here. The DT should reflect that.

Quoted 4 lines

However, and as explained in this patchset, using the letter fixed clock is in practice the only choice. Once CPUFreq support is implemented for the Armada XP SoC the L2/coherency fabric clock will change its rate, and handling such change will be problematic.

It's not mandatory for an OS to implement cpufreq, so it'd be quite possible to still use that variable-rate clock on some HW. What SW may-or-may-not do on HW isn't something that should feed into the DT binding design.

Quoted 9 lines

Maybe the most accurate representation would be something like this...

timer {
compatible = "marvell,armada-xp-timer"; reg = ...
interrupts = ...
clocks = ... /* either 25 MHz fixed clock
* or L2/coherency fabric clock */
};

I think better would be:

clocks = <&xxx ...> <&yyy ...>;
clock-names = "fabric", "fixed";

In the documentation for this HW block, there's a register that switches between the two clock sources. What names are used for the clocks in the documentation of that register? Those names should be used for clock-names entries.

Is the fact that one of "fabric" and "fixed" is variable and one fixed-rate more a facet of the integration of the IP block into the SoC, and not forced by the design of the IP block itself? If so, perhaps you'd want some additional properties indicating which of those clocks was fixed and which was variable, which would allow SW to make intelligent decisions re: which to use. Perhaps it can be assumed this information can be queried from the source of the clock though?

The "marvell,armada-370-xp-timer" compatible string, together with the "marvell,timer-25Mhz" property are deprecated and should be removed from current DT.

Instead, the timer DT nodes are now required to have an appropriate compatible string, which should be either "marvell,armada-370-timer" or "marvell,armada-xp-timer", depending on SoC.

The clock property is now required only for Armada 370 so move it accordingly.

Signed-off-by Ezequiel Garcia <[email protected]>

---
 arch/arm/boot/dts/armada-370-xp.dtsi | 2 --
 arch/arm/boot/dts/armada-370.dtsi    | 5 +++++
 arch/arm/boot/dts/armada-xp.dtsi     | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

This patchset is based on tip/timers/core.

Quoted 13 lines · Ezequiel Garcia

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

Quoted 4 lines

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

This patchset is based on tip/timers/core.

Applied to my tree as 3.12 material.

Daniel,

Quoted 14 lines · Daniel Lezcano

Quoted 13 lines · Ezequiel Garcia

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

Quoted 6 lines

Quoted 4 lines

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

This patchset is based on tip/timers/core.

Applied to my tree as 3.12 material.

Did you take patch #6 as well?

Quoted 19 lines · Jason Cooper

Daniel,

Quoted 16 lines · Daniel Lezcano

Quoted 15 lines · Ezequiel Garcia

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

This patchset is based on tip/timers/core.

Applied to my tree as 3.12 material.

Did you take patch #6 as well?

Yes. Not good ?

Quoted 20 lines · Daniel Lezcano

Quoted 19 lines · Jason Cooper

Daniel,

Quoted 16 lines · Daniel Lezcano

Quoted 15 lines · Ezequiel Garcia

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

This patchset is based on tip/timers/core.

Applied to my tree as 3.12 material.

Did you take patch #6 as well?

Yes. Not good ?

I usually try to keep all the *.dts? changes in one tree so I can resolve the conflicts internally because our dts files have been subject to large changes (adding pcie/mbus, relocating nodes under the proper parents, etc).

By way of example:

$ git diff --stat v3.11-rc1..for-next -- arch/arm/boot/dts/armada-*
 arch/arm/boot/dts/armada-370-db.dts              |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts              |  37 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             | 114 ++++---
 arch/arm/boot/dts/armada-370.dtsi                | 127 ++++---
 arch/arm/boot/dts/armada-xp-db.dts               | 131 ++++---
 arch/arm/boot/dts/armada-xp-gp.dts               | 107 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 229 +++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 270 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 418 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  88 +++--
 arch/arm/boot/dts/armada-xp.dtsi                 |  19 +-
 12 files changed, 849 insertions(+), 733 deletions(-)

I would prefer not to subject arm-soc or Linus to resolving those when they are best resolved at our level.

Is it possible for you to drop that one so we can take it?

Quoted 52 lines · Jason Cooper

Quoted 20 lines · Daniel Lezcano

Quoted 19 lines · Jason Cooper

Daniel,

Quoted 16 lines · Daniel Lezcano

Quoted 15 lines · Ezequiel Garcia

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

This patchset is based on tip/timers/core.

Applied to my tree as 3.12 material.

Did you take patch #6 as well?

Yes. Not good ?

I usually try to keep all the *.dts? changes in one tree so I can resolve the conflicts internally because our dts files have been subject to large changes (adding pcie/mbus, relocating nodes under the proper parents, etc).

By way of example:

$ git diff --stat v3.11-rc1..for-next -- arch/arm/boot/dts/armada-*
 arch/arm/boot/dts/armada-370-db.dts              |   5 +-
 arch/arm/boot/dts/armada-370-mirabox.dts         |  37 +-
 arch/arm/boot/dts/armada-370-rd.dts              |  37 +-
 arch/arm/boot/dts/armada-370-xp.dtsi             | 114 ++++---
 arch/arm/boot/dts/armada-370.dtsi                | 127 ++++---
 arch/arm/boot/dts/armada-xp-db.dts               | 131 ++++---
 arch/arm/boot/dts/armada-xp-gp.dts               | 107 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi         | 229 +++++++------
 arch/arm/boot/dts/armada-xp-mv78260.dtsi         | 270 ++++++++-------
 arch/arm/boot/dts/armada-xp-mv78460.dtsi         | 418 ++++++++++++-----------
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  88 +++--
 arch/arm/boot/dts/armada-xp.dtsi                 |  19 +-
 12 files changed, 849 insertions(+), 733 deletions(-)

Quoted 4 lines

I would prefer not to subject arm-soc or Linus to resolving those when they are best resolved at our level.

Is it possible for you to drop that one so we can take it?

Sure, no problem. Dropped.

Quoted 13 lines · Ezequiel Garcia

This small patchset fixes a somewhat minor issue found in the clocksource driver for Armada 370/XP SoC.

On one side the Armada 370 SoC has no 25 MHz fixed timer.
On the other side the Armada XP SoC cannot work properly without such 25 MHz fixed timer selected, because otherwise the base clock frequency would vary when doing cpufreq frequency changes.

Therefore we can consider the SoCs as not being compatible, being better to have two compatible strings, one for each SoC. The previous compatible and its behavior has been removed, considering there are no DT-enabled boards in use in the field.

Quoted 4 lines

In addition, CLOCKSOURCE_OF_DECLARE is used to simplify the initialization.

This patchset is based on tip/timers/core.

Applied to my tree as 3.12 material.