From: Tony Lindgren <tony@atomide.com> To: Kevin Hilman <khilman@ti.com> Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org Subject: Re: [PATCH 05/10] omap2+: Use dmtimer macros for clockevent Date: Thu, 31 Mar 2011 15:04:26 -0700 [thread overview] Message-ID: <20110331220426.GC21887@atomide.com> (raw) In-Reply-To: <8762qz9dnl.fsf@ti.com> * Kevin Hilman <khilman@ti.com> [110331 14:32]: > Tony Lindgren <tony@atomide.com> writes: > > > This patch makes timer-gp.c to use only a subset of dmtimer > > functions without the need to initialize dmtimer code early. > > > > Note that omap_dmtimer_init_one can eventually be moved to > > omap2+ specific dmtimer.c. > > > > Also note that now with the inline functions, timer_set_next_event > > becomes more efficient in the lines of assembly code. > > > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > In looking closer at this patch, I have a few questions. > > [...] > > > @@ -75,7 +97,8 @@ static struct irqaction omap2_gp_timer_irq = { > > static int omap2_gp_timer_set_next_event(unsigned long cycles, > > struct clock_event_device *evt) > > { > > - omap_dm_timer_set_load_start(gptimer, 0, 0xffffffff - cycles); > > + __omap_dm_timer_load_start(clkev.io_base, OMAP_TIMER_CTRL_ST, > > + 0xffffffff - cycles, 1); > > > > return 0; > > The creation of macros is causing some readability concern, at least for > me... > > In creating the macro versions of some of the functions, the macro > version actually has different behavior which makes reading the code a > little confusing. > > I just noticed that the macro version of _load_start() doesn't actually > do the "start", so you added the OMAP_TIMER_CTRL_ST when calling it. > To do this, the macro version takes a 'ctrl' argument where as the > "real" version only takes the autoreload argument. > > If you're going to keep the same function name (but just add the __ > prefix, I would expect that the functionality of the function doesn't > change. > > If the functionality of the macro is different from the "real" function, > it should probably just be given a different name. In this case, > probably dropping the _start suffix is probably enough. OK good point. > > } > > @@ -85,13 +108,13 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode, > > { > > u32 period; > > > > - omap_dm_timer_stop(gptimer); > > + omap_dm_timer_stop(&clkev); > > > > switch (mode) { > > case CLOCK_EVT_MODE_PERIODIC: > > - period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ; > > + period = clkev.rate / HZ; > > period -= 1; > > - omap_dm_timer_set_load_start(gptimer, 1, 0xffffffff - period); > > + omap_dm_timer_set_load_start(&clkev, 1, 0xffffffff - period); > > Hmm, you're using the driver function here not the macro. Is that > intended? > > Why not use the macro version here with OMAP_TIMER_CTRL_AR | > OMAP_TIMER_CTRL_ST. Hmm I guess I tried to change as little as possible here when I noticed that there's some weirdness with the autoreload mode in the original omap_dm_timer_set_load_start function that requires writing twice in the autoreload case. Looks like that's not needed for the one-shot case. Anyways, you're right, this should not be using the driver function to move the rest of the timers to be under drivers/ eventually. Will post an updated version after taking another look at the dmtimer hwmod series. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 05/10] omap2+: Use dmtimer macros for clockevent Date: Thu, 31 Mar 2011 15:04:26 -0700 [thread overview] Message-ID: <20110331220426.GC21887@atomide.com> (raw) In-Reply-To: <8762qz9dnl.fsf@ti.com> * Kevin Hilman <khilman@ti.com> [110331 14:32]: > Tony Lindgren <tony@atomide.com> writes: > > > This patch makes timer-gp.c to use only a subset of dmtimer > > functions without the need to initialize dmtimer code early. > > > > Note that omap_dmtimer_init_one can eventually be moved to > > omap2+ specific dmtimer.c. > > > > Also note that now with the inline functions, timer_set_next_event > > becomes more efficient in the lines of assembly code. > > > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > In looking closer at this patch, I have a few questions. > > [...] > > > @@ -75,7 +97,8 @@ static struct irqaction omap2_gp_timer_irq = { > > static int omap2_gp_timer_set_next_event(unsigned long cycles, > > struct clock_event_device *evt) > > { > > - omap_dm_timer_set_load_start(gptimer, 0, 0xffffffff - cycles); > > + __omap_dm_timer_load_start(clkev.io_base, OMAP_TIMER_CTRL_ST, > > + 0xffffffff - cycles, 1); > > > > return 0; > > The creation of macros is causing some readability concern, at least for > me... > > In creating the macro versions of some of the functions, the macro > version actually has different behavior which makes reading the code a > little confusing. > > I just noticed that the macro version of _load_start() doesn't actually > do the "start", so you added the OMAP_TIMER_CTRL_ST when calling it. > To do this, the macro version takes a 'ctrl' argument where as the > "real" version only takes the autoreload argument. > > If you're going to keep the same function name (but just add the __ > prefix, I would expect that the functionality of the function doesn't > change. > > If the functionality of the macro is different from the "real" function, > it should probably just be given a different name. In this case, > probably dropping the _start suffix is probably enough. OK good point. > > } > > @@ -85,13 +108,13 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode, > > { > > u32 period; > > > > - omap_dm_timer_stop(gptimer); > > + omap_dm_timer_stop(&clkev); > > > > switch (mode) { > > case CLOCK_EVT_MODE_PERIODIC: > > - period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ; > > + period = clkev.rate / HZ; > > period -= 1; > > - omap_dm_timer_set_load_start(gptimer, 1, 0xffffffff - period); > > + omap_dm_timer_set_load_start(&clkev, 1, 0xffffffff - period); > > Hmm, you're using the driver function here not the macro. Is that > intended? > > Why not use the macro version here with OMAP_TIMER_CTRL_AR | > OMAP_TIMER_CTRL_ST. Hmm I guess I tried to change as little as possible here when I noticed that there's some weirdness with the autoreload mode in the original omap_dm_timer_set_load_start function that requires writing twice in the autoreload case. Looks like that's not needed for the one-shot case. Anyways, you're right, this should not be using the driver function to move the rest of the timers to be under drivers/ eventually. Will post an updated version after taking another look at the dmtimer hwmod series. Regards, Tony
next prev parent reply other threads:[~2011-03-31 22:04 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-28 22:21 [PATCH 00/10] omap init_early changes for irq and timer init Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 01/10] omap: Use separate init_irq functions to avoid cpu_is_omap tests early Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 6:11 ` [PATCH 01/10] omap: Use separate init_irq functions to avoidcpu_is_omap " Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 15:30 ` Tony Lindgren 2011-03-29 15:30 ` Tony Lindgren 2011-03-29 22:27 ` Tony Lindgren 2011-03-29 22:27 ` Tony Lindgren 2011-03-29 17:11 ` [PATCH 01/10] omap: Use separate init_irq functions to avoid cpu_is_omap " Kevin Hilman 2011-03-29 17:11 ` Kevin Hilman 2011-03-29 17:14 ` Tony Lindgren 2011-03-29 17:14 ` Tony Lindgren 2011-05-17 11:28 ` Tony Lindgren 2011-05-17 11:28 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 02/10] omap: Set separate timer init functions to avoid cpu_is_omap tests Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 03/10] omap: Move dmtimer defines to dmtimer.h Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 17:41 ` Kevin Hilman 2011-03-29 17:41 ` Kevin Hilman 2011-03-29 17:44 ` Tony Lindgren 2011-03-29 17:44 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 04/10] omap: Make a subset of dmtimer functions into inline functions Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 17:51 ` Kevin Hilman 2011-03-29 17:51 ` Kevin Hilman 2011-03-29 17:58 ` Tony Lindgren 2011-03-29 17:58 ` Tony Lindgren 2011-03-29 18:01 ` Kevin Hilman 2011-03-29 18:01 ` Kevin Hilman 2011-03-29 18:02 ` Tony Lindgren 2011-03-29 18:02 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 05/10] omap2+: Use dmtimer macros for clockevent Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 17:16 ` Tony Lindgren 2011-03-29 17:16 ` Tony Lindgren 2011-03-31 21:35 ` Kevin Hilman 2011-03-31 21:35 ` Kevin Hilman 2011-03-31 22:04 ` Tony Lindgren [this message] 2011-03-31 22:04 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 06/10] omap2+: Remove gptimer_wakekup for now Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-31 22:09 ` Kevin Hilman 2011-03-31 22:09 ` Kevin Hilman 2011-04-01 16:26 ` Santosh Shilimkar 2011-04-01 16:26 ` Santosh Shilimkar 2011-03-28 22:21 ` [PATCH 07/10] omap2+: Reserve clocksource and timesource and initialize dmtimer later Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 08/10] omap2+: Use dmtimer macros for clocksource Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 09/10] omap2+: Remove omap2_gp_clockevent_set_gptimer Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 10/10] omap2+: Rename timer-gp.c into timer.c to combine timer init functions Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 18:16 ` [PATCH 00/10] omap init_early changes for irq and timer init Kevin Hilman 2011-03-29 18:16 ` Kevin Hilman 2011-03-30 7:56 ` Santosh Shilimkar 2011-03-30 7:56 ` Santosh Shilimkar 2011-03-30 18:22 ` Tony Lindgren 2011-03-30 18:22 ` Tony Lindgren 2011-03-31 8:16 ` Santosh Shilimkar 2011-03-31 8:16 ` Santosh Shilimkar 2011-03-31 17:32 ` Tony Lindgren 2011-03-31 17:32 ` Tony Lindgren 2011-04-01 8:39 ` Santosh Shilimkar 2011-04-01 8:39 ` Santosh Shilimkar 2011-06-20 9:23 [PATCH 00/10] init_early cleanup for omap init_irq and init_timer Tony Lindgren 2011-06-20 9:23 ` [PATCH 05/10] omap2+: Use dmtimer macros for clockevent Tony Lindgren 2011-06-20 9:23 ` Tony Lindgren 2011-06-23 17:07 ` Kevin Hilman 2011-06-23 17:07 ` Kevin Hilman 2011-06-27 7:39 ` Tony Lindgren 2011-06-27 7:39 ` Tony Lindgren
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=20110331220426.GC21887@atomide.com \ --to=tony@atomide.com \ --cc=khilman@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ /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: linkBe 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.