All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jon-hunter@ti.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Tarun Kanti DebBarma <tarun.kanti@ti.com>
Subject: Re: [PATCH V2 00/11] ARM: OMAP: DMTIMER clean-up and fixes in preparation for device-tree
Date: Mon, 4 Jun 2012 12:29:38 -0500	[thread overview]
Message-ID: <4FCCF082.7020705@ti.com> (raw)
In-Reply-To: <1338830555-20469-1-git-send-email-jon-hunter@ti.com>


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

      parent reply	other threads:[~2012-06-04 17:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-04 17:22 [PATCH V2 00/11] ARM: OMAP: DMTIMER clean-up and fixes in preparation for device-tree Jon Hunter
2012-06-04 17:22 ` [PATCH V2 01/11] ARM: OMAP: Remove unnecessary clk structure Jon Hunter
2012-06-04 17:22 ` [PATCH V2 02/11] ARM: OMAP2+: Remove unused max number of timers definition Jon Hunter
2012-06-04 17:22 ` [PATCH V2 03/11] ARM: OMAP2+: Add dmtimer platform function to reserve systimers Jon Hunter
2012-06-04 17:22 ` [PATCH V2 04/11] ARM: OMAP: Add DMTIMER capability variable to represent timer features Jon Hunter
2012-06-04 17:22 ` [PATCH V2 05/11] ARM: OMAP2+: HWMOD: Correct timer device attributes Jon Hunter
2012-06-04 17:22 ` [PATCH V2 06/11] ARM: OMAP1: Fix dmtimer support Jon Hunter
2012-06-04 17:22 ` [PATCH V2 07/11] ARM: OMAP2+: Fix external clock support for dmtimers Jon Hunter
2012-06-04 17:22 ` [PATCH V2 08/11] ARM: OMAP: Remove loses_context variable from timer platform data Jon Hunter
2012-06-04 17:22 ` [PATCH V2 09/11] ARM: OMAP: Remove timer function pointer for context loss counter Jon Hunter
2012-06-04 18:49   ` Jon Hunter
2012-06-04 17:22 ` [PATCH V2 10/11] ARM: OMAP2+: Move dmtimer clock set function to dmtimer driver Jon Hunter
2012-06-04 17:22 ` [PATCH V2 11/11] ARM: OMAP2+: Simplify dmtimer clock aliases Jon Hunter
2012-06-04 17:29 ` Jon Hunter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FCCF082.7020705@ti.com \
    --to=jon-hunter@ti.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=tarun.kanti@ti.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.