| Message ID | 1443559446-26969-12-git-send-email-balbi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > All devices should have a default status. Ignoring > the arguments if it should be 'okay' or 'disabled' > by default, let's set them all the 'disabled' and > have boards enable 32k counter. > > Signed-off-by: Felipe Balbi <balbi@ti.com> > The patch looks good, but the description is slightly incorrect: There is no reason to list "status='okay'" other than overriding the 'disabled' status. I'd phrase it something like: "We want the use of the 32k counter to be a per-board setting, so let's disable it by default in each dtsi file and override the setting in the boards. Any board that does not wire up the counter should leave it disabled". However, if you really want all boards to provide the counter all the time, I'd argue that we're better off dropping this patch. We use the status="disabled" trick for anything that may or may not be working based on the board design, but things that are present everywhere don't need this. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote: > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > > All devices should have a default status. Ignoring > > the arguments if it should be 'okay' or 'disabled' > > by default, let's set them all the 'disabled' and > > have boards enable 32k counter. > > > > Signed-off-by: Felipe Balbi <balbi@ti.com> > > > > The patch looks good, but the description is slightly incorrect: > There is no reason to list "status='okay'" other than overriding > the 'disabled' status. > > I'd phrase it something like: > > "We want the use of the 32k counter to be a per-board setting, > so let's disable it by default in each dtsi file and override the > setting in the boards. Any board that does not wire up the counter > should leave it disabled". > > However, if you really want all boards to provide the counter all > the time, I'd argue that we're better off dropping this patch. We > use the status="disabled" trick for anything that may or may not > be working based on the board design, but things that are present > everywhere don't need this. okay, so here's the thing. While fiddling with the 32k counter, I noticed that even though there was no status listed, the thing still initializes fine. However, when moving 32k to drivers/clocksource and using CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit status = "okay" in DT. This is where this patch came from. I've used disabled by default because we just might have a board somewhere which doesn't want to use 32k counter and having it enabled per-board would help with that. Although, we could just set status = "disabled" for that one board. Whatever Tony prefers, I can change the patch accordingly.
On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote: > On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote: > > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > > > All devices should have a default status. Ignoring > > > the arguments if it should be 'okay' or 'disabled' > > > by default, let's set them all the 'disabled' and > > > have boards enable 32k counter. > > > > > > Signed-off-by: Felipe Balbi <balbi@ti.com> > > > > > > > The patch looks good, but the description is slightly incorrect: > > There is no reason to list "status='okay'" other than overriding > > the 'disabled' status. > > > > I'd phrase it something like: > > > > "We want the use of the 32k counter to be a per-board setting, > > so let's disable it by default in each dtsi file and override the > > setting in the boards. Any board that does not wire up the counter > > should leave it disabled". > > > > However, if you really want all boards to provide the counter all > > the time, I'd argue that we're better off dropping this patch. We > > use the status="disabled" trick for anything that may or may not > > be working based on the board design, but things that are present > > everywhere don't need this. > > okay, so here's the thing. While fiddling with the 32k counter, I noticed > that even though there was no status listed, the thing still initializes > fine. However, when moving 32k to drivers/clocksource and using > CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit > status = "okay" in DT. Very strange, that sounds like a bug in the clocksource probe code. Can you check how this happens? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Felipe Balbi <balbi@ti.com> [150929 13:48]: > All devices should have a default status. Ignoring > the arguments if it should be 'okay' or 'disabled' > by default, let's set them all the 'disabled' and > have boards enable 32k counter. We should not use "disabled" really at all. That means no struct device is ever created while that hardawre is there for the internal devices for sure. Also, we should use the 32k counter as the default one as that's always on for deeper idle states. For cases where the 32k ocillator is not available, it's better to just set the source clock rate to 0 in the board specific dts file and have the driver bail out early if source clock rate is 0. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 30, 2015 at 11:58:16PM +0200, Arnd Bergmann wrote: > On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote: > > On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote: > > > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: > > > > All devices should have a default status. Ignoring > > > > the arguments if it should be 'okay' or 'disabled' > > > > by default, let's set them all the 'disabled' and > > > > have boards enable 32k counter. > > > > > > > > Signed-off-by: Felipe Balbi <balbi@ti.com> > > > > > > > > > > The patch looks good, but the description is slightly incorrect: > > > There is no reason to list "status='okay'" other than overriding > > > the 'disabled' status. > > > > > > I'd phrase it something like: > > > > > > "We want the use of the 32k counter to be a per-board setting, > > > so let's disable it by default in each dtsi file and override the > > > setting in the boards. Any board that does not wire up the counter > > > should leave it disabled". > > > > > > However, if you really want all boards to provide the counter all > > > the time, I'd argue that we're better off dropping this patch. We > > > use the status="disabled" trick for anything that may or may not > > > be working based on the board design, but things that are present > > > everywhere don't need this. > > > > okay, so here's the thing. While fiddling with the 32k counter, I noticed > > that even though there was no status listed, the thing still initializes > > fine. However, when moving 32k to drivers/clocksource and using > > CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit > > status = "okay" in DT. > > Very strange, that sounds like a bug in the clocksource probe code. > Can you check how this happens? seems like something overwrites counter's status field, here's a snippet of boot log: [ 0.000000] ===> counter is available ?? [ 0.000000] ===> no status -> TRUE!! [ 0.000000] ===> searching for timer [ 0.000000] ===> timer is available ?? [ 0.000000] ===> no status -> TRUE!! [ 0.000005] sched_clock: 64 bits at 1000MHz, resolution 1ns, wraps every 4398046511103ns [ 0.000014] clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.000047] ===> searching for timer [ 0.000051] ===> timer is available ?? [ 0.000054] ===> no status -> TRUE!! [ 0.000307] ===> searching for counter [ 0.000311] ===> counter is available ?? [ 0.000315] ===> counter status disabled [ 0.000318] ====> counter NOT available note that first time around counter had no status and later it got a status disabled from somewhere.
Felipe Balbi <balbi@ti.com> writes: > On Wed, Sep 30, 2015 at 11:58:16PM +0200, Arnd Bergmann wrote: >> On Wednesday 30 September 2015 09:12:09 Felipe Balbi wrote: >> > On Wed, Sep 30, 2015 at 10:15:25AM +0200, Arnd Bergmann wrote: >> > > On Tuesday 29 September 2015 15:44:06 Felipe Balbi wrote: >> > > > All devices should have a default status. Ignoring >> > > > the arguments if it should be 'okay' or 'disabled' >> > > > by default, let's set them all the 'disabled' and >> > > > have boards enable 32k counter. >> > > > >> > > > Signed-off-by: Felipe Balbi <balbi@ti.com> >> > > > >> > > >> > > The patch looks good, but the description is slightly incorrect: >> > > There is no reason to list "status='okay'" other than overriding >> > > the 'disabled' status. >> > > >> > > I'd phrase it something like: >> > > >> > > "We want the use of the 32k counter to be a per-board setting, >> > > so let's disable it by default in each dtsi file and override the >> > > setting in the boards. Any board that does not wire up the counter >> > > should leave it disabled". >> > > >> > > However, if you really want all boards to provide the counter all >> > > the time, I'd argue that we're better off dropping this patch. We >> > > use the status="disabled" trick for anything that may or may not >> > > be working based on the board design, but things that are present >> > > everywhere don't need this. >> > >> > okay, so here's the thing. While fiddling with the 32k counter, I noticed >> > that even though there was no status listed, the thing still initializes >> > fine. However, when moving 32k to drivers/clocksource and using >> > CLOCKSOURCE_OF_DECLARE(), 32k would *NOT* probe unless I had an explicit >> > status = "okay" in DT. >> >> Very strange, that sounds like a bug in the clocksource probe code. >> Can you check how this happens? > > seems like something overwrites counter's status field, here's a snippet of boot > log: > > [ 0.000000] ===> counter is available ?? > [ 0.000000] ===> no status -> TRUE!! > [ 0.000000] ===> searching for timer > [ 0.000000] ===> timer is available ?? > [ 0.000000] ===> no status -> TRUE!! > [ 0.000005] sched_clock: 64 bits at 1000MHz, resolution 1ns, wraps every 4398046511103ns > [ 0.000014] clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns > [ 0.000047] ===> searching for timer > [ 0.000051] ===> timer is available ?? > [ 0.000054] ===> no status -> TRUE!! > [ 0.000307] ===> searching for counter > [ 0.000311] ===> counter is available ?? > [ 0.000315] ===> counter status disabled > [ 0.000318] ====> counter NOT available > > note that first time around counter had no status and later it got a status > disabled from somewhere. found it. arch/arm/mach-omap2/timer.c is the culprit: /** * omap_get_timer_dt - get a timer using device-tree * @match - device-tree match structure for matching a device type * @property - optional timer property to match * * Helper function to get a timer during early boot using device-tree for use * as kernel system timer. Optionally, the property argument can be used to * select a timer with a specific property. Once a timer is found then mark * the timer node in device-tree as disabled, to prevent the kernel from * registering this timer as a platform device and so no one else can use it. */ static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match, const char *property) { struct device_node *np; for_each_matching_node(np, match) { if (!of_device_is_available(np)) continue; if (property && !of_get_property(np, property, NULL)) continue; if (!property && (of_get_property(np, "ti,timer-alwon", NULL) || of_get_property(np, "ti,timer-dsp", NULL) || of_get_property(np, "ti,timer-pwm", NULL) || of_get_property(np, "ti,timer-secure", NULL))) continue; of_add_property(np, &device_disabled); return np; } return NULL; } I'll patch this up and drop $subject
On Monday 05 October 2015 14:41:07 Felipe Balbi wrote: > > /** > * omap_get_timer_dt - get a timer using device-tree > * @match - device-tree match structure for matching a device type > * @property - optional timer property to match > * > * Helper function to get a timer during early boot using device-tree for use > * as kernel system timer. Optionally, the property argument can be used to > * select a timer with a specific property. Once a timer is found then mark > * the timer node in device-tree as disabled, to prevent the kernel from > * registering this timer as a platform device and so no one else can use it. > */ > static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match, > const char *property) > { > struct device_node *np; > > for_each_matching_node(np, match) { > if (!of_device_is_available(np)) > continue; > > if (property && !of_get_property(np, property, NULL)) > continue; > > if (!property && (of_get_property(np, "ti,timer-alwon", NULL) || > of_get_property(np, "ti,timer-dsp", NULL) || > of_get_property(np, "ti,timer-pwm", NULL) || > of_get_property(np, "ti,timer-secure", NULL))) > continue; > > of_add_property(np, &device_disabled); > return np; > } > > return NULL; > } > > I'll patch this up and drop $subject > Ah, good. I'm seeing the "ti,timer-alwon" property here, we probably need to take that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if that isn't how it gets done already. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Arnd Bergmann <arnd@arndb.de> writes: > On Monday 05 October 2015 14:41:07 Felipe Balbi wrote: >> >> /** >> * omap_get_timer_dt - get a timer using device-tree >> * @match - device-tree match structure for matching a device type >> * @property - optional timer property to match >> * >> * Helper function to get a timer during early boot using device-tree for use >> * as kernel system timer. Optionally, the property argument can be used to >> * select a timer with a specific property. Once a timer is found then mark >> * the timer node in device-tree as disabled, to prevent the kernel from >> * registering this timer as a platform device and so no one else can use it. >> */ >> static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match, >> const char *property) >> { >> struct device_node *np; >> >> for_each_matching_node(np, match) { >> if (!of_device_is_available(np)) >> continue; >> >> if (property && !of_get_property(np, property, NULL)) >> continue; >> >> if (!property && (of_get_property(np, "ti,timer-alwon", NULL) || >> of_get_property(np, "ti,timer-dsp", NULL) || >> of_get_property(np, "ti,timer-pwm", NULL) || >> of_get_property(np, "ti,timer-secure", NULL))) >> continue; >> >> of_add_property(np, &device_disabled); >> return np; >> } >> >> return NULL; >> } >> >> I'll patch this up and drop $subject >> > > Ah, good. > > I'm seeing the "ti,timer-alwon" property here, we probably need to take > that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if > that isn't how it gets done already. that flag is not set for 32k in any dts. Seems like it should, though, judging by the binding documentation: - ti,timer-alwon: Indicates the timer is in an alway-on power domain. Tony, care to comment if we should add timer-alwon to 32k ?
* Felipe Balbi <balbi@ti.com> [151006 08:02]: > Arnd Bergmann <arnd@arndb.de> writes: > > > On Monday 05 October 2015 14:41:07 Felipe Balbi wrote: > >> > >> /** > >> * omap_get_timer_dt - get a timer using device-tree > >> * @match - device-tree match structure for matching a device type > >> * @property - optional timer property to match > >> * > >> * Helper function to get a timer during early boot using device-tree for use > >> * as kernel system timer. Optionally, the property argument can be used to > >> * select a timer with a specific property. Once a timer is found then mark > >> * the timer node in device-tree as disabled, to prevent the kernel from > >> * registering this timer as a platform device and so no one else can use it. > >> */ > >> static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match, > >> const char *property) > >> { > >> struct device_node *np; > >> > >> for_each_matching_node(np, match) { > >> if (!of_device_is_available(np)) > >> continue; > >> > >> if (property && !of_get_property(np, property, NULL)) > >> continue; > >> > >> if (!property && (of_get_property(np, "ti,timer-alwon", NULL) || > >> of_get_property(np, "ti,timer-dsp", NULL) || > >> of_get_property(np, "ti,timer-pwm", NULL) || > >> of_get_property(np, "ti,timer-secure", NULL))) > >> continue; > >> > >> of_add_property(np, &device_disabled); > >> return np; > >> } > >> > >> return NULL; > >> } > >> > >> I'll patch this up and drop $subject > >> > > > > Ah, good. > > > > I'm seeing the "ti,timer-alwon" property here, we probably need to take > > that into account when setting the CLOCK_SOURCE_SUSPEND_NONSTOP flag, if > > that isn't how it gets done already. > > that flag is not set for 32k in any dts. Seems like it should, though, > judging by the binding documentation: > > - ti,timer-alwon: Indicates the timer is in an alway-on power > domain. > > Tony, care to comment if we should add timer-alwon to 32k ? No that should not be needed for the 32k counter. We should be able to do everything we want with CLOCK_SOURCE_SUSPEND_NONSTOP for the 32k counter. We still need ti,timer-alwon for a while for gptimers 1 and 12 as they are the only ones in the always-on domain. I guess that need will eventually go away too once we have a proper interconnect driver and are using genpd. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Tony Lindgren <tony@atomide.com> writes: > * Felipe Balbi <balbi@ti.com> [151006 08:02]: >> - ti,timer-alwon: Indicates the timer is in an alway-on power >> domain. >> >> Tony, care to comment if we should add timer-alwon to 32k ? > > No that should not be needed for the 32k counter. We should be able > to do everything we want with CLOCK_SOURCE_SUSPEND_NONSTOP for the > 32k counter. > > We still need ti,timer-alwon for a while for gptimers 1 and 12 as > they are the only ones in the always-on domain. I guess that need > will eventually go away too once we have a proper interconnect > driver and are using genpd. cool, thanks. I'll try to respin this series, hopefully still this week.
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index 0447c04a40cc..0a3e0a82ea96 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -349,6 +349,7 @@ compatible = "ti,am4372-counter32k","ti,omap-counter32k"; reg = <0x44e86000 0x40>; ti,hwmods = "counter_32k"; + status = "disabled"; }; rtc: rtc@44e3e000 { diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index 22038f21f228..f4b6cb6efde3 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -954,3 +954,7 @@ clock-names = "ext-clk", "int-clk"; status = "okay"; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts b/arch/arm/boot/dts/am437x-idk-evm.dts index af25801418b4..17c429d4e136 100644 --- a/arch/arm/boot/dts/am437x-idk-evm.dts +++ b/arch/arm/boot/dts/am437x-idk-evm.dts @@ -413,3 +413,7 @@ &cpu { cpu0-supply = <&tps>; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts index 7da7c2da4af1..f0d9d26e644e 100644 --- a/arch/arm/boot/dts/am437x-sk-evm.dts +++ b/arch/arm/boot/dts/am437x-sk-evm.dts @@ -734,3 +734,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index 86c2dfbe8875..9a0cd866e3ab 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -792,3 +792,7 @@ tx-num-evt = <32>; rx-num-evt = <32>; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 5d65db9ebc2b..a6f2072b6c46 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -193,6 +193,7 @@ compatible = "ti,omap-counter32k"; reg = <0x4000 0x40>; ti,hwmods = "counter_32k"; + status = "disabled"; }; prm: prm@6000 { diff --git a/arch/arm/boot/dts/omap2420-h4.dts b/arch/arm/boot/dts/omap2420-h4.dts index 34cdecb4fdda..f41d95836dcf 100644 --- a/arch/arm/boot/dts/omap2420-h4.dts +++ b/arch/arm/boot/dts/omap2420-h4.dts @@ -64,3 +64,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi index 5b9a376cc31e..abef0670e7e6 100644 --- a/arch/arm/boot/dts/omap2420.dtsi +++ b/arch/arm/boot/dts/omap2420.dtsi @@ -70,6 +70,7 @@ compatible = "ti,omap-counter32k"; reg = <0x4000 0x20>; ti,hwmods = "counter_32k"; + status = "disabled"; }; }; diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi index 2390f387c271..f501b6f355a4 100644 --- a/arch/arm/boot/dts/omap2430.dtsi +++ b/arch/arm/boot/dts/omap2430.dtsi @@ -82,6 +82,7 @@ compatible = "ti,omap-counter32k"; reg = <0x20000 0x20>; ti,hwmods = "counter_32k"; + status = "disabled"; }; }; diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts index 7c4dca122a91..47a354f22363 100644 --- a/arch/arm/boot/dts/omap3-beagle-xm.dts +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts @@ -390,3 +390,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts index a5474113cd50..3a50baa56399 100644 --- a/arch/arm/boot/dts/omap3-beagle.dts +++ b/arch/arm/boot/dts/omap3-beagle.dts @@ -429,3 +429,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts index bd6e6769c7ce..58ef3e86c31f 100644 --- a/arch/arm/boot/dts/omap3-ldp.dts +++ b/arch/arm/boot/dts/omap3-ldp.dts @@ -302,3 +302,7 @@ /* Needed for ads7846 */ regulator-name = "vcc"; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts index 5f5e0f3d5b64..0f9405ef4dc7 100644 --- a/arch/arm/boot/dts/omap3-n900.dts +++ b/arch/arm/boot/dts/omap3-n900.dts @@ -988,3 +988,7 @@ &ssi_port2 { status = "disabled"; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 69a40cfc1f29..1bc8fb05d4bd 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -181,6 +181,7 @@ compatible = "ti,omap-counter32k"; reg = <0x48320000 0x20>; ti,hwmods = "counter_32k"; + status = "disabled"; }; intc: interrupt-controller@48200000 { diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts index 16b0cdfbee9c..8344e1d01ac6 100644 --- a/arch/arm/boot/dts/omap3430-sdp.dts +++ b/arch/arm/boot/dts/omap3430-sdp.dts @@ -191,3 +191,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts index dac86ed7481f..d54ee6605af0 100644 --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -697,3 +697,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index abc4473e6f8a..76371eb9fa02 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -220,6 +220,7 @@ compatible = "ti,omap-counter32k"; reg = <0x4000 0x20>; ti,hwmods = "counter_32k"; + status = "disabled"; }; prm: prm@6000 { diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts b/arch/arm/boot/dts/omap5-cm-t54.dts index 61ad2ea34720..d88f9bf1ce28 100644 --- a/arch/arm/boot/dts/omap5-cm-t54.dts +++ b/arch/arm/boot/dts/omap5-cm-t54.dts @@ -677,3 +677,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 3cc8f357d5b8..ecf8db4ea64b 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -641,3 +641,7 @@ }; }; }; + +&counter32k { + status = "okay"; +}; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 4205a8ac9ddb..aa8216a5bf4f 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -236,6 +236,7 @@ compatible = "ti,omap-counter32k"; reg = <0x4000 0x40>; ti,hwmods = "counter_32k"; + status = "disabled"; }; prm: prm@6000 {
All devices should have a default status. Ignoring the arguments if it should be 'okay' or 'disabled' by default, let's set them all the 'disabled' and have boards enable 32k counter. Signed-off-by: Felipe Balbi <balbi@ti.com> --- arch/arm/boot/dts/am4372.dtsi | 1 + arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++++ arch/arm/boot/dts/am437x-idk-evm.dts | 4 ++++ arch/arm/boot/dts/am437x-sk-evm.dts | 4 ++++ arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++++ arch/arm/boot/dts/dra7.dtsi | 1 + arch/arm/boot/dts/omap2420-h4.dts | 4 ++++ arch/arm/boot/dts/omap2420.dtsi | 1 + arch/arm/boot/dts/omap2430.dtsi | 1 + arch/arm/boot/dts/omap3-beagle-xm.dts | 4 ++++ arch/arm/boot/dts/omap3-beagle.dts | 4 ++++ arch/arm/boot/dts/omap3-ldp.dts | 4 ++++ arch/arm/boot/dts/omap3-n900.dts | 4 ++++ arch/arm/boot/dts/omap3.dtsi | 1 + arch/arm/boot/dts/omap3430-sdp.dts | 4 ++++ arch/arm/boot/dts/omap4-sdp.dts | 4 ++++ arch/arm/boot/dts/omap4.dtsi | 1 + arch/arm/boot/dts/omap5-cm-t54.dts | 4 ++++ arch/arm/boot/dts/omap5-uevm.dts | 4 ++++ arch/arm/boot/dts/omap5.dtsi | 1 + 20 files changed, 59 insertions(+)