[PATCH V2 7/7] ARM: OMAP: Add DT support for timer driver
Jon Hunter
jon-hunter at ti.com
Thu Sep 27 01:51:51 EST 2012
Hi Rob,
On 09/13/2012 06:31 PM, Jon Hunter wrote:
> 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 <jon-hunter at ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 96 +++++++++++++++++++++++++++++++++---------
> arch/arm/plat-omap/dmtimer.c | 41 +++++++++++++++---
> 2 files changed, 112 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 60d43c8..d1c7771 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -58,16 +58,20 @@
> #define OMAP3_32K_SOURCE "omap_32k_fck"
> #define OMAP4_32K_SOURCE "sys_32k_ck"
>
> +#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.
> #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
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
More information about the devicetree-discuss
mailing list