arm: omap2: timer: don't disable our timers
diff mbox

Message ID 1444074528-3905-1-git-send-email-balbi@ti.com
State New
Headers show

Commit Message

Felipe Balbi Oct. 5, 2015, 7:48 p.m. UTC
We actually want these devices to be created because
we will be moving timers to drivers/clocksource and
this will prevent them from probing.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---

Tony, I wonder if you can get merged as a fix, or do you
prefer receiving it together with my timer series ?

 arch/arm/mach-omap2/timer.c | 11 +----------
 1 file changed, 1 insertion(+), 10 deletions(-)

Comments

Suman Anna Oct. 5, 2015, 10:22 p.m. UTC | #1
Hi Felipe,

On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
> We actually want these devices to be created because
> we will be moving timers to drivers/clocksource and
> this will prevent them from probing.

This logic is also used to remove the secure timer from being
registered to the kernel on HS devices, while allowing the timer to be
available on GP devices. Your patch actually would break that
functionality. I suggest that you look at the history of the code that
originally added this logic - this function seems to be designed to
actually remove the node. The OMAP DMTimer provides an API to request
timers, and I think this logic was used to eliminate giving out the
timers used for clocksource and clockevent when the driver got adapted
to DT.

> 
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> 
> Tony, I wonder if you can get merged as a fix, or do you
> prefer receiving it together with my timer series ?

NAK for rc, as it breaks other stuff.

regards
Suman

> 
>  arch/arm/mach-omap2/timer.c | 11 +----------
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 0ff676273b4b..0c00138d7bd5 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -136,12 +136,6 @@ static struct clock_event_device clockevent_gpt = {
>  	.tick_resume		= omap2_gp_timer_shutdown,
>  };
>  
> -static struct property device_disabled = {
> -	.name = "status",
> -	.length = sizeof("disabled"),
> -	.value = "disabled",
> -};
> -
>  static const struct of_device_id omap_timer_match[] __initconst = {
>  	{ .compatible = "ti,omap2420-timer", },
>  	{ .compatible = "ti,omap3430-timer", },
> @@ -161,9 +155,7 @@ static const struct of_device_id omap_timer_match[] __initconst = {
>   *
>   * 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.
> + * select a timer with a specific property.
>   */
>  static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match,
>  						     const char *property)
> @@ -183,7 +175,6 @@ static struct device_node * __init omap_get_timer_dt(const struct of_device_id *
>  				  of_get_property(np, "ti,timer-secure", NULL)))
>  			continue;
>  
> -		of_add_property(np, &device_disabled);
>  		return np;
>  	}
>  
> 

--
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 Oct. 5, 2015, 10:46 p.m. UTC | #2
Suman Anna <s-anna@ti.com> writes:

> Hi Felipe,
>
> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>> We actually want these devices to be created because
>> we will be moving timers to drivers/clocksource and
>> this will prevent them from probing.
>
> This logic is also used to remove the secure timer from being
> registered to the kernel on HS devices, while allowing the timer to be
> available on GP devices. Your patch actually would break that
> functionality. I suggest that you look at the history of the code that

heh, that's a silly way of doing so. Could just detect if we're running
on HS or not.

> originally added this logic - this function seems to be designed to
> actually remove the node. The OMAP DMTimer provides an API to request
> timers, and I think this logic was used to eliminate giving out the
> timers used for clocksource and clockevent when the driver got adapted
> to DT.

again not the best way of achieving what you want. In any case, other
than ir-rx51.c who's using that API ? Seems like we could just pass a
phandle to ir-rx51 and be done with it.

>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> ---
>> 
>> Tony, I wonder if you can get merged as a fix, or do you
>> prefer receiving it together with my timer series ?
>
> NAK for rc, as it breaks other stuff.

a single stuff which is likely easy enough to fix. But fair enough

--
balbi
Suman Anna Oct. 5, 2015, 11:41 p.m. UTC | #3
Hi Felipe,

>>
>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>> We actually want these devices to be created because
>>> we will be moving timers to drivers/clocksource and
>>> this will prevent them from probing.
>>
>> This logic is also used to remove the secure timer from being
>> registered to the kernel on HS devices, while allowing the timer to be
>> available on GP devices. Your patch actually would break that
>> functionality. I suggest that you look at the history of the code that
> 
> heh, that's a silly way of doing so. Could just detect if we're running
> on HS or not.

This function is invoked only after detecting that we are running on a
HS device.

> 
>> originally added this logic - this function seems to be designed to
>> actually remove the node. The OMAP DMTimer provides an API to request
>> timers, and I think this logic was used to eliminate giving out the
>> timers used for clocksource and clockevent when the driver got adapted
>> to DT.
> 
> again not the best way of achieving what you want. In any case, other
> than ir-rx51.c who's using that API ? Seems like we could just pass a
> phandle to ir-rx51 and be done with it.

We will gain a user from OMAP remoteproc driver as well (out of tree at
the moment, but it does follow the DT phandle and
omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
converted to DT, and also some of the API are alive just because of the
continued OMAP3 legacy boot support. Guess, it is a just a question of
not breaking existing API until we kill some of them.

> 
>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>> ---
>>>
>>> Tony, I wonder if you can get merged as a fix, or do you
>>> prefer receiving it together with my timer series ?
>>
>> NAK for rc, as it breaks other stuff.
> 
> a single stuff which is likely easy enough to fix. But fair enough

Don't think this patch is fixing any critical bug either, better to club
it with your cleanup series.

regards
Suman

--
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
Sebastian Reichel Oct. 6, 2015, 12:43 a.m. UTC | #4
Hi,

On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote:
> We will gain a user from OMAP remoteproc driver as well (out of tree at
> the moment, but it does follow the DT phandle and
> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
> converted to DT, and also some of the API are alive just because of the
> continued OMAP3 legacy boot support. Guess, it is a just a question of
> not breaking existing API until we kill some of them.

Right, ir-rx51 has not yet been converted to DT. Additionally it
depends !ARCH_MULTIPLATFORM, since it requires <plat/dmtimer.h>.

I remember a patchset adding a omap-pwm driver using dmtimers. If
that was added to the kernel, ir-rx51 could probably be switched to
the PWM API + hrtimer API instead of depending on the dmtimer API.
At the end not much is gained, though, since then the PWM driver
would probably require the dmtimer API.

-- Sebastian
Felipe Balbi Oct. 6, 2015, 12:55 a.m. UTC | #5
Suman Anna <s-anna@ti.com> writes:

> Hi Felipe,
>
>>>
>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>>> We actually want these devices to be created because
>>>> we will be moving timers to drivers/clocksource and
>>>> this will prevent them from probing.
>>>
>>> This logic is also used to remove the secure timer from being
>>> registered to the kernel on HS devices, while allowing the timer to be
>>> available on GP devices. Your patch actually would break that
>>> functionality. I suggest that you look at the history of the code that
>> 
>> heh, that's a silly way of doing so. Could just detect if we're running
>> on HS or not.
>
> This function is invoked only after detecting that we are running on a
> HS device.

What actually disables the timer is omap_get_timer_dt() and that's
called in more than one place.

>>> originally added this logic - this function seems to be designed to
>>> actually remove the node. The OMAP DMTimer provides an API to request
>>> timers, and I think this logic was used to eliminate giving out the
>>> timers used for clocksource and clockevent when the driver got adapted
>>> to DT.
>> 
>> again not the best way of achieving what you want. In any case, other
>> than ir-rx51.c who's using that API ? Seems like we could just pass a
>> phandle to ir-rx51 and be done with it.
>
> We will gain a user from OMAP remoteproc driver as well (out of tree at
> the moment, but it does follow the DT phandle and
> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
> converted to DT, and also some of the API are alive just because of the
> continued OMAP3 legacy boot support. Guess, it is a just a question of
> not breaking existing API until we kill some of them.

sure, but until remoteproc gets upstream, it's only 1 user ;-)

>>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>> ---
>>>>
>>>> Tony, I wonder if you can get merged as a fix, or do you
>>>> prefer receiving it together with my timer series ?
>>>
>>> NAK for rc, as it breaks other stuff.
>> 
>> a single stuff which is likely easy enough to fix. But fair enough
>
> Don't think this patch is fixing any critical bug either, better to club
> it with your cleanup series.

it is kinda critical when you consider that the timer is disabled
outside of the soc type detection.
Felipe Balbi Oct. 6, 2015, 12:57 a.m. UTC | #6
Hi,

Sebastian Reichel <sre@kernel.org> writes:
> On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote:
>> We will gain a user from OMAP remoteproc driver as well (out of tree at
>> the moment, but it does follow the DT phandle and
>> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
>> converted to DT, and also some of the API are alive just because of the
>> continued OMAP3 legacy boot support. Guess, it is a just a question of
>> not breaking existing API until we kill some of them.
>
> Right, ir-rx51 has not yet been converted to DT. Additionally it
> depends !ARCH_MULTIPLATFORM, since it requires <plat/dmtimer.h>.
>
> I remember a patchset adding a omap-pwm driver using dmtimers. If
> that was added to the kernel, ir-rx51 could probably be switched to
> the PWM API + hrtimer API instead of depending on the dmtimer API.
> At the end not much is gained, though, since then the PWM driver
> would probably require the dmtimer API.

Tony has been talking about an HRTimer API for some time, but I guess it
didn't happen yet. Until then, cleanups will have to continue to cope
with legacy users.
Tony Lindgren Oct. 6, 2015, 8:08 a.m. UTC | #7
* Felipe Balbi <balbi@ti.com> [151005 18:02]:
> 
> Hi,
> 
> Sebastian Reichel <sre@kernel.org> writes:
> > On Mon, Oct 05, 2015 at 06:41:37PM -0500, Suman Anna wrote:
> >> We will gain a user from OMAP remoteproc driver as well (out of tree at
> >> the moment, but it does follow the DT phandle and
> >> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
> >> converted to DT, and also some of the API are alive just because of the
> >> continued OMAP3 legacy boot support. Guess, it is a just a question of
> >> not breaking existing API until we kill some of them.
> >
> > Right, ir-rx51 has not yet been converted to DT. Additionally it
> > depends !ARCH_MULTIPLATFORM, since it requires <plat/dmtimer.h>.
> >
> > I remember a patchset adding a omap-pwm driver using dmtimers. If
> > that was added to the kernel, ir-rx51 could probably be switched to
> > the PWM API + hrtimer API instead of depending on the dmtimer API.
> > At the end not much is gained, though, since then the PWM driver
> > would probably require the dmtimer API.
> 
> Tony has been talking about an HRTimer API for some time, but I guess it
> didn't happen yet. Until then, cleanups will have to continue to cope
> with legacy users.

Yeh.. Well meanwhile, here's how we can easily support hardware
timers for pwm in a non-intrusive way:

1. We add irqchip support to gptimer code

2. We create omap-gptimer-pwm.c and pass hwtimer_get/set type
   function pointers in pdata to avoid exposing the gptimer
   custom functions to drivers until we have a hwtimer framework

3. Then omap-gptimer-pwm.c does request_irq on the hardware timer(s)
   configured in the board specific dts file to get the right timer

4. Then ir-rx51 can just use he Linux PWM API and omap-gptimer-pwm.c

5. We get rid of the pdata when we have a generic API available

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
Suman Anna Oct. 6, 2015, 5:01 p.m. UTC | #8
Hi Felipe,

>>>>
>>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>>>> We actually want these devices to be created because
>>>>> we will be moving timers to drivers/clocksource and
>>>>> this will prevent them from probing.
>>>>
>>>> This logic is also used to remove the secure timer from being
>>>> registered to the kernel on HS devices, while allowing the timer to be
>>>> available on GP devices. Your patch actually would break that
>>>> functionality. I suggest that you look at the history of the code that
>>>
>>> heh, that's a silly way of doing so. Could just detect if we're running
>>> on HS or not.
>>
>> This function is invoked only after detecting that we are running on a
>> HS device.
> 
> What actually disables the timer is omap_get_timer_dt() and that's
> called in more than one place.

Yes indeed, and this patch is changing the behavior of
omap_get_timer_dt(), so you have to check all call-sites. Also, one
another thing is that this trick was used for DT boots so that the
timers used for clocksource and clockevent are eliminated from the
omap_dm_timer_request() API. The legacy boot used a specific API to mark
those as reserved so that the _request API does not give them out.
Granted that it may not have been the best approach, but that needs a
solution if you change the behavior of this API.

> 
>>>> originally added this logic - this function seems to be designed to
>>>> actually remove the node. The OMAP DMTimer provides an API to request
>>>> timers, and I think this logic was used to eliminate giving out the
>>>> timers used for clocksource and clockevent when the driver got adapted
>>>> to DT.
>>>
>>> again not the best way of achieving what you want. In any case, other
>>> than ir-rx51.c who's using that API ? Seems like we could just pass a
>>> phandle to ir-rx51 and be done with it.
>>
>> We will gain a user from OMAP remoteproc driver as well (out of tree at
>> the moment, but it does follow the DT phandle and
>> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is
>> converted to DT, and also some of the API are alive just because of the
>> continued OMAP3 legacy boot support. Guess, it is a just a question of
>> not breaking existing API until we kill some of them.
> 
> sure, but until remoteproc gets upstream, it's only 1 user ;-)
> 
>>>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>>> ---
>>>>>
>>>>> Tony, I wonder if you can get merged as a fix, or do you
>>>>> prefer receiving it together with my timer series ?
>>>>
>>>> NAK for rc, as it breaks other stuff.
>>>
>>> a single stuff which is likely easy enough to fix. But fair enough
>>
>> Don't think this patch is fixing any critical bug either, better to club
>> it with your cleanup series.
> 
> it is kinda critical when you consider that the timer is disabled
> outside of the soc type detection.

This has been like this since DMTimer is converted to DT (from 3.8
kernel), and is a need for your counter32k clocksource series. The
problem seems to stem from the reuse of omap_get_timer_dt for counter32k
nodes. A better solution would be to remove the omap_get_timer_dt() from
omap2_sync32k_clocksource_init() code and just replace it with
of_find_compatible_node - you seem to be limiting the majority of that
function to legacy mode in Patch 10 of your RFC series anyways.

regards
Suman

--
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 Oct. 6, 2015, 5:14 p.m. UTC | #9
Hi,

Suman Anna <s-anna@ti.com> writes:
>>>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>>>>> We actually want these devices to be created because
>>>>>> we will be moving timers to drivers/clocksource and
>>>>>> this will prevent them from probing.
>>>>>
>>>>> This logic is also used to remove the secure timer from being
>>>>> registered to the kernel on HS devices, while allowing the timer to be
>>>>> available on GP devices. Your patch actually would break that
>>>>> functionality. I suggest that you look at the history of the code that
>>>>
>>>> heh, that's a silly way of doing so. Could just detect if we're running
>>>> on HS or not.
>>>
>>> This function is invoked only after detecting that we are running on a
>>> HS device.
>> 
>> What actually disables the timer is omap_get_timer_dt() and that's
>> called in more than one place.
>
> Yes indeed, and this patch is changing the behavior of
> omap_get_timer_dt(), so you have to check all call-sites. Also, one
> another thing is that this trick was used for DT boots so that the
> timers used for clocksource and clockevent are eliminated from the
> omap_dm_timer_request() API. The legacy boot used a specific API to mark
> those as reserved so that the _request API does not give them out.
> Granted that it may not have been the best approach, but that needs a
> solution if you change the behavior of this API.

no doubt this needs a solution, but seesm like a solution here will have
to be incremental. See new revision of my series. I'm now skipping 32k
only and keeping it enabled so drivers/clocksource/ can use it.

>>>>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>>>> ---
>>>>>>
>>>>>> Tony, I wonder if you can get merged as a fix, or do you
>>>>>> prefer receiving it together with my timer series ?
>>>>>
>>>>> NAK for rc, as it breaks other stuff.
>>>>
>>>> a single stuff which is likely easy enough to fix. But fair enough
>>>
>>> Don't think this patch is fixing any critical bug either, better to club
>>> it with your cleanup series.
>> 
>> it is kinda critical when you consider that the timer is disabled
>> outside of the soc type detection.
>
> This has been like this since DMTimer is converted to DT (from 3.8
> kernel), and is a need for your counter32k clocksource series. The
> problem seems to stem from the reuse of omap_get_timer_dt for counter32k
> nodes. A better solution would be to remove the omap_get_timer_dt() from
> omap2_sync32k_clocksource_init() code and just replace it with
> of_find_compatible_node - you seem to be limiting the majority of that
> function to legacy mode in Patch 10 of your RFC series anyways.

I still need omap_hwmod_enable() to be called, that's why it's still
used. I don't think replacing it with of_find_compatible_node() will buy
us much, we will still need to check for of_device_is_available()
anyway. Sure we skip all the timer flags (alwon, dsp, pwm, secure), but
that really isn't big deal.

When converting gptimer to clocksource, then I'll look at what I can do
for the timer request side of things. For now, things are working,
apparently without regressions (or at least I couldn't catch any so far)
and it seems clean enough that it could possibly be queued for v4.4
merge window. For v4.5 I'll look at this again and try to figure out how
to handle gptimer.
Suman Anna Oct. 6, 2015, 6:13 p.m. UTC | #10
On 10/06/2015 12:14 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Suman Anna <s-anna@ti.com> writes:
>>>>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote:
>>>>>>> We actually want these devices to be created because
>>>>>>> we will be moving timers to drivers/clocksource and
>>>>>>> this will prevent them from probing.
>>>>>>
>>>>>> This logic is also used to remove the secure timer from being
>>>>>> registered to the kernel on HS devices, while allowing the timer to be
>>>>>> available on GP devices. Your patch actually would break that
>>>>>> functionality. I suggest that you look at the history of the code that
>>>>>
>>>>> heh, that's a silly way of doing so. Could just detect if we're running
>>>>> on HS or not.
>>>>
>>>> This function is invoked only after detecting that we are running on a
>>>> HS device.
>>>
>>> What actually disables the timer is omap_get_timer_dt() and that's
>>> called in more than one place.
>>
>> Yes indeed, and this patch is changing the behavior of
>> omap_get_timer_dt(), so you have to check all call-sites. Also, one
>> another thing is that this trick was used for DT boots so that the
>> timers used for clocksource and clockevent are eliminated from the
>> omap_dm_timer_request() API. The legacy boot used a specific API to mark
>> those as reserved so that the _request API does not give them out.
>> Granted that it may not have been the best approach, but that needs a
>> solution if you change the behavior of this API.
> 
> no doubt this needs a solution, but seesm like a solution here will have
> to be incremental. See new revision of my series. I'm now skipping 32k
> only and keeping it enabled so drivers/clocksource/ can use it.

Yeah, have noticed, and it's better for the current problem at hand than
this patch.

> 
>>>>>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Tony, I wonder if you can get merged as a fix, or do you
>>>>>>> prefer receiving it together with my timer series ?
>>>>>>
>>>>>> NAK for rc, as it breaks other stuff.
>>>>>
>>>>> a single stuff which is likely easy enough to fix. But fair enough
>>>>
>>>> Don't think this patch is fixing any critical bug either, better to club
>>>> it with your cleanup series.
>>>
>>> it is kinda critical when you consider that the timer is disabled
>>> outside of the soc type detection.
>>
>> This has been like this since DMTimer is converted to DT (from 3.8
>> kernel), and is a need for your counter32k clocksource series. The
>> problem seems to stem from the reuse of omap_get_timer_dt for counter32k
>> nodes. A better solution would be to remove the omap_get_timer_dt() from
>> omap2_sync32k_clocksource_init() code and just replace it with
>> of_find_compatible_node - you seem to be limiting the majority of that
>> function to legacy mode in Patch 10 of your RFC series anyways.
> 
> I still need omap_hwmod_enable() to be called, that's why it's still
> used. I don't think replacing it with of_find_compatible_node() will buy
> us much, we will still need to check for of_device_is_available()
> anyway. Sure we skip all the timer flags (alwon, dsp, pwm, secure), but
> that really isn't big deal.

Yeah, I would think the counter_32k and the timer code will have to be
decoupled in the future anyway, so it is best to localize the change now
rather than later, so that the omap2_sync32k_clocksource_init() function
can be decoupled cleanly from the timr code. The check for
of_device_is_available may be moot if this device is always needed. But
as long as current timer functionality is unchanged, I am not too
particular about this. If it is always needed, the check for of_device

regards
Suman


> When converting gptimer to clocksource, then I'll look at what I can do
> for the timer request side of things. For now, things are working,
> apparently without regressions (or at least I couldn't catch any so far)
> and it seems clean enough that it could possibly be queued for v4.4
> merge window. For v4.5 I'll look at this again and try to figure out how
> to handle gptimer.


--
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

Patch
diff mbox

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 0ff676273b4b..0c00138d7bd5 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -136,12 +136,6 @@  static struct clock_event_device clockevent_gpt = {
 	.tick_resume		= omap2_gp_timer_shutdown,
 };
 
-static struct property device_disabled = {
-	.name = "status",
-	.length = sizeof("disabled"),
-	.value = "disabled",
-};
-
 static const struct of_device_id omap_timer_match[] __initconst = {
 	{ .compatible = "ti,omap2420-timer", },
 	{ .compatible = "ti,omap3430-timer", },
@@ -161,9 +155,7 @@  static const struct of_device_id omap_timer_match[] __initconst = {
  *
  * 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.
+ * select a timer with a specific property.
  */
 static struct device_node * __init omap_get_timer_dt(const struct of_device_id *match,
 						     const char *property)
@@ -183,7 +175,6 @@  static struct device_node * __init omap_get_timer_dt(const struct of_device_id *
 				  of_get_property(np, "ti,timer-secure", NULL)))
 			continue;
 
-		of_add_property(np, &device_disabled);
 		return np;
 	}