watchdog: imx2: handle WMCR only being available on i.MX35 and later
Subsystems (5)
cover watchdog: imx2: handle WMCR only being available on i.MX35 and later
Hello,
this is my approach to fix the issue reported by Vladimir Zapolskiy.
IMHO we don't need the third commit because I'm convinced most machines just don't do anything when the WDOG signal becomes active. An affected machine powers off 16 seconds after startup. This would be noticed during development of the bootloader and so I assume all affected machines having bootloaders that make the compat code unimportant.
If you want to know if your machine is affected, do:
mw -w $(watchdog_base_addr) 0x10
The machines I tested this on (among a few customer boards a Phycore i.MX35 and a Freescale i.MX53 Quick Start Board) don't power off.
I don't have manuals handy for ls1021a, ls1043a and ls1046a but assume they use the i.MX35 type, too. This needs to be fixed before this series is applied.
Compared to Vladimir's patch machines still using board files are fixed, too.
Quoted 8 lines · Fabio Estevam
Quoted 3 lines · Uwe Kleine-K?nig
Ack. If you teach the driver now about i.MX35 and only make use of the WMCR register on this one, the possible breakage is that this register isn't written to on the i.MX35 type until the dtb is updated.
So basically you are saying that you don't care about old dtb compatibility.
No, I weight old dtb compatibility which IMHO doesn't buy us anything in this case against maintenance overhead.
Quoted 2 lines
As far as I can see this is the reason we have not made any progress with this patch since September.
I want to disagree with this. I replied the first time with my concerns about the compat code on December 11, so I'm not responsible for the time before that date. Also on December 23 I said that if Vladimir really wants that compat code he should add it. The delay between December 11 and December 23 isn't mine either. In this thread I am a reviewer and so it's unfair to point at me when wailing about delays. I mentioned my doubts and if you don't agree or understand the patch submitter is free to discuss or ask the maintainer to overrule my opinion.
Best regards
Uwe
Uwe Kleine-K?nig (3):
watchdog: imx2: Only i.MX35 and later have a WMCR register
dts: teach newer i.MX machines to have the i.MX35 type watchdog
watchdog: imx2: add compatibility for new i.MX35 type watchdog
.../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 +- arch/arm/boot/dts/imx25.dtsi | 2 +- arch/arm/boot/dts/imx35.dtsi | 2 +- arch/arm/boot/dts/imx50.dtsi | 2 +- arch/arm/boot/dts/imx51.dtsi | 2 +- arch/arm/boot/dts/imx53.dtsi | 2 +- arch/arm/boot/dts/imx6qdl.dtsi | 2 +- arch/arm/boot/dts/imx6sl.dtsi | 4 +- arch/arm/boot/dts/imx6sx.dtsi | 6 +- arch/arm/boot/dts/imx6ul.dtsi | 4 +- arch/arm/boot/dts/imx7s.dtsi | 8 +- arch/arm/boot/dts/vfxxx.dtsi | 2 +- arch/arm/mach-imx/devices/devices-common.h | 1 + arch/arm/mach-imx/devices/platform-imx2-wdt.c | 13 +-- drivers/watchdog/imx2_wdt.c | 97 ++++++++++++++++++++-- 15 files changed, 116 insertions(+), 33 deletions(-)
Signature · 1 line
2.11.0
PATCH 1/3 watchdog: imx2: Only i.MX35 and later have a WMCR register
Commit 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot") introduced a write to the WMCR register that doesn't exist on i.MX21, i.MX27 and i.MX31 and so makes the SoC hang during probe.
So teach the driver to differentiate between these two types. Note that this effectively undoes commit 5fe65ce7ccbb for machines using dt until their dtb is updated accordingly. This is critical iff the bootloader doesn't disable the power down counter and the #WDOG signal actually does something to the machine.
--- arch/arm/mach-imx/devices/devices-common.h | 1 + arch/arm/mach-imx/devices/platform-imx2-wdt.c | 13 +++--- drivers/watchdog/imx2_wdt.c | 59 +++++++++++++++++++++++---- 3 files changed, 59 insertions(+), 14 deletions(-)
arch/arm/mach-imx/devices/devices-common.h +1 -0
@@ -92,6 +92,7 @@ struct platform_device *__init imx_add_imx27_coda(struct imx_imx2_wdt_data {int id; +const char *devname;resource_size_t iobase;resource_size_t iosize; };
arch/arm/mach-imx/devices/platform-imx2-wdt.c +7 -6
@@ -11,9 +11,10 @@#include "../hardware.h" #include "devices-common.h" -#define imx_imx2_wdt_data_entry_single (soc, _id, _hwid, _size) \ +#define imx_imx2_wdt_data_entry_single (soc, _id, _devname, _hwid, _size)\ { \ .id = _id, \ + .devname = _devname, \ .iobase = soc ## _WDOG ## _hwid ## _BASE_ADDR, \ .iosize = _size, \ }
@@ -22,22 +23,22 @@#ifdef CONFIG_SOC_IMX21 const struct imx_imx2_wdt_data imx21_imx2_wdt_data__initconst = - imx_imx2_wdt_data_entry_single(MX21, 0, , SZ_4K); + imx_imx2_wdt_data_entry_single(MX21, 0, "imx21-wdt", , SZ_4K);#endif /* ifdef CONFIG_SOC_IMX21 */ #ifdef CONFIG_SOC_IMX27 const struct imx_imx2_wdt_data imx27_imx2_wdt_data__initconst = - imx_imx2_wdt_data_entry_single(MX27, 0, , SZ_4K); + imx_imx2_wdt_data_entry_single(MX27, 0, "imx21-wdt", , SZ_4K);#endif /* ifdef CONFIG_SOC_IMX27 */ #ifdef CONFIG_SOC_IMX31 const struct imx_imx2_wdt_data imx31_imx2_wdt_data__initconst = - imx_imx2_wdt_data_entry_single(MX31, 0, , SZ_16K); + imx_imx2_wdt_data_entry_single(MX31, 0, "imx21-wdt", , SZ_16K);#endif /* ifdef CONFIG_SOC_IMX31 */ #ifdef CONFIG_SOC_IMX35 const struct imx_imx2_wdt_data imx35_imx2_wdt_data__initconst = - imx_imx2_wdt_data_entry_single(MX35, 0, , SZ_16K); + imx_imx2_wdt_data_entry_single(MX35, 0, "imx35-wdt", , SZ_16K);#endif /* ifdef CONFIG_SOC_IMX35 */ struct platform_device *__init imx_add_imx2_wdt(
@@ -50,6 +51,6 @@ struct platform_device *__init imx_add_imx2_wdt( .flags = IORESOURCE_MEM, }, }; -return imx_add_platform_device ("imx2-wdt" , data->id, +return imx_add_platform_device (data->devname, data->id, res,ARRAY_SIZE (res),NULL ,0 ); }
drivers/watchdog/imx2_wdt.c +51 -8
90 lines not on this page · raw message
Signature · 1 line
2.11.0
Fabio Estevam
reviewerPATCH 1/3 watchdog: imx2: Only i.MX35 and later have a WMCR register
Hi Magnus,
Quoted 11 lines · Uwe Kleine-K?nig
Commit
5fe65ce7ccbb("watchdog:imx2_wdt: Disable power down counter on boot") introduced a write to the WMCR register that doesn't exist on i.MX21, i.MX27 and i.MX31 and so makes the SoC hang during probe.So teach the driver to differentiate between these two types. Note that this effectively undoes commit
5fe65ce7ccbbfor machines using dt until their dtb is updated accordingly. This is critical iff the bootloader doesn't disable the power down counter and the #WDOG signal actually does something to the machine.Signed-off-by Uwe Kleine-K?nig <[email protected]>
Is it possible for you to try this series and let us know if it fixes the mx31 watchdog issue?
Thanks
Fabio Estevam
reviewerPATCH 1/3 watchdog: imx2: Only i.MX35 and later have a WMCR register
In reply to Uwe Kleine-KönigQuoted 11 lines · Uwe Kleine-K?nig
Commit
5fe65ce7ccbb("watchdog:imx2_wdt: Disable power down counter on boot") introduced a write to the WMCR register that doesn't exist on i.MX21, i.MX27 and i.MX31 and so makes the SoC hang during probe.So teach the driver to differentiate between these two types. Note that this effectively undoes commit
5fe65ce7ccbbfor machines using dt until their dtb is updated accordingly. This is critical iff the bootloader doesn't disable the power down counter and the #WDOG signal actually does something to the machine.Signed-off-by Uwe Kleine-K?nig <[email protected]>
PATCH 2/3 dts: teach newer i.MX machines to have the i.MX35 type watchdog
In reply to Uwe Kleine-KönigOnly i.MX35 and newer feature a WMCR register that should be written to. Older SoCs hang when this address is written.
--- Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 +- arch/arm/boot/dts/imx25.dtsi | 2 +- arch/arm/boot/dts/imx35.dtsi | 2 +- arch/arm/boot/dts/imx50.dtsi | 2 +- arch/arm/boot/dts/imx51.dtsi | 2 +- arch/arm/boot/dts/imx53.dtsi | 2 +- arch/arm/boot/dts/imx6qdl.dtsi | 2 +- arch/arm/boot/dts/imx6sl.dtsi | 4 ++-- arch/arm/boot/dts/imx6sx.dtsi | 6 +++--- arch/arm/boot/dts/imx6ul.dtsi | 4 ++-- arch/arm/boot/dts/imx7s.dtsi | 8 ++++---- arch/arm/boot/dts/vfxxx.dtsi | 2 +- 12 files changed, 19 insertions(+), 19 deletions(-)
Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt +1 -1
@@ -15,7 +15,7 @@ Optional properties: Examples: wdt at 73f98000 { - compatible = "fsl,imx51-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx51-wdt", "fsl,imx35-wdt"; reg = <0x73f98000 0x4000>; interrupts = <58>; big-endian;
arch/arm/boot/dts/imx25.dtsi +1 -1
@@ -504,7 +504,7 @@ }; wdog at 53fdc000 { - compatible = "fsl,imx25-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx25-wdt", "fsl,imx35-wdt"; reg = <0x53fdc000 0x4000>; clocks = <&clks 126>; clock-names = "";
arch/arm/boot/dts/imx35.dtsi +1 -1
@@ -286,7 +286,7 @@ }; wdog: wdog at 53fdc000 { - compatible = "fsl,imx35-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx35-wdt"; reg = <0x53fdc000 0x4000>; clocks = <&clks 74>; clock-names = "";
arch/arm/boot/dts/imx50.dtsi +1 -1
@@ -270,7 +270,7 @@ }; wdog1: wdog at 53f98000 { - compatible = "fsl,imx50-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx50-wdt", "fsl,imx35-wdt"; reg = <0x53f98000 0x4000>; interrupts = <58>; clocks = <&clks IMX5_CLK_DUMMY>;
arch/arm/boot/dts/imx51.dtsi +1 -1
@@ -347,7 +347,7 @@ }; wdog1: wdog at 73f98000 { - compatible = "fsl,imx51-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx51-wdt", "fsl,imx35-wdt"; reg = <0x73f98000 0x4000>; interrupts = <58>; clocks = <&clks IMX5_CLK_DUMMY>;
arch/arm/boot/dts/imx53.dtsi +1 -1
@@ -402,7 +402,7 @@ }; wdog1: wdog at 53f98000 { - compatible = "fsl,imx53-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx53-wdt", "fsl,imx35-wdt"; reg = <0x53f98000 0x4000>; interrupts = <58>; clocks = <&clks IMX5_CLK_DUMMY>;
arch/arm/boot/dts/imx6qdl.dtsi +1 -1
@@ -594,7 +594,7 @@ }; wdog1: wdog at 020bc000 { - compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6q-wdt", "fsl,imx35-wdt"; reg = <0x020bc000 0x4000>; interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6QDL_CLK_DUMMY>;
arch/arm/boot/dts/imx6sl.dtsi +2 -2
@@ -479,14 +479,14 @@ }; wdog1: wdog at 020bc000 { - compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6sl-wdt", "fsl,imx35-wdt"; reg = <0x020bc000 0x4000>; interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SL_CLK_DUMMY>; }; wdog2: wdog at 020c0000 { - compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6sl-wdt", "fsl,imx35-wdt"; reg = <0x020c0000 0x4000>; interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SL_CLK_DUMMY>;
arch/arm/boot/dts/imx6sx.dtsi +3 -3
@@ -534,14 +534,14 @@ }; wdog1: wdog at 020bc000 { - compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6sx-wdt", "fsl,imx35-wdt"; reg = <0x020bc000 0x4000>; interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SX_CLK_DUMMY>; }; wdog2: wdog at 020c0000 { - compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6sx-wdt", "fsl,imx35-wdt"; reg = <0x020c0000 0x4000>; interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SX_CLK_DUMMY>;
@@ -1201,7 +1201,7 @@ }; wdog3: wdog at 02288000 { - compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6sx-wdt", "fsl,imx35-wdt"; reg = <0x02288000 0x4000>; interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SX_CLK_DUMMY>;
arch/arm/boot/dts/imx6ul.dtsi +2 -2
@@ -491,14 +491,14 @@ }; wdog1: wdog at 020bc000 { - compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6ul-wdt", "fsl,imx35-wdt"; reg = <0x020bc000 0x4000>; interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6UL_CLK_WDOG1>; }; wdog2: wdog at 020c0000 { - compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx6ul-wdt", "fsl,imx35-wdt"; reg = <0x020c0000 0x4000>; interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6UL_CLK_WDOG2>;
arch/arm/boot/dts/imx7s.dtsi +4 -4
@@ -399,14 +399,14 @@ }; wdog1: wdog at 30280000 { - compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt"; reg = <0x30280000 0x10000>; interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_WDOG1_ROOT_CLK>; }; wdog2: wdog at 30290000 { - compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt"; reg = <0x30290000 0x10000>; interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_WDOG2_ROOT_CLK>;
@@ -414,7 +414,7 @@ }; wdog3: wdog at 302a0000 { - compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt"; reg = <0x302a0000 0x10000>; interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_WDOG3_ROOT_CLK>;
@@ -422,7 +422,7 @@ }; wdog4: wdog at 302b0000 { - compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt"; + compatible = "fsl,imx7d-wdt", "fsl,imx35-wdt"; reg = <0x302b0000 0x10000>; interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX7D_WDOG4_ROOT_CLK>;
arch/arm/boot/dts/vfxxx.dtsi +1 -1
@@ -326,7 +326,7 @@ }; wdoga5: wdog at 4003e000 { - compatible = "fsl,vf610-wdt", "fsl,imx21-wdt"; + compatible = "fsl,vf610-wdt", "fsl,imx35-wdt"; reg = <0x4003e000 0x1000>; interrupts = <20 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks VF610_CLK_WDT>;
Signature · 1 line
2.11.0
Fabio Estevam
reviewerPATCH 2/3 dts: teach newer i.MX machines to have the i.MX35 type watchdog
Quoted 4 lines · Uwe Kleine-K?nig
Only i.MX35 and newer feature a WMCR register that should be written to. Older SoCs hang when this address is written.
Signed-off-by Uwe Kleine-K?nig <[email protected]>
Only a minor nit: Subject could: ARM: dts: imx: teach...
PATCH 2/3 dts: teach newer i.MX machines to have the i.MX35 type watchdog
Quoted 10 lines · Fabio Estevam
Quoted 4 lines · Uwe Kleine-K?nig
Only i.MX35 and newer feature a WMCR register that should be written to. Older SoCs hang when this address is written.
Signed-off-by Uwe Kleine-K?nig <[email protected]>Reviewed-by Fabio Estevam <[email protected]>Only a minor nit: Subject could: ARM: dts: imx: teach...
Ack. To reference the commit id of the first patch in the third I can prepare a branch to pull. There I'd fix the Subject. Shawn, is this OK?
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
PATCH 2/3 dts: teach newer i.MX machines to have the i.MX35 type watchdog
Quoted 6 lines · Uwe Kleine-K?nig
Quoted 5 lines · Fabio Estevam
Quoted 3 lines · Uwe Kleine-K?nig
Only i.MX35 and newer feature a WMCR register that should be written to. Older SoCs hang when this address is written.
Quoted 9 lines
Quoted 5 lines
Quoted 1 line
Signed-off-by Uwe Kleine-K?nig <[email protected]>Reviewed-by Fabio Estevam <[email protected]>Only a minor nit: Subject could: ARM: dts: imx: teach...
Ack. To reference the commit id of the first patch in the third I can prepare a branch to pull. There I'd fix the Subject. Shawn, is this OK?
This is too early for changes, which are not reviewed by Linux watchdog masters.
As I emphasized multiple times in our discussions your series is organized improperly, it has interdependencies between DTS and driver, it lacks atomicity feature of a proper fix, in the middle it breaks backward compatibility with old DTB, all that makes it impossible to send an atomic fix for linux-stable, some of the changes are captured from mine ones without preserving the authorship or even a reported-by credit.
--
With best wishes,
Vladimir
PATCH 2/3 dts: teach newer i.MX machines to have the i.MX35 type watchdog
Hello Vladimir,
Quoted 17 lines · Vladimir Zapolskiy
Quoted 6 lines · Uwe Kleine-K?nig
Quoted 5 lines · Fabio Estevam
Quoted 3 lines · Uwe Kleine-K?nig
Only i.MX35 and newer feature a WMCR register that should be written to. Older SoCs hang when this address is written.
Quoted 9 lines
Quoted 5 lines
Quoted 1 line
Signed-off-by Uwe Kleine-K?nig <[email protected]>Reviewed-by Fabio Estevam <[email protected]>Only a minor nit: Subject could: ARM: dts: imx: teach...
Ack. To reference the commit id of the first patch in the third I can prepare a branch to pull. There I'd fix the Subject. Shawn, is this OK?
Quoted 6 lines
This is too early for changes, which are not reviewed by Linux watchdog masters.
As I emphasized multiple times in our discussions your series is organized improperly, it has interdependencies between DTS and driver, it lacks atomicity feature of a proper fix, in the middle it breaks backward compatibility with old DTB, all that makes it impossible to send an atomic fix for linux-stable,
Oh, I must have missed that. In my inbox there are two replys to my series, the one I reply to being the first to mention these critics.
Regarding your critics:
- organized improperly: that alone is too abstract to understand what you mean.
- interdependencies between DTS and driver, lacks atomicity, impossible to send an atomic fix for linux-stable: I wonder how you want to get rid of that. Yes there are interdependencies, that's because both driver and dts need adaption. Well, I could squash together some of the changes, then there is a single patch that atomically fixes everything. Personally I prefer to have three commits, each one changing a single thing and considering all three together as a fix for stable.
- in the middle it breaks backward compatibility: There are three patches:
1) watchdog: imx2: Only i.MX35 and later have a WMCR register
2) dts: teach newer i.MX machines to have the i.MX35 type watchdog
3) watchdog: imx2: add compatibility for new i.MX35 type watchdog
Before the first patch we have:
- newer i.mx dtsi wrongly claims to have i.mx21 type watchdog
- watchdog handles i.MX21 as if it were i.MX35
After the first patch we have:
- newer i.mx dtsi wrongly claims to have i.mx21 type watchdog
And after the second everything is fine (assuming a dtb not older than the kernel). So each patch fixes a single thing.
Yes, after the first patch machines having an i.MX35 type watchdog might have a problem. That's because there are two things to fix (so there are two patches): The driver must know about the new type and the dts must make use of it. And fixing the first makes the second visible, but doesn't introduce it (after all the i.MX35 dtsi is wrong claiming to have the i.MX21 type).
Now that there are machines known that suffer from the problem under discussion it's obvious that we want the changes from the third patch. Personally I don't care much if it stays separate or is squashed into the first one.
Quoted 2 lines
some of the changes are captured from mine ones without preserving the authorship or even a reported-by credit.
Compared to your v1 the similarities are AFAICT:
- added .data to dt_ids array
- added an if to only conditionally execute the breaking command
- added a new compatible to several dtsi files
All these are necessary to fix the problem discussed here. The way I implemented the first two ones are different to your way. So IMHO it's at least questionable if you or I should be the author of the patches I sent.
I'm ok to add a Reported-by for you. I usually add such a tag only after a request for it. I missed to ask for that, please excuse this.
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
PATCH 3/3 watchdog: imx2: add compatibility for new i.MX35 type watchdog
In reply to Uwe Kleine-KönigWhen the watchdog driver learned about the i.MX35 type watchdog a new compatibility string was introduced. Older dtb continue to use the old fsl,imx21-wdt string and so stop writing the WMCR register which is critical iff the machine powers off when WDOG becomes active and the bootloader doesn't stop the power down counter.
It's unknown which boards are affected and I guess most of them are not. Also note this is only an issue if a new kernel is operated with an old dtb as the SoC dtsi files are fixed accordingly.
XXX: the XXX introduced needs to be changed to HEAD~2 when got a stable commit id.
--- drivers/watchdog/imx2_wdt.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+)
drivers/watchdog/imx2_wdt.c +38 -0
@@ -454,6 +454,44 @@ static const struct of_device_id imx2_wdt_dt_ids[] = { }, { .compatible = "fsl,imx35-wdt", .data = &imx2_wdt_type_imx35, + }, + /* + * The following ids are only there to make commit XXX compatible with + * older device trees. The result is that iff the machine makes use of + * the WDG signal (most don't, only WDG_RST is used) and the bootloader + * doesn't stop the power down counter it powers off the board after 16 + * seconds. + */ + { + .compatible = "fsl,imx25-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx50-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx51-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx53-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx6q-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx6sl-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx6sx-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx6ul-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,imx7d-wdt", + .data = &imx2_wdt_type_imx35, + }, { + .compatible = "fsl,vf610-wdt", + .data = &imx2_wdt_type_imx35, }, { /* sentinel */ }
Signature · 1 line
2.11.0
Fabio Estevam
reviewerPATCH 3/3 watchdog: imx2: add compatibility for new i.MX35 type watchdog
Quoted 7 lines · Uwe Kleine-K?nig
When the watchdog driver learned about the i.MX35 type watchdog a new compatibility string was introduced. Older dtb continue to use the old fsl,imx21-wdt string and so stop writing the WMCR register which is critical iff the machine powers off when WDOG becomes active and the bootloader doesn't stop the power down counter.
It's unknown which boards are affected and I guess most of them are not.
At least imx31 pdk is affected.
Quoted 4 lines
Also note this is only an issue if a new kernel is operated with an old dtb as the SoC dtsi files are fixed accordingly.
XXX: the XXX introduced needs to be changed to HEAD~2 when got a stable commit id.
This comment should not be here.
Other than that:
cover watchdog: imx2: handle WMCR only being available on i.MX35 and later
In reply to Uwe Kleine-KönigHello Uwe,
Quoted 10 lines · Uwe Kleine-K?nig
Hello,
this is my approach to fix the issue reported by Vladimir Zapolskiy.
IMHO we don't need the third commit because I'm convinced most machines just don't do anything when the WDOG signal becomes active. An affected machine powers off 16 seconds after startup. This would be noticed during development of the bootloader and so I assume all affected machines having bootloaders that make the compat code unimportant.
Quoted 3 lines
If you want to know if your machine is affected, do:
mw -w $(watchdog_base_addr) 0x10
is it a command in barebox shell?
Quoted 10 lines
The machines I tested this on (among a few customer boards a Phycore i.MX35 and a Freescale i.MX53 Quick Start Board) don't power off.
I don't have manuals handy for ls1021a, ls1043a and ls1046a but assume they use the i.MX35 type, too. This needs to be fixed before this series is applied.
Compared to Vladimir's patch machines still using board files are fixed, too.
This addition can be done on top of my changes, in my version the driver ignores WMCR on all machines with board files.
So now we have two competing series unfortunately...
--
With best wishes,
Vladimir
cover watchdog: imx2: handle WMCR only being available on i.MX35 and later
Hello Vladimir,
Quoted 11 lines · Vladimir Zapolskiy
Quoted 10 lines · Uwe Kleine-K?nig
Hello,
this is my approach to fix the issue reported by Vladimir Zapolskiy.
IMHO we don't need the third commit because I'm convinced most machines just don't do anything when the WDOG signal becomes active. An affected machine powers off 16 seconds after startup. This would be noticed during development of the bootloader and so I assume all affected machines having bootloaders that make the compat code unimportant.
Quoted 5 lines
Quoted 3 lines
If you want to know if your machine is affected, do:
mw -w $(watchdog_base_addr) 0x10is it a command in barebox shell?
barebox cannot do $(watchdog_base_addr), but (on i.MX25) I can do:
mw -w 0x53fdc000 0x10
. I think the corresponding U-Boot command is:
mw.w 0x53fdc000 0x10
Quoted 7 lines
Quoted 7 lines
The machines I tested this on (among a few customer boards a Phycore i.MX35 and a Freescale i.MX53 Quick Start Board) don't power off.
I don't have manuals handy for ls1021a, ls1043a and ls1046a but assume they use the i.MX35 type, too. This needs to be fixed before this series is applied.
Quoted 8 lines
Quoted 3 lines
Compared to Vladimir's patch machines still using board files are fixed, too.
This addition can be done on top of my changes, in my version the driver ignores WMCR on all machines with board files.
So now we have two competing series unfortunately...
With mine being the better one, right? :-)
You didn't update your series for my concerns, so I did it myself instead of retrying to iterate about the changes I'd like to see on your version. Feel free to criticise my variant.
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
Guenter Roeck
maintainercover watchdog: imx2: handle WMCR only being available on i.MX35 and later
In reply to Uwe Kleine-KönigQuoted 4 lines · Uwe Kleine-K?nig
Hello,
this is my approach to fix the issue reported by Vladimir Zapolskiy.
So ...
Unfortunately, I don't see any convergence on this issue. My take is that, given the lack of convergence, it can't be that severe since no one feels that it is important enough to get it fixed one way or the other to budge from your positions.
I had the other patch in my watchdog-next branch. I'll drop it, and wait for the two of you to agree to something. You can either agree to that something, or try to convince Wim to accept one or the other patch set. For my part, I'll only accept a patch or patch series which has a Signed-off: and/or Reviewed-by:
from both of you.
Maybe you can get together into a room and agree not to leave it until white smoke comes out of the chimney. Just an idea.
Thanks,
Guenter
cover watchdog: imx2: handle WMCR only being available on i.MX35 and later
Quoted 9 lines · Guenter Roeck
Quoted 2 lines · Uwe Kleine-K?nig
this is my approach to fix the issue reported by Vladimir Zapolskiy.
So ...
Unfortunately, I don't see any convergence on this issue. My take is that, given the lack of convergence, it can't be that severe since no one feels that it is important enough to get it fixed one way or the other to budge from your positions.
I didn't get any critic for my patch set yet apart from being a second one to address the same problem. So until proven differently I assume that mine is fine.
Best regards
Uwe
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
cover watchdog: imx2: handle WMCR only being available on i.MX35 and later
In reply to Uwe Kleine-KönigHi,
Quoted 4 lines · Uwe Kleine-K?nig
Hello,
this is my approach to fix the issue reported by Vladimir Zapolskiy.
...
Quoted 8 lines
Best regards
UweUwe Kleine-K?nig (3):
watchdog: imx2: Only i.MX35 and later have a WMCR register
dts: teach newer i.MX machines to have the i.MX35 type watchdog
watchdog: imx2: add compatibility for new i.MX35 type watchdog
Quoted 16 lines
.../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 +- arch/arm/boot/dts/imx25.dtsi | 2 +- arch/arm/boot/dts/imx35.dtsi | 2 +- arch/arm/boot/dts/imx50.dtsi | 2 +- arch/arm/boot/dts/imx51.dtsi | 2 +- arch/arm/boot/dts/imx53.dtsi | 2 +- arch/arm/boot/dts/imx6qdl.dtsi | 2 +- arch/arm/boot/dts/imx6sl.dtsi | 4 +- arch/arm/boot/dts/imx6sx.dtsi | 6 +- arch/arm/boot/dts/imx6ul.dtsi | 4 +- arch/arm/boot/dts/imx7s.dtsi | 8 +- arch/arm/boot/dts/vfxxx.dtsi | 2 +- arch/arm/mach-imx/devices/devices-common.h | 1 + arch/arm/mach-imx/devices/platform-imx2-wdt.c | 13 +-- drivers/watchdog/imx2_wdt.c | 97 ++++++++++++++++++++-- 15 files changed, 116 insertions(+), 33 deletions(-)
Tested on i.MX31 PDK board.