On 06/04/2012 12:22 PM, Jon Hunter wrote:
> In order to migrate the dmtimer driver to support device-tree I found that it
> was first necessary to clean-up the timer platform data. The goal of this
> series is to simplify the timer platform data structure from ...
> 
> struct dmtimer_platform_data {
>       int (*set_timer_src)(struct platform_device *pdev, int source);
>       int timer_ip_version;
>       u32 needs_manual_reset:1;
>       bool reserved;
>       bool loses_context;
>       int (*get_context_loss_count)(struct device *dev);
> };
> 
> to ...
> 
> struct dmtimer_platform_data {
>       int (*set_timer_src)(struct platform_device *pdev, int source);
>       u32 timer_capability;
> };
> 
> ... where timer_capability is a bit mask that indicates the timer features
> supported and uses the HWMOD timer capabilities flags described in
> plat/dmtimer.h. For OMAP2+ devices this allows us to read the timer
> capabilities from the HWMOD data and for OMAP1 devices the flags are simply
> populated by the timer initialisation code. Eventually, the aim is to read the
> timer capabilities from the device tree blob.
> 
> This series includes some fixes as well as clean-up. For instance OMAP1 
> dmtimer
> support is currently completely broken and so I have included a fix for this.
> If it is preferred to split the series into fixes and clean-up I can do that.
> 
> This series is based upon the current linux-omap master branch (3.5-rc1). I 
> have
> built both omap1 and omap2plus configurations as well as booted the respective
> kernels on the omap5912 OSK (omap1), OMAP3430 Beagle and OMAP4460 PANDA.

Forgot to add high-level changes for V2:

V2:
- Fix OMAP1 dmtimer support which currently broken. Requesting a timer
  fails because clk_get() is called and this is not support for OMAP1
  devices.
- Only use "set_timer_src" function pointer for OMAP1 devices.

Testing:
- On the above boards I have tested that I can request a timer and set
  the parent clock.

Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to