Hi Wim,
Today's linux-next merge of the watchdog tree got a conflict in:
arch/arm64/boot/dts/arm/foundation-v8.dts
between commit:
d11a89796678 ("arm64: dts: split Foundation model dts to put the GIC separately")
from the arm-soc tree and commit:
fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts")
from the watchdog tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell
diff --cc arch/arm64/boot/dts/arm/foundation-v8.dts
index 71168077312d,66cb9aaa9135..000000000000
--- a/arch/arm64/boot/dts/arm/foundation-v8.dts
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
@@@ -18,4 -83,165 +18,11 @@@
<0x0 0x2c006000 0 0x2000>;
interrupts = <1 9 0xf04>;
};
-
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <1 13 0xf08>,
- <1 14 0xf08>,
- <1 11 0xf08>,
- <1 10 0xf08>;
- clock-frequency = <100000000>;
- };
-
- pmu {
- compatible = "arm,armv8-pmuv3";
- interrupts = <0 60 4>,
- <0 61 4>,
- <0 62 4>,
- <0 63 4>;
- };
-
- smb {
- compatible = "arm,vexpress,v2m-p1", "simple-bus";
- arm,v2m-memory-map = "rs1";
- #address-cells = <2>; /* SMB chipselect number and offset */
- #size-cells = <1>;
-
- ranges = <0 0 0 0x08000000 0x04000000>,
- <1 0 0 0x14000000 0x04000000>,
- <2 0 0 0x18000000 0x04000000>,
- <3 0 0 0x1c000000 0x04000000>,
- <4 0 0 0x0c000000 0x04000000>,
- <5 0 0 0x10000000 0x04000000>;
-
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 63>;
- interrupt-map = <0 0 0 &gic 0 0 4>,
- <0 0 1 &gic 0 1 4>,
- <0 0 2 &gic 0 2 4>,
- <0 0 3 &gic 0 3 4>,
- <0 0 4 &gic 0 4 4>,
- <0 0 5 &gic 0 5 4>,
- <0 0 6 &gic 0 6 4>,
- <0 0 7 &gic 0 7 4>,
- <0 0 8 &gic 0 8 4>,
- <0 0 9 &gic 0 9 4>,
- <0 0 10 &gic 0 10 4>,
- <0 0 11 &gic 0 11 4>,
- <0 0 12 &gic 0 12 4>,
- <0 0 13 &gic 0 13 4>,
- <0 0 14 &gic 0 14 4>,
- <0 0 15 &gic 0 15 4>,
- <0 0 16 &gic 0 16 4>,
- <0 0 17 &gic 0 17 4>,
- <0 0 18 &gic 0 18 4>,
- <0 0 19 &gic 0 19 4>,
- <0 0 20 &gic 0 20 4>,
- <0 0 21 &gic 0 21 4>,
- <0 0 22 &gic 0 22 4>,
- <0 0 23 &gic 0 23 4>,
- <0 0 24 &gic 0 24 4>,
- <0 0 25 &gic 0 25 4>,
- <0 0 26 &gic 0 26 4>,
- <0 0 27 &gic 0 27 4>,
- <0 0 28 &gic 0 28 4>,
- <0 0 29 &gic 0 29 4>,
- <0 0 30 &gic 0 30 4>,
- <0 0 31 &gic 0 31 4>,
- <0 0 32 &gic 0 32 4>,
- <0 0 33 &gic 0 33 4>,
- <0 0 34 &gic 0 34 4>,
- <0 0 35 &gic 0 35 4>,
- <0 0 36 &gic 0 36 4>,
- <0 0 37 &gic 0 37 4>,
- <0 0 38 &gic 0 38 4>,
- <0 0 39 &gic 0 39 4>,
- <0 0 40 &gic 0 40 4>,
- <0 0 41 &gic 0 41 4>,
- <0 0 42 &gic 0 42 4>;
-
- ethernet@2,02000000 {
- compatible = "smsc,lan91c111";
- reg = <2 0x02000000 0x10000>;
- interrupts = <15>;
- };
-
- v2m_clk24mhz: clk24mhz {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <24000000>;
- clock-output-names = "v2m:clk24mhz";
- };
-
- v2m_refclk1mhz: refclk1mhz {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <1000000>;
- clock-output-names = "v2m:refclk1mhz";
- };
-
- v2m_refclk32khz: refclk32khz {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <32768>;
- clock-output-names = "v2m:refclk32khz";
- };
-
- iofpga@3,00000000 {
- compatible = "arm,amba-bus", "simple-bus";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 3 0 0x200000>;
-
- v2m_sysreg: sysreg@010000 {
- compatible = "arm,vexpress-sysreg";
- reg = <0x010000 0x1000>;
- };
-
- v2m_serial0: uart@090000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0x090000 0x1000>;
- interrupts = <5>;
- clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
- clock-names = "uartclk", "apb_pclk";
- };
-
- v2m_serial1: uart@0a0000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0x0a0000 0x1000>;
- interrupts = <6>;
- clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
- clock-names = "uartclk", "apb_pclk";
- };
-
- v2m_serial2: uart@0b0000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0x0b0000 0x1000>;
- interrupts = <7>;
- clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
- clock-names = "uartclk", "apb_pclk";
- };
-
- v2m_serial3: uart@0c0000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0x0c0000 0x1000>;
- interrupts = <8>;
- clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
- clock-names = "uartclk", "apb_pclk";
- };
-
- virtio_block@0130000 {
- compatible = "virtio,mmio";
- reg = <0x130000 0x200>;
- interrupts = <42>;
- };
- };
- };
+ watchdog@2a440000 {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x2a440000 0 0x1000>,
+ <0x0 0x2a450000 0 0x1000>;
+ interrupts = <0 27 4>;
+ timeout-sec = <30>;
+ };
};
Hi Wim,
It's much easier for us if all DTS changes go in through the arm-soc
trees, to avoid these kind of conflicts. Is this on a branch where you
can easily drop it and we pick it up instead, or is it on a now-stable
branch?
-Olof
On Sun, Mar 6, 2016 at 8:04 PM, Stephen Rothwell <[email protected]> wrote:
> Hi Wim,
>
> Today's linux-next merge of the watchdog tree got a conflict in:
>
> arch/arm64/boot/dts/arm/foundation-v8.dts
>
> between commit:
>
> d11a89796678 ("arm64: dts: split Foundation model dts to put the GIC separately")
>
> from the arm-soc tree and commit:
>
> fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts")
>
> from the watchdog tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/boot/dts/arm/foundation-v8.dts
> index 71168077312d,66cb9aaa9135..000000000000
> --- a/arch/arm64/boot/dts/arm/foundation-v8.dts
> +++ b/arch/arm64/boot/dts/arm/foundation-v8.dts
> @@@ -18,4 -83,165 +18,11 @@@
> <0x0 0x2c006000 0 0x2000>;
> interrupts = <1 9 0xf04>;
> };
> -
> - timer {
> - compatible = "arm,armv8-timer";
> - interrupts = <1 13 0xf08>,
> - <1 14 0xf08>,
> - <1 11 0xf08>,
> - <1 10 0xf08>;
> - clock-frequency = <100000000>;
> - };
> -
> - pmu {
> - compatible = "arm,armv8-pmuv3";
> - interrupts = <0 60 4>,
> - <0 61 4>,
> - <0 62 4>,
> - <0 63 4>;
> - };
> -
> - smb {
> - compatible = "arm,vexpress,v2m-p1", "simple-bus";
> - arm,v2m-memory-map = "rs1";
> - #address-cells = <2>; /* SMB chipselect number and offset */
> - #size-cells = <1>;
> -
> - ranges = <0 0 0 0x08000000 0x04000000>,
> - <1 0 0 0x14000000 0x04000000>,
> - <2 0 0 0x18000000 0x04000000>,
> - <3 0 0 0x1c000000 0x04000000>,
> - <4 0 0 0x0c000000 0x04000000>,
> - <5 0 0 0x10000000 0x04000000>;
> -
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 63>;
> - interrupt-map = <0 0 0 &gic 0 0 4>,
> - <0 0 1 &gic 0 1 4>,
> - <0 0 2 &gic 0 2 4>,
> - <0 0 3 &gic 0 3 4>,
> - <0 0 4 &gic 0 4 4>,
> - <0 0 5 &gic 0 5 4>,
> - <0 0 6 &gic 0 6 4>,
> - <0 0 7 &gic 0 7 4>,
> - <0 0 8 &gic 0 8 4>,
> - <0 0 9 &gic 0 9 4>,
> - <0 0 10 &gic 0 10 4>,
> - <0 0 11 &gic 0 11 4>,
> - <0 0 12 &gic 0 12 4>,
> - <0 0 13 &gic 0 13 4>,
> - <0 0 14 &gic 0 14 4>,
> - <0 0 15 &gic 0 15 4>,
> - <0 0 16 &gic 0 16 4>,
> - <0 0 17 &gic 0 17 4>,
> - <0 0 18 &gic 0 18 4>,
> - <0 0 19 &gic 0 19 4>,
> - <0 0 20 &gic 0 20 4>,
> - <0 0 21 &gic 0 21 4>,
> - <0 0 22 &gic 0 22 4>,
> - <0 0 23 &gic 0 23 4>,
> - <0 0 24 &gic 0 24 4>,
> - <0 0 25 &gic 0 25 4>,
> - <0 0 26 &gic 0 26 4>,
> - <0 0 27 &gic 0 27 4>,
> - <0 0 28 &gic 0 28 4>,
> - <0 0 29 &gic 0 29 4>,
> - <0 0 30 &gic 0 30 4>,
> - <0 0 31 &gic 0 31 4>,
> - <0 0 32 &gic 0 32 4>,
> - <0 0 33 &gic 0 33 4>,
> - <0 0 34 &gic 0 34 4>,
> - <0 0 35 &gic 0 35 4>,
> - <0 0 36 &gic 0 36 4>,
> - <0 0 37 &gic 0 37 4>,
> - <0 0 38 &gic 0 38 4>,
> - <0 0 39 &gic 0 39 4>,
> - <0 0 40 &gic 0 40 4>,
> - <0 0 41 &gic 0 41 4>,
> - <0 0 42 &gic 0 42 4>;
> -
> - ethernet@2,02000000 {
> - compatible = "smsc,lan91c111";
> - reg = <2 0x02000000 0x10000>;
> - interrupts = <15>;
> - };
> -
> - v2m_clk24mhz: clk24mhz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <24000000>;
> - clock-output-names = "v2m:clk24mhz";
> - };
> -
> - v2m_refclk1mhz: refclk1mhz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <1000000>;
> - clock-output-names = "v2m:refclk1mhz";
> - };
> -
> - v2m_refclk32khz: refclk32khz {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <32768>;
> - clock-output-names = "v2m:refclk32khz";
> - };
> -
> - iofpga@3,00000000 {
> - compatible = "arm,amba-bus", "simple-bus";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0 3 0 0x200000>;
> -
> - v2m_sysreg: sysreg@010000 {
> - compatible = "arm,vexpress-sysreg";
> - reg = <0x010000 0x1000>;
> - };
> -
> - v2m_serial0: uart@090000 {
> - compatible = "arm,pl011", "arm,primecell";
> - reg = <0x090000 0x1000>;
> - interrupts = <5>;
> - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
> - clock-names = "uartclk", "apb_pclk";
> - };
> -
> - v2m_serial1: uart@0a0000 {
> - compatible = "arm,pl011", "arm,primecell";
> - reg = <0x0a0000 0x1000>;
> - interrupts = <6>;
> - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
> - clock-names = "uartclk", "apb_pclk";
> - };
> -
> - v2m_serial2: uart@0b0000 {
> - compatible = "arm,pl011", "arm,primecell";
> - reg = <0x0b0000 0x1000>;
> - interrupts = <7>;
> - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
> - clock-names = "uartclk", "apb_pclk";
> - };
> -
> - v2m_serial3: uart@0c0000 {
> - compatible = "arm,pl011", "arm,primecell";
> - reg = <0x0c0000 0x1000>;
> - interrupts = <8>;
> - clocks = <&v2m_clk24mhz>, <&v2m_clk24mhz>;
> - clock-names = "uartclk", "apb_pclk";
> - };
> -
> - virtio_block@0130000 {
> - compatible = "virtio,mmio";
> - reg = <0x130000 0x200>;
> - interrupts = <42>;
> - };
> - };
> - };
> + watchdog@2a440000 {
> + compatible = "arm,sbsa-gwdt";
> + reg = <0x0 0x2a440000 0 0x1000>,
> + <0x0 0x2a450000 0 0x1000>;
> + interrupts = <0 27 4>;
> + timeout-sec = <30>;
> + };
> };
Hi Olof,
On 07/03/16 05:41, Olof Johansson wrote:
> Hi Wim,
>
> It's much easier for us if all DTS changes go in through the arm-soc
> trees, to avoid these kind of conflicts. Is this on a branch where you
> can easily drop it and we pick it up instead, or is it on a now-stable
> branch?
>
Sorry for that. Since the patch series was still under discussion and
v14 was posted 3 days ago, I had not checked with Fu Wei on his plans
for DTS changes.
Let me know if you want to pick up this single patch directly or want me
to send PR for that if Wim drops it from his branch. I might have couple
of DTS warning fixes for juno/vexpress(though I need to wait for Rob's
acks to them), so I can bundle them together.
--
Regards,
Sudeep
Hi All,
> It's much easier for us if all DTS changes go in through the arm-soc
> trees, to avoid these kind of conflicts. Is this on a branch where you
> can easily drop it and we pick it up instead, or is it on a now-stable
> branch?
>
>
> -Olof
I can always redo the tree once you picked it up.
Kind regards,
Wim.
On Mon, Mar 7, 2016 at 4:19 AM, Sudeep Holla <[email protected]> wrote:
> Hi Olof,
>
> On 07/03/16 05:41, Olof Johansson wrote:
>>
>> Hi Wim,
>>
>> It's much easier for us if all DTS changes go in through the arm-soc
>> trees, to avoid these kind of conflicts. Is this on a branch where you
>> can easily drop it and we pick it up instead, or is it on a now-stable
>> branch?
>>
>
> Sorry for that. Since the patch series was still under discussion and
> v14 was posted 3 days ago, I had not checked with Fu Wei on his plans
> for DTS changes.
>
> Let me know if you want to pick up this single patch directly or want me
> to send PR for that if Wim drops it from his branch. I might have couple
> of DTS warning fixes for juno/vexpress(though I need to wait for Rob's
> acks to them), so I can bundle them together.
We're short on time for -rc7, most material should have been in by
now. So you might want to send this separately if you think Rob will
time out.
I'm OK with either applying directly or you bundling with other 64-bit
DTS material. Either way, send to [email protected] and we'll pick it up
from there.
Thanks,
-Olof
On Mon, Mar 7, 2016 at 10:54 AM, Wim Van Sebroeck <[email protected]> wrote:
> Hi All,
>
>> It's much easier for us if all DTS changes go in through the arm-soc
>> trees, to avoid these kind of conflicts. Is this on a branch where you
>> can easily drop it and we pick it up instead, or is it on a now-stable
>> branch?
>>
>>
>> -Olof
>
> I can always redo the tree once you picked it up.
Great, thanks!
-Olof
On 07/03/16 19:00, Olof Johansson wrote:
> On Mon, Mar 7, 2016 at 4:19 AM, Sudeep Holla <[email protected]> wrote:
>> Hi Olof,
>>
>> On 07/03/16 05:41, Olof Johansson wrote:
>>>
>>> Hi Wim,
>>>
>>> It's much easier for us if all DTS changes go in through the arm-soc
>>> trees, to avoid these kind of conflicts. Is this on a branch where you
>>> can easily drop it and we pick it up instead, or is it on a now-stable
>>> branch?
>>>
>>
>> Sorry for that. Since the patch series was still under discussion and
>> v14 was posted 3 days ago, I had not checked with Fu Wei on his plans
>> for DTS changes.
>>
>> Let me know if you want to pick up this single patch directly or want me
>> to send PR for that if Wim drops it from his branch. I might have couple
>> of DTS warning fixes for juno/vexpress(though I need to wait for Rob's
>> acks to them), so I can bundle them together.
>
> We're short on time for -rc7, most material should have been in by
> now. So you might want to send this separately if you think Rob will
> time out.
>
I agree, but the warnings I mentioned got introduced last Friday after
Rob updated DTC in -next.
> I'm OK with either applying directly or you bundling with other 64-bit
> DTS material. Either way, send to [email protected] and we'll pick it up
> from there.
>
OK, will do that.
--
Regards,
Sudeep
On 07/03/16 11:04, Stephen Rothwell wrote:
> Hi Wim,
>
> Today's linux-next merge of the watchdog tree got a conflict in:
>
> arch/arm64/boot/dts/arm/foundation-v8.dts
>
> between commit:
>
> d11a89796678 ("arm64: dts: split Foundation model dts to put the GIC separately")
>
> from the arm-soc tree and commit:
>
> fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts")
>
> from the watchdog tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
But unfortunately this is the wrong solution. The watchdog DT node
belongs into the (newly created) common foundation-v8.dtsi, not into the
GICv2-only .dts.
So whoever now provides the watchdog patch, can it be rebased on top of
the foundation model .dts rework, so that the new node ends up in the
.dtsi file?
If this is too much hassle I could also send a fix after -rc1 (as the
breakage is not really critical).
Cheers,
Andre.
Hi All,
On 8 March 2016 at 22:52, André Przywara <[email protected]> wrote:
> On 07/03/16 11:04, Stephen Rothwell wrote:
>> Hi Wim,
>>
>> Today's linux-next merge of the watchdog tree got a conflict in:
>>
>> arch/arm64/boot/dts/arm/foundation-v8.dts
>>
>> between commit:
>>
>> d11a89796678 ("arm64: dts: split Foundation model dts to put the GIC separately")
>>
>> from the arm-soc tree and commit:
>>
>> fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts")
>>
>> from the watchdog tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> But unfortunately this is the wrong solution. The watchdog DT node
> belongs into the (newly created) common foundation-v8.dtsi, not into the
> GICv2-only .dts.
> So whoever now provides the watchdog patch, can it be rebased on top of
> the foundation model .dts rework, so that the new node ends up in the
> .dtsi file?
I can rebase this patch to make a watchdog DT patch for
foundation-v8.dtsi ASAP.
Thanks
> If this is too much hassle I could also send a fix after -rc1 (as the
> breakage is not really critical).
>
> Cheers,
> Andre.
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
Hi Andre,
On 08/03/16 15:52, Andr? Przywara wrote:
> On 07/03/16 11:04, Stephen Rothwell wrote:
>> Hi Wim,
>>
>> Today's linux-next merge of the watchdog tree got a conflict in:
>>
>> arch/arm64/boot/dts/arm/foundation-v8.dts
>>
>> between commit:
>>
>> d11a89796678 ("arm64: dts: split Foundation model dts to put the GIC separately")
>>
>> from the arm-soc tree and commit:
>>
>> fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in foundation-v8.dts")
>>
>> from the watchdog tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> But unfortunately this is the wrong solution. The watchdog DT node
> belongs into the (newly created) common foundation-v8.dtsi, not into the
> GICv2-only .dts.
> So whoever now provides the watchdog patch, can it be rebased on top of
> the foundation model .dts rework, so that the new node ends up in the
> .dtsi file?
> If this is too much hassle I could also send a fix after -rc1 (as the
> breakage is not really critical).
>
I have rebased it on top of my earlier PR and sending it shortly.
I have moved it to dtsi file.
--
Regards,
Sudeep
On 08/03/16 23:06, Sudeep Holla wrote:
Hi Sudeep,
> On 08/03/16 15:52, Andr? Przywara wrote:
>> On 07/03/16 11:04, Stephen Rothwell wrote:
>>> Hi Wim,
>>>
>>> Today's linux-next merge of the watchdog tree got a conflict in:
>>>
>>> arch/arm64/boot/dts/arm/foundation-v8.dts
>>>
>>> between commit:
>>>
>>> d11a89796678 ("arm64: dts: split Foundation model dts to put the
>>> GIC separately")
>>>
>>> from the arm-soc tree and commit:
>>>
>>> fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in
>>> foundation-v8.dts")
>>>
>>> from the watchdog tree.
>>>
>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>> is required).
>>
>> But unfortunately this is the wrong solution. The watchdog DT node
>> belongs into the (newly created) common foundation-v8.dtsi, not into the
>> GICv2-only .dts.
>> So whoever now provides the watchdog patch, can it be rebased on top of
>> the foundation model .dts rework, so that the new node ends up in the
>> .dtsi file?
>> If this is too much hassle I could also send a fix after -rc1 (as the
>> breakage is not really critical).
>>
>
> I have rebased it on top of my earlier PR and sending it shortly.
> I have moved it to dtsi file.
Thanks, that was quick!
Hope that this now does not collide with Fu Wei's fix ;-)
Cheers,
Andre.
On 08/03/16 16:03, Fu Wei wrote:
> Hi All,
>
> On 8 March 2016 at 22:52, André Przywara <[email protected]> wrote:
[...]
>
> I can rebase this patch to make a watchdog DT patch for
> foundation-v8.dtsi ASAP.
>
> Thanks
>
>> If this is too much hassle I could also send a fix after -rc1 (as the
>> breakage is not really critical).
>>
Thanks Andre and Fu Wei, I just fixed it myself and sent the PR[1]
--
Regards,
Sudeep
[1] http://www.spinics.net/lists/arm-kernel/msg489600.html