ARM: OMAP2+: Add device-tree support for timers

For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER) power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck" as its functional clock the actual clock used is different depending on whether the clock is in the Wake-up, ABE or PER domain. So when we look-up the dmtimer's "timer_sys_ck" we need to specify the timer device name as well as clock alias to find the right clock.

Currently, the device names for the timers have the format "omap_timer.X" where X is the timer instance number. When using to device tree, the format of the device name created by device-tree is different and has the format "<reg-address>.<device-name>" (this is assuming that the device-tree "reg" property is specified). This causes the look-up for the OMAP4 "timer_sys_ck" to fail. To fix this add new timer clock alias for using device-tree.

Please note that adding a 2nd set of clock aliases for the same clocks to only temporary until device-tree migration is complete. Then we can remove the legacy aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.

Signed-off-by Jon Hunter <[email protected]>

Some instances of the DMTIMER peripheral on OMAP devices have the ability to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER attribute to indicate which timers can interrupt the DSP. By using the omap_dm_timer_request_by_cap() API, driver will now be able to allocate a DMTIMER that can interrupt the DSP based upon this attribute and not require the driver to know which instance has this capability.

DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as follows ...

- OMAP1 (OMAP5912/16xx/17xx) devices - All 8 DMTIMERs
- OMAP2/3/4 devices - DMTIMERs 5-8

Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and generate a PWM output.

Signed-off-by Jon Hunter <[email protected]>

In order to add device-tree support to the timer driver the following changes were made ...

1. Allocate system timers (used for clock-events and clock-source) based upon timer properties rather than using an hard-coded timer instance ID. To allow this a new helper function called omap_dmtimer_find_by_property() has been added for finding a timer with the particular properties in the device-tree blob. Please note that this is an internal helper function for system timers only to find a timer in the device-tree blob. This cannot be used by device drivers, another API has been added for that (see below). Timers that are allocated for system timers are dynamically disabled at boot time by adding a status property with the value "disabled" to the timer's device-tree node.

Please note that when allocating system timers we now pass a timer ID and timer property. The timer ID is only be used for allocating a timer when booting without device-tree. Once device-tree migration is complete, all the timer ID references will be removed.

2. If DT blob is present, then let device-tree create the timer devices dynamically.

3. When device-tree is present the "id" field in the platform_device structure (pdev->id) is initialised to -1 and hence cannot be used to identify a timer instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer. This function will return an error if called when device-tree is present. Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device name instead of the "id".

4. When device-tree is present the platform_data structure will be NULL and so check for this.

5. The OMAP timer device tree binding has the following optional parameters ...

   a). ti,timer-alwon  --> Timer is in an always-on power domain
   b). ti,timer-dsp    --> Timer can generate an interrupt to the on-chip DSP
   c). ti,timer-pwm    --> Timer can generate a PWM output

d). ti,timer-secure --> Timer is reserved on a secure OMAP device Search for the above parameters and set the appropriate timer attribute flags.

Signed-off-by Jon Hunter <[email protected]>

---

 arch/arm/mach-omap2/timer.c  |   96 +++++++++++++++++++++++++++++++++---------
 arch/arm/plat-omap/dmtimer.c |   41 +++++++++++++++---
 2 files changed, 112 insertions(+), 25 deletions(-)

arch/arm/mach-omap2/timer.c +0 -0

index 60d43c8..d1c7771 100644

arch/arm/mach-omap2/timer.c +2 -0

 #ifdef CONFIG_OMAP_32K_TIMER
 #define OMAP2_CLKEV_SOURCE	OMAP2_32K_SOURCE
 #define OMAP3_CLKEV_SOURCE	OMAP3_32K_SOURCE
 #define OMAP4_CLKEV_SOURCE	OMAP4_32K_SOURCE
 #define OMAP3_SECURE_TIMER	12
+#define TIMER_PROP_SECURE	"ti,timer-secure"
 #else
 #define OMAP2_CLKEV_SOURCE	OMAP2_MPU_SOURCE
 #define OMAP3_CLKEV_SOURCE	OMAP3_MPU_SOURCE
 #define OMAP4_CLKEV_SOURCE	OMAP4_MPU_SOURCE
 #define OMAP3_SECURE_TIMER	1
+#define TIMER_PROP_SECURE	TIMER_PROP_ALWON
 #endif
 

In order to add device-tree support to the timer driver the following changes were made ...

1. Allocate system timers (used for clock-events and clock-source) based upon timer properties rather than using an hard-coded timer instance ID. To allow this a new helper function called omap_dmtimer_find_by_property() has been added for finding a timer with the particular properties in the device-tree blob. Please note that this is an internal helper function for system timers only to find a timer in the device-tree blob. This cannot be used by device drivers, another API has been added for that (see below). Timers that are allocated for system timers are dynamically disabled at boot time by adding a status property with the value "disabled" to the timer's device-tree node.

Please note that when allocating system timers we now pass a timer ID and timer property. The timer ID is only be used for allocating a timer when booting without device-tree. Once device-tree migration is complete, all the timer ID references will be removed.

2. If DT blob is present, then let device-tree create the timer devices dynamically.

3. When device-tree is present the "id" field in the platform_device structure (pdev->id) is initialised to -1 and hence cannot be used to identify a timer instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer. This function will return an error if called when device-tree is present. Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device name instead of the "id".

4. When device-tree is present the platform_data structure will be NULL and so check for this.

5. The OMAP timer device tree binding has the following optional parameters ...

   a). ti,timer-alwon  --> Timer is in an always-on power domain
   b). ti,timer-dsp    --> Timer can generate an interrupt to the on-chip DSP
   c). ti,timer-pwm    --> Timer can generate a PWM output

d). ti,timer-secure --> Timer is reserved on a secure OMAP device Search for the above parameters and set the appropriate timer attribute flags.

Signed-off-by Jon Hunter <[email protected]>

---
 arch/arm/mach-omap2/timer.c  |   96 +++++++++++++++++++++++++++++++++---------
 arch/arm/plat-omap/dmtimer.c |   41 +++++++++++++++---
 2 files changed, 112 insertions(+), 25 deletions(-)

arch/arm/mach-omap2/timer.c +0 -0

index 60d43c8..d1c7771 100644

Hi Rob,

arch/arm/mach-omap2/timer.c line 62

Quoted 5 lines

#define OMAP3_32K_SOURCE "omap_32k_fck"
#define OMAP4_32K_SOURCE "sys_32k_ck"

arch/arm/mach-omap2/timer.c +2 -0

+#define TIMER_PROP_ALWON	"ti,timer-alwon"
+

I see you made the following comment [1] here ...

"It would be easier to follow the code if you use the strings directly (and you do in some places)."

I could avoid the above definition.

arch/arm/mach-omap2/timer.c line 75

Quoted 13 lines

#ifdef CONFIG_OMAP_32K_TIMER
#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
#define OMAP3_SECURE_TIMER 12

arch/arm/mach-omap2/timer.c +2 -0

+#define TIMER_PROP_SECURE	"ti,timer-secure"
 #else
 #define OMAP2_CLKEV_SOURCE	OMAP2_MPU_SOURCE
 #define OMAP3_CLKEV_SOURCE	OMAP3_MPU_SOURCE
 #define OMAP4_CLKEV_SOURCE	OMAP4_MPU_SOURCE
 #define OMAP3_SECURE_TIMER	1
+#define TIMER_PROP_SECURE	TIMER_PROP_ALWON
 #endif

Are you ok, with having the TIMER_PROP_SECURE definition or would you prefer I handle this differently? This is dependent on the kernel config.\

Cheers
Jon

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/84458/focus=84982

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

This series adds device-tree support for the timers on OMAP2+ devices including AM33xx.

This series adds device-tree support for the timers on OMAP2+ devices including AM33xx.

Testing:
1. I have booted linux with this series on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda with/without device-tree present.
2. Vaibhav has booted linux on AM335x Beagle bone (thanks!)
3. I have tested the all the timers (not used by the kernel as sys-timers) on OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda with/without device-tree with this series. The testing includes ...
a. Configuring, starting a timer and checking the counter value is
incrementing.
b. Testing timer overflow interrupt when timer expires.
c. Using different clock sources to operate the timer with.
4. Verified on OMAP4430 and AM33xx (Vaibhav) that the kernel boots when using a GP timer as clock-source (default for OMAP is 32k-sync timer). Thanks to Vaibhav for catching and tracking down a bug when using a GP-timer as the clock-source!

V2 changes:
- Remove use of device-tree alias property
- Migrate OMAP timers to request timers by property instead of device ID
- Include OMAP2 support

Jon Hunter (7):
ARM: dts: OMAP: Add timer nodes
ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
ARM: OMAP4: Add timer clock aliases for device-tree
ARM: OMAP: Add a timer attribute for timers that can interrupt the
DSP
ARM: OMAP: Add function to request a timer by capability
ARM: OMAP3: Add generic machine descriptor for boards with OMAP3 GP
devices
ARM: OMAP: Add DT support for timer driver

 .../devicetree/bindings/arm/omap/timer.txt         |   30 +++++
 arch/arm/boot/dts/am33xx.dtsi                      |   61 +++++++++
 arch/arm/boot/dts/omap2.dtsi                       |   86 +++++++++++++
 arch/arm/boot/dts/omap2420.dtsi                    |    8 ++
 arch/arm/boot/dts/omap2430.dtsi                    |    8 ++
 arch/arm/boot/dts/omap3.dtsi                       |   96 ++++++++++++++
 arch/arm/boot/dts/omap4.dtsi                       |   86 +++++++++++++
 arch/arm/mach-omap1/timer.c                        |    2 +-
 arch/arm/mach-omap2/board-generic.c                |   18 +++
 arch/arm/mach-omap2/clock44xx_data.c               |   12 ++
 arch/arm/mach-omap2/common.h                       |    1 +
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    9 ++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |   15 ++-
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |   15 ++-
 arch/arm/mach-omap2/timer.c                        |  131 +++++++++++++++++---
 arch/arm/plat-omap/dmtimer.c                       |   94 +++++++++++++-
 arch/arm/plat-omap/include/plat/dmtimer.h          |    2 +
 17 files changed, 646 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt

Hi Tony,

I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7.

Quoted 4 lines · Benoit Cousson

Hi Tony,

I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7.

I suggest that you do a separate branch on top of Paul's hwmod series when he posts those if that works for you?

Quoted 6 lines · Tony Lindgren

Quoted 4 lines · Benoit Cousson

Hi Tony,

I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7.

Quoted 2 lines

I suggest that you do a separate branch on top of Paul's hwmod series when he posts those if that works for you?

Benoit, I see that you have pulled in the DTS patch.

Do you guys want me to rebase the remaining patches with Rob's change on Tony's master branch and re-submit?

Cheers
Jon

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss at lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Quoted 8 lines · Jon Hunter

Quoted 6 lines · Tony Lindgren

Quoted 4 lines · Benoit Cousson

Hi Tony,

I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7.

Quoted 8 lines

Quoted 2 lines

I suggest that you do a separate branch on top of Paul's hwmod series when he posts those if that works for you?

Benoit, I see that you have pulled in the DTS patch.

Do you guys want me to rebase the remaining patches with Rob's change on Tony's master branch and re-submit?

Jon,

Sorry for delayed response, But I tried using your omap_test application to validate this patch series, but it is failing for me.

How did you test it? Are you running same test application at your end?

I am debugging this issue, i just thought I should tell you this before its too late.

Below is the log -

[root at arago /]# echo 3 > /tmp/omap-test/timer/one

[   79.612223] omap_dm_timer_request_specific: Please use
omap_dm_timer_request_by_cap()
[   79.620636] Timer 3 not available!

Quoted 8 lines · Jon Hunter

Quoted 6 lines · Tony Lindgren

Quoted 4 lines · Benoit Cousson

Hi Tony,

I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7.

Quoted 8 lines

Quoted 2 lines

I suggest that you do a separate branch on top of Paul's hwmod series when he posts those if that works for you?

Benoit, I see that you have pulled in the DTS patch.

Do you guys want me to rebase the remaining patches with Rob's change on Tony's master branch and re-submit?

Jon,

Sorry for delayed response, But I tried using your omap_test application to validate this patch series, but it is failing for me.

How did you test it? Are you running same test application at your end?

I am debugging this issue, i just thought I should tell you this before its too late.

Below is the log -

[root at arago /]# echo 3 > /tmp/omap-test/timer/one

[   79.612223] omap_dm_timer_request_specific: Please use
omap_dm_timer_request_by_cap()
[   79.620636] Timer 3 not available!

[root at arago /]#
[root at arago /]# echo 3 > /tmp/omap-test/timer/all

[  135.111949] Testing 48042000.timer with 24000000 Hz clock ...
[root at arago /]# [  137.457389] Timer read test PASSED! No errors, 100 loops
[  137.463267] Timer interrupt test PASSED!
[  137.467650] Testing 48042000.timer with 32768 Hz clock ...
[  139.816892] Timer read test PASSED! No errors, 100 loops
[  139.830776] Timer interrupt test PASSED!
[  139.835245] Testing 48044000.timer with 24000000 Hz clock ...
[  142.183912] Timer read test PASSED! No errors, 100 loops
[  142.189734] Timer interrupt test PASSED!
[  142.194076] Testing 48044000.timer with 32768 Hz clock ...
[  144.543451] Timer read test PASSED! No errors, 100 loops
[  144.557334] Timer interrupt test PASSED!
[  144.561806] Testing 48046000.timer with 24000000 Hz clock ...
[  146.910469] Timer read test PASSED! No errors, 100 loops
[  147.910493] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  147.917598] Testing 48046000.timer with 32768 Hz clock ...
[  150.262203] Timer read test PASSED! No errors, 100 loops
[  151.262049] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  151.269298] Testing 48048000.timer with 24000000 Hz clock ...
[  153.613596] Timer read test PASSED! No errors, 100 loops
[  154.613618] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  154.620725] Testing 48048000.timer with 32768 Hz clock ...
[  156.965324] Timer read test PASSED! No errors, 100 loops
[  157.965176] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  157.972419] Testing 4804a000.timer with 24000000 Hz clock ...

[root at arago /]# [ 160.316753] Timer read test PASSED! No errors, 100 loops

[root at arago /]# [ 161.316728] Timer interrupt test FAILED! No interrupt occurred in 1 sec

[  161.323912] Testing 4804a000.timer with 32768 Hz clock ...

[root at arago /]# [ 163.668490] Timer read test PASSED! No errors, 100 loops

[  164.668328] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  164.675545] Tested 5 timers, skipped 6 timers and detected 6 errors
[  164.682202] Test iteration 0 complete in 29 secs
[  164.687104] Test summary: Iterations 1, Errors 6

Quoted 22 lines · Vaibhav Hiremath

Quoted 8 lines · Jon Hunter

Quoted 6 lines · Tony Lindgren

Quoted 4 lines · Benoit Cousson

Hi Tony,

I was about to take the DTS patch, but was wondering if you will pull the driver changes for 3.7.

Quoted 8 lines

Quoted 2 lines

I suggest that you do a separate branch on top of Paul's hwmod series when he posts those if that works for you?

Benoit, I see that you have pulled in the DTS patch.

Do you guys want me to rebase the remaining patches with Rob's change on Tony's master branch and re-submit?

Jon,

Quoted 4 lines

Sorry for delayed response, But I tried using your omap_test application to validate this patch series, but it is failing for me.

How did you test it? Are you running same test application at your end?

Sorry, I now see you are using the latest test code! I was too hasty when I saw the first error ;-)

Quoted 2 lines

I am debugging this issue, i just thought I should tell you this before its too late.

Thanks.

Quoted 6 lines

Below is the log -

[root at arago /]# echo 3 > /tmp/omap-test/timer/one

[   79.612223] omap_dm_timer_request_specific: Please use
omap_dm_timer_request_by_cap()
[   79.620636] Timer 3 not available!

This is expected because omap_dm_timer_request_specific() is no longer supported. I should remove in the omap-test/timer/one going forward.

Quoted 32 lines

[root at arago /]#
[root at arago /]# echo 3 > /tmp/omap-test/timer/all

[  135.111949] Testing 48042000.timer with 24000000 Hz clock ...
[root at arago /]# [  137.457389] Timer read test PASSED! No errors, 100 loops
[  137.463267] Timer interrupt test PASSED!
[  137.467650] Testing 48042000.timer with 32768 Hz clock ...
[  139.816892] Timer read test PASSED! No errors, 100 loops
[  139.830776] Timer interrupt test PASSED!
[  139.835245] Testing 48044000.timer with 24000000 Hz clock ...
[  142.183912] Timer read test PASSED! No errors, 100 loops
[  142.189734] Timer interrupt test PASSED!
[  142.194076] Testing 48044000.timer with 32768 Hz clock ...
[  144.543451] Timer read test PASSED! No errors, 100 loops
[  144.557334] Timer interrupt test PASSED!
[  144.561806] Testing 48046000.timer with 24000000 Hz clock ...
[  146.910469] Timer read test PASSED! No errors, 100 loops
[  147.910493] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  147.917598] Testing 48046000.timer with 32768 Hz clock ...
[  150.262203] Timer read test PASSED! No errors, 100 loops
[  151.262049] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  151.269298] Testing 48048000.timer with 24000000 Hz clock ...
[  153.613596] Timer read test PASSED! No errors, 100 loops
[  154.613618] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  154.620725] Testing 48048000.timer with 32768 Hz clock ...
[  156.965324] Timer read test PASSED! No errors, 100 loops
[  157.965176] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  157.972419] Testing 4804a000.timer with 24000000 Hz clock ...

[root at arago /]# [ 160.316753] Timer read test PASSED! No errors, 100 loops

[root at arago /]# [ 161.316728] Timer interrupt test FAILED! No interrupt occurred in 1 sec

Quoted 7 lines

[  161.323912] Testing 4804a000.timer with 32768 Hz clock ...

[root at arago /]# [ 163.668490] Timer read test PASSED! No errors, 100 loops

[  164.668328] Timer interrupt test FAILED! No interrupt occurred in 1 sec
[  164.675545] Tested 5 timers, skipped 6 timers and detected 6 errors
[  164.682202] Test iteration 0 complete in 29 secs
[  164.687104] Test summary: Iterations 1, Errors 6

What is interesting is that it is the interrupt test that is failing for timers 5-7. Any chance there is a problem with the interrupt mapping? I checked the documentation for AM335x and I don't see anything obvious that is wrong with the binding unless the documentation itself is wrong.

Given that the interrupts work on timers 3 and 4 it appears to be a interrupt configuration problem somewhere. We could adapt the test to see if an interrupt is pending in the timer peripheral when it fails. This would tell us that the timer is working but the interrupt is not being enabled correctly in the interrupt controller.

Cheers
Jon

What is interesting is that it is the interrupt test that is failing for timers 5-7. Any chance there is a problem with the interrupt mapping? I checked the documentation for AM335x and I don't see anything obvious that is wrong with the binding unless the documentation itself is wrong.

Jon,

Sorry for delayed response, But I tried using your omap_test application to validate this patch series, but it is failing for me.

How did you test it? Are you running same test application at your end?

I am debugging this issue, i just thought I should tell you this before its too late.