Subject: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

From: [email-masked] (Grygorii Strashko)
Date: Wed, 18 Nov 2015 17:35:43 +0200

Hi Mark,

On 11/18/2015 04:15 PM, Mark Rutland wrote:
> On Wed, Nov 18, 2015 at 04:01:55PM +0200, Grygorii Strashko wrote:
>> Keep ARM TWD and Global timer's nodes disabled by default - if someone
>> would like to use them then those nodes have to be enabled explicitly
>> in board file.
>>
>> The reason for this change is:
>> - ARM TWD is not always-on timer on am437x and it will stop in low
>>    CPUIdle states and, therefore, broadcast timer has to configured
>>    properly if CPU_IDLE=y.
>> - ARM Global timer is not always-on timer on am437x and it can't be
>>    used as clocksource device if CPU_IDLE=y.
> 
> I don't understand. What timer do you use in the absence of a TWD, and
> if it is better why is it not used even if TWD is present?

OMAP GP timer as clockevent device
"ti,omap-counter32k" as clocksource
both are in wakeup (always-on) PM domain.

I see some problems with selecting clocksource/event device (but may be I'm mistaken):
- Current clock event will be selected using "rating" field in clock_event_device
  structure and now ARM TWD has higer value (350) vs OMAP GP timer (300),
  so ARM TWD will be always selected if it's present. 
- we have to force all am437x user to use kernel cmdline parameter "clocksource="
  if ARM Global timer is present, but shouldn't be used. But even in this case,
  it will be selected as sched_clock.

We can see benefits from using these timers when Power mangement is not the case,
for example on -RT kernel where CPUIdle is not the target.

By this change, and taking into account discovered issues, I want to make people,
who would like to use these timers on AM437x based boards, responsible for such
decision with assumption that they know what they are doing.
And this is simplest way I found to disable those timers without modifying kernel.

> 
>> - ARM Global timer driver doesn't support CPUfreq now.
> 
> Surely that should be fixed in the driver (e.g. make it fail to probe if
> CPUfreq is present)? It's broken for any other users too...

May be.

Also, there is additional issue with ARM global timer which I've not
mentioned here, because I sent the fix for it already (in progress):
https://lkml.org/lkml/2015/11/13/456

and there is ongoing discussion:
http://www.spinics.net/lists/arm-kernel/msg459649.html

-- 
regards,
-grygorii