| Message ID | 1346871872-24413-9-git-send-email-jon-hunter@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Jon Hunter <jon-hunter@ti.com> [120905 12:05]: > The dmtimer functions to read and write the dmtimer registers are currently > defined as follows ... > > static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, > int posted); > static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, > u32 reg, u32 val, int posted); > > The posted variable indicates if the timer is configured to use the posted mode > when performing register accesses. The posted mode configuration of the dmtimer > is stored in the omap_dm_timer structure that is also being passed to the above > functions and therefore we do not need to pass the posted variable separately. > Therefore, simplify the above functions by removing the posted variable as an > argument as this is not necessary. I believe the reason for passing the posted flag was to optimize out some functions from the timer code as that's being run all the time. Care to check the assembly before and after this patch for the timer functions with objdump -d to make sure it does not add tons of bloat there? Thanks, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/07/2012 05:22 PM, Tony Lindgren wrote: > * Jon Hunter <jon-hunter@ti.com> [120905 12:05]: >> The dmtimer functions to read and write the dmtimer registers are currently >> defined as follows ... >> >> static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, >> int posted); >> static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, >> u32 reg, u32 val, int posted); >> >> The posted variable indicates if the timer is configured to use the posted mode >> when performing register accesses. The posted mode configuration of the dmtimer >> is stored in the omap_dm_timer structure that is also being passed to the above >> functions and therefore we do not need to pass the posted variable separately. >> Therefore, simplify the above functions by removing the posted variable as an >> argument as this is not necessary. > > I believe the reason for passing the posted flag was to optimize out some > functions from the timer code as that's being run all the time. > > Care to check the assembly before and after this patch for the timer > functions with objdump -d to make sure it does not add tons of bloat > there? Hi Tony, Thanks for the details here. I see that makes sense and that the compiler could take advantage of this as the functions are inlined. I have taken a look at the disassembled output using objdump as you mentioned. What I see is ... 1. For dmtimer.c the impact appears negligible, the total number of lines outputted by objdump only changed by 8 with (1215 lines) and without (1207 lines) the patch applied. 2. For timer.c the impact is greater. I see that omap2_gp_timer_set_next_event() increased by 6 instructions from 29 to 35. clocksource_read_cycles() increased by 2 instructions 15 to 17 instructions. dmtimer_read_sched_clock() increased by 2 instructions from 17 to 19. omap2_gp_timer_set_mode() increased by 21 instructions from 102 to 123. I imagine that we are mainly concerned about omap2_gp_timer_set_next_event(), clocksource_read_cycles() and dmtimer_read_sched_clock() as these will be called often. Therefore, I am not sure if you wish to drop this patch. By the way, if we do drop this patch, I would then need to fix the setting of the posted variable in mach-omap2/timer.c for clock-source in the case where a dmtimer is used. Today the code assumes that for clock-source and clock-events posted mode is always used. However, with the errata i103/i767 we will disable posted mode for clock-source on omap2/3/4/5/am33xx devices. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Jon Hunter <jon-hunter@ti.com> [120910 15:00]: > > On 09/07/2012 05:22 PM, Tony Lindgren wrote: > > * Jon Hunter <jon-hunter@ti.com> [120905 12:05]: > >> The dmtimer functions to read and write the dmtimer registers are currently > >> defined as follows ... > >> > >> static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, > >> int posted); > >> static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, > >> u32 reg, u32 val, int posted); > >> > >> The posted variable indicates if the timer is configured to use the posted mode > >> when performing register accesses. The posted mode configuration of the dmtimer > >> is stored in the omap_dm_timer structure that is also being passed to the above > >> functions and therefore we do not need to pass the posted variable separately. > >> Therefore, simplify the above functions by removing the posted variable as an > >> argument as this is not necessary. > > > > I believe the reason for passing the posted flag was to optimize out some > > functions from the timer code as that's being run all the time. > > > > Care to check the assembly before and after this patch for the timer > > functions with objdump -d to make sure it does not add tons of bloat > > there? > > Hi Tony, > > Thanks for the details here. I see that makes sense and that the > compiler could take advantage of this as the functions are inlined. > > I have taken a look at the disassembled output using objdump as you > mentioned. What I see is ... > > 1. For dmtimer.c the impact appears negligible, the total number of > lines outputted by objdump only changed by 8 with (1215 lines) and > without (1207 lines) the patch applied. > > 2. For timer.c the impact is greater. I see that > omap2_gp_timer_set_next_event() increased by 6 instructions from 29 > to 35. clocksource_read_cycles() increased by 2 instructions 15 to > 17 instructions. dmtimer_read_sched_clock() increased by 2 > instructions from 17 to 19. omap2_gp_timer_set_mode() increased by > 21 instructions from 102 to 123. > > I imagine that we are mainly concerned about > omap2_gp_timer_set_next_event(), clocksource_read_cycles() and > dmtimer_read_sched_clock() as these will be called often. Therefore, I > am not sure if you wish to drop this patch. Well does it at lots of new ldr to the critical code? > By the way, if we do drop this patch, I would then need to fix the > setting of the posted variable in mach-omap2/timer.c for clock-source in > the case where a dmtimer is used. Today the code assumes that for > clock-source and clock-events posted mode is always used. However, with > the errata i103/i767 we will disable posted mode for clock-source on > omap2/3/4/5/am33xx devices. Yes I see, I guess that means just adding a new systimer entry? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/10/2012 07:58 PM, Tony Lindgren wrote: > * Jon Hunter <jon-hunter@ti.com> [120910 15:00]: >> >> On 09/07/2012 05:22 PM, Tony Lindgren wrote: >>> * Jon Hunter <jon-hunter@ti.com> [120905 12:05]: >>>> The dmtimer functions to read and write the dmtimer registers are currently >>>> defined as follows ... >>>> >>>> static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, >>>> int posted); >>>> static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, >>>> u32 reg, u32 val, int posted); >>>> >>>> The posted variable indicates if the timer is configured to use the posted mode >>>> when performing register accesses. The posted mode configuration of the dmtimer >>>> is stored in the omap_dm_timer structure that is also being passed to the above >>>> functions and therefore we do not need to pass the posted variable separately. >>>> Therefore, simplify the above functions by removing the posted variable as an >>>> argument as this is not necessary. >>> >>> I believe the reason for passing the posted flag was to optimize out some >>> functions from the timer code as that's being run all the time. >>> >>> Care to check the assembly before and after this patch for the timer >>> functions with objdump -d to make sure it does not add tons of bloat >>> there? >> >> Hi Tony, >> >> Thanks for the details here. I see that makes sense and that the >> compiler could take advantage of this as the functions are inlined. >> >> I have taken a look at the disassembled output using objdump as you >> mentioned. What I see is ... >> >> 1. For dmtimer.c the impact appears negligible, the total number of >> lines outputted by objdump only changed by 8 with (1215 lines) and >> without (1207 lines) the patch applied. >> >> 2. For timer.c the impact is greater. I see that >> omap2_gp_timer_set_next_event() increased by 6 instructions from 29 >> to 35. clocksource_read_cycles() increased by 2 instructions 15 to >> 17 instructions. dmtimer_read_sched_clock() increased by 2 >> instructions from 17 to 19. omap2_gp_timer_set_mode() increased by >> 21 instructions from 102 to 123. >> >> I imagine that we are mainly concerned about >> omap2_gp_timer_set_next_event(), clocksource_read_cycles() and >> dmtimer_read_sched_clock() as these will be called often. Therefore, I >> am not sure if you wish to drop this patch. > > Well does it at lots of new ldr to the critical code? For the omap2_gp_timer_set_next_event() function it adds 3 load instructions, increasing the number of possible loads from 11 to 14. For the clocksource_read_cycles() function it adds 1 load instruction, increasing the number of possible loads from 7 to 8. For the dmtimer_read_sched_clock() function, I don't see any additional loads, but instructions added are a tst and beq instruction. >> By the way, if we do drop this patch, I would then need to fix the >> setting of the posted variable in mach-omap2/timer.c for clock-source in >> the case where a dmtimer is used. Today the code assumes that for >> clock-source and clock-events posted mode is always used. However, with >> the errata i103/i767 we will disable posted mode for clock-source on >> omap2/3/4/5/am33xx devices. > > Yes I see, I guess that means just adding a new systimer entry? Actually, I think we can avoid that by not using posted mode for clock-source timers at all. Posted mode only benefits the clock-events timers that are configured often. The benefit of not using posted mode for clock-source timers and setting the "posted" parameter to 0, will really allow the compiler to optimise the clocksource_read_cycles() and dmtimer_read_sched_clock() quite a bit. So this could be a nice optimisation. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Jon Hunter <jon-hunter@ti.com> [120911 09:26]: > > On 09/10/2012 07:58 PM, Tony Lindgren wrote: > > * Jon Hunter <jon-hunter@ti.com> [120910 15:00]: > >> > >> On 09/07/2012 05:22 PM, Tony Lindgren wrote: > >>> * Jon Hunter <jon-hunter@ti.com> [120905 12:05]: > >>>> The dmtimer functions to read and write the dmtimer registers are currently > >>>> defined as follows ... > >>>> > >>>> static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, > >>>> int posted); > >>>> static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, > >>>> u32 reg, u32 val, int posted); > >>>> > >>>> The posted variable indicates if the timer is configured to use the posted mode > >>>> when performing register accesses. The posted mode configuration of the dmtimer > >>>> is stored in the omap_dm_timer structure that is also being passed to the above > >>>> functions and therefore we do not need to pass the posted variable separately. > >>>> Therefore, simplify the above functions by removing the posted variable as an > >>>> argument as this is not necessary. > >>> > >>> I believe the reason for passing the posted flag was to optimize out some > >>> functions from the timer code as that's being run all the time. > >>> > >>> Care to check the assembly before and after this patch for the timer > >>> functions with objdump -d to make sure it does not add tons of bloat > >>> there? > >> > >> Hi Tony, > >> > >> Thanks for the details here. I see that makes sense and that the > >> compiler could take advantage of this as the functions are inlined. > >> > >> I have taken a look at the disassembled output using objdump as you > >> mentioned. What I see is ... > >> > >> 1. For dmtimer.c the impact appears negligible, the total number of > >> lines outputted by objdump only changed by 8 with (1215 lines) and > >> without (1207 lines) the patch applied. > >> > >> 2. For timer.c the impact is greater. I see that > >> omap2_gp_timer_set_next_event() increased by 6 instructions from 29 > >> to 35. clocksource_read_cycles() increased by 2 instructions 15 to > >> 17 instructions. dmtimer_read_sched_clock() increased by 2 > >> instructions from 17 to 19. omap2_gp_timer_set_mode() increased by > >> 21 instructions from 102 to 123. > >> > >> I imagine that we are mainly concerned about > >> omap2_gp_timer_set_next_event(), clocksource_read_cycles() and > >> dmtimer_read_sched_clock() as these will be called often. Therefore, I > >> am not sure if you wish to drop this patch. > > > > Well does it at lots of new ldr to the critical code? > > For the omap2_gp_timer_set_next_event() function it adds 3 load > instructions, increasing the number of possible loads from 11 to 14. > > For the clocksource_read_cycles() function it adds 1 load instruction, > increasing the number of possible loads from 7 to 8. > > For the dmtimer_read_sched_clock() function, I don't see any additional > loads, but instructions added are a tst and beq instruction. > > >> By the way, if we do drop this patch, I would then need to fix the > >> setting of the posted variable in mach-omap2/timer.c for clock-source in > >> the case where a dmtimer is used. Today the code assumes that for > >> clock-source and clock-events posted mode is always used. However, with > >> the errata i103/i767 we will disable posted mode for clock-source on > >> omap2/3/4/5/am33xx devices. > > > > Yes I see, I guess that means just adding a new systimer entry? > > Actually, I think we can avoid that by not using posted mode for > clock-source timers at all. Posted mode only benefits the clock-events > timers that are configured often. > > The benefit of not using posted mode for clock-source timers and setting > the "posted" parameter to 0, will really allow the compiler to optimise > the clocksource_read_cycles() and dmtimer_read_sched_clock() quite a > bit. So this could be a nice optimisation. OK up to you, but maybe run some benchmarks first to figure out what makes most sense? Updating the timer used to be a bottleneck earlier. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/11/2012 11:34 AM, Tony Lindgren wrote: > * Jon Hunter <jon-hunter@ti.com> [120911 09:26]: >> >> On 09/10/2012 07:58 PM, Tony Lindgren wrote: >>> * Jon Hunter <jon-hunter@ti.com> [120910 15:00]: >>>> >>>> On 09/07/2012 05:22 PM, Tony Lindgren wrote: >>>>> * Jon Hunter <jon-hunter@ti.com> [120905 12:05]: >>>>>> The dmtimer functions to read and write the dmtimer registers are currently >>>>>> defined as follows ... >>>>>> >>>>>> static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, >>>>>> int posted); >>>>>> static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, >>>>>> u32 reg, u32 val, int posted); >>>>>> >>>>>> The posted variable indicates if the timer is configured to use the posted mode >>>>>> when performing register accesses. The posted mode configuration of the dmtimer >>>>>> is stored in the omap_dm_timer structure that is also being passed to the above >>>>>> functions and therefore we do not need to pass the posted variable separately. >>>>>> Therefore, simplify the above functions by removing the posted variable as an >>>>>> argument as this is not necessary. >>>>> >>>>> I believe the reason for passing the posted flag was to optimize out some >>>>> functions from the timer code as that's being run all the time. >>>>> >>>>> Care to check the assembly before and after this patch for the timer >>>>> functions with objdump -d to make sure it does not add tons of bloat >>>>> there? >>>> >>>> Hi Tony, >>>> >>>> Thanks for the details here. I see that makes sense and that the >>>> compiler could take advantage of this as the functions are inlined. >>>> >>>> I have taken a look at the disassembled output using objdump as you >>>> mentioned. What I see is ... >>>> >>>> 1. For dmtimer.c the impact appears negligible, the total number of >>>> lines outputted by objdump only changed by 8 with (1215 lines) and >>>> without (1207 lines) the patch applied. >>>> >>>> 2. For timer.c the impact is greater. I see that >>>> omap2_gp_timer_set_next_event() increased by 6 instructions from 29 >>>> to 35. clocksource_read_cycles() increased by 2 instructions 15 to >>>> 17 instructions. dmtimer_read_sched_clock() increased by 2 >>>> instructions from 17 to 19. omap2_gp_timer_set_mode() increased by >>>> 21 instructions from 102 to 123. >>>> >>>> I imagine that we are mainly concerned about >>>> omap2_gp_timer_set_next_event(), clocksource_read_cycles() and >>>> dmtimer_read_sched_clock() as these will be called often. Therefore, I >>>> am not sure if you wish to drop this patch. >>> >>> Well does it at lots of new ldr to the critical code? >> >> For the omap2_gp_timer_set_next_event() function it adds 3 load >> instructions, increasing the number of possible loads from 11 to 14. >> >> For the clocksource_read_cycles() function it adds 1 load instruction, >> increasing the number of possible loads from 7 to 8. >> >> For the dmtimer_read_sched_clock() function, I don't see any additional >> loads, but instructions added are a tst and beq instruction. >> >>>> By the way, if we do drop this patch, I would then need to fix the >>>> setting of the posted variable in mach-omap2/timer.c for clock-source in >>>> the case where a dmtimer is used. Today the code assumes that for >>>> clock-source and clock-events posted mode is always used. However, with >>>> the errata i103/i767 we will disable posted mode for clock-source on >>>> omap2/3/4/5/am33xx devices. >>> >>> Yes I see, I guess that means just adding a new systimer entry? >> >> Actually, I think we can avoid that by not using posted mode for >> clock-source timers at all. Posted mode only benefits the clock-events >> timers that are configured often. >> >> The benefit of not using posted mode for clock-source timers and setting >> the "posted" parameter to 0, will really allow the compiler to optimise >> the clocksource_read_cycles() and dmtimer_read_sched_clock() quite a >> bit. So this could be a nice optimisation. > > OK up to you, but maybe run some benchmarks first to figure out what > makes most sense? Updating the timer used to be a bottleneck earlier. Ok, let me re-work this. Thanks for the inputs. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 1ee67a3..43da595 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -94,7 +94,7 @@ static int omap2_gp_timer_set_next_event(unsigned long cycles, struct clock_event_device *evt) { __omap_dm_timer_load_start(&clkev, OMAP_TIMER_CTRL_ST, - 0xffffffff - cycles, 1); + 0xffffffff - cycles); return 0; } @@ -104,7 +104,7 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode, { u32 period; - __omap_dm_timer_stop(&clkev, 1, clkev.rate); + __omap_dm_timer_stop(&clkev, clkev.rate); switch (mode) { case CLOCK_EVT_MODE_PERIODIC: @@ -112,10 +112,10 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode, period -= 1; /* Looks like we need to first set the load value separately */ __omap_dm_timer_write(&clkev, OMAP_TIMER_LOAD_REG, - 0xffffffff - period, 1); + 0xffffffff - period); __omap_dm_timer_load_start(&clkev, OMAP_TIMER_CTRL_AR | OMAP_TIMER_CTRL_ST, - 0xffffffff - period, 1); + 0xffffffff - period); break; case CLOCK_EVT_MODE_ONESHOT: break; @@ -246,7 +246,7 @@ static bool use_gptimer_clksrc; */ static cycle_t clocksource_read_cycles(struct clocksource *cs) { - return (cycle_t)__omap_dm_timer_read_counter(&clksrc, 1); + return (cycle_t)__omap_dm_timer_read_counter(&clksrc); } static struct clocksource clocksource_gpt = { @@ -260,7 +260,7 @@ static struct clocksource clocksource_gpt = { static u32 notrace dmtimer_read_sched_clock(void) { if (clksrc.reserved) - return __omap_dm_timer_read_counter(&clksrc, 1); + return __omap_dm_timer_read_counter(&clksrc); return 0; } @@ -316,7 +316,7 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id, BUG_ON(res); __omap_dm_timer_load_start(&clksrc, - OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1); + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0); setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate); if (clocksource_register_hz(&clocksource_gpt, clksrc.rate)) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 1eb7353..541adbb 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -63,7 +63,7 @@ static DEFINE_SPINLOCK(dm_timer_lock); static inline u32 omap_dm_timer_read_reg(struct omap_dm_timer *timer, u32 reg) { WARN_ON((reg & 0xff) < _OMAP_TIMER_WAKEUP_EN_OFFSET); - return __omap_dm_timer_read(timer, reg, timer->posted); + return __omap_dm_timer_read(timer, reg); } /** @@ -80,7 +80,7 @@ static void omap_dm_timer_write_reg(struct omap_dm_timer *timer, u32 reg, u32 value) { WARN_ON((reg & 0xff) < _OMAP_TIMER_WAKEUP_EN_OFFSET); - __omap_dm_timer_write(timer, reg, value, timer->posted); + __omap_dm_timer_write(timer, reg, value); } static void omap_timer_restore_context(struct omap_dm_timer *timer) @@ -377,7 +377,7 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer) if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) rate = clk_get_rate(timer->fclk); - __omap_dm_timer_stop(timer, timer->posted, rate); + __omap_dm_timer_stop(timer, rate); if (!(timer->capability & OMAP_TIMER_ALWON)) timer->ctx_loss_count = @@ -511,7 +511,7 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer *timer, int autoreload, } l |= OMAP_TIMER_CTRL_ST; - __omap_dm_timer_load_start(timer, l, load, timer->posted); + __omap_dm_timer_load_start(timer, l, load); /* Save the context */ timer->context.tclr = l; @@ -646,7 +646,7 @@ unsigned int omap_dm_timer_read_counter(struct omap_dm_timer *timer) return 0; } - return __omap_dm_timer_read_counter(timer, timer->posted); + return __omap_dm_timer_read_counter(timer); } EXPORT_SYMBOL_GPL(omap_dm_timer_read_counter); diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h index 6488a19..b3150a3 100644 --- a/arch/arm/plat-omap/include/plat/dmtimer.h +++ b/arch/arm/plat-omap/include/plat/dmtimer.h @@ -283,20 +283,19 @@ struct omap_dm_timer { int omap_dm_timer_prepare(struct omap_dm_timer *timer); -static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, - int posted) +static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg) { - if (posted) + if (timer->posted) while (__raw_readl(timer->pend) & (reg >> WPSHIFT)) cpu_relax(); return __raw_readl(timer->func_base + (reg & 0xff)); } -static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, - u32 reg, u32 val, int posted) +static inline void +__omap_dm_timer_write(struct omap_dm_timer *timer, u32 reg, u32 val) { - if (posted) + if (timer->posted) while (__raw_readl(timer->pend) & (reg >> WPSHIFT)) cpu_relax(); @@ -340,7 +339,7 @@ static inline void __omap_dm_timer_enable_posted(struct omap_dm_timer *timer) return; __omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG, - OMAP_TIMER_CTRL_POSTED, 0); + OMAP_TIMER_CTRL_POSTED); timer->context.tsicr = OMAP_TIMER_CTRL_POSTED; timer->posted = 1; } @@ -387,18 +386,18 @@ static inline int __omap_dm_timer_set_source(struct clk *timer_fck, return ret; } -static inline void __omap_dm_timer_stop(struct omap_dm_timer *timer, - int posted, unsigned long rate) +static inline void +__omap_dm_timer_stop(struct omap_dm_timer *timer, unsigned long rate) { u32 l; - l = __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, posted); + l = __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG); if (l & OMAP_TIMER_CTRL_ST) { l &= ~0x1; - __omap_dm_timer_write(timer, OMAP_TIMER_CTRL_REG, l, posted); + __omap_dm_timer_write(timer, OMAP_TIMER_CTRL_REG, l); #ifdef CONFIG_ARCH_OMAP2PLUS /* Readback to make sure write has completed */ - __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG, posted); + __omap_dm_timer_read(timer, OMAP_TIMER_CTRL_REG); /* * Wait for functional clock period x 3.5 to make sure that * timer is stopped @@ -412,24 +411,22 @@ static inline void __omap_dm_timer_stop(struct omap_dm_timer *timer, } static inline void __omap_dm_timer_load_start(struct omap_dm_timer *timer, - u32 ctrl, unsigned int load, - int posted) + u32 ctrl, unsigned int load) { - __omap_dm_timer_write(timer, OMAP_TIMER_COUNTER_REG, load, posted); - __omap_dm_timer_write(timer, OMAP_TIMER_CTRL_REG, ctrl, posted); + __omap_dm_timer_write(timer, OMAP_TIMER_COUNTER_REG, load); + __omap_dm_timer_write(timer, OMAP_TIMER_CTRL_REG, ctrl); } static inline void __omap_dm_timer_int_enable(struct omap_dm_timer *timer, unsigned int value) { __raw_writel(value, timer->irq_ena); - __omap_dm_timer_write(timer, OMAP_TIMER_WAKEUP_EN_REG, value, 0); + __omap_dm_timer_write(timer, OMAP_TIMER_WAKEUP_EN_REG, value); } -static inline unsigned int -__omap_dm_timer_read_counter(struct omap_dm_timer *timer, int posted) +static inline u32 __omap_dm_timer_read_counter(struct omap_dm_timer *timer) { - return __omap_dm_timer_read(timer, OMAP_TIMER_COUNTER_REG, posted); + return __omap_dm_timer_read(timer, OMAP_TIMER_COUNTER_REG); } static inline void __omap_dm_timer_write_status(struct omap_dm_timer *timer,
The dmtimer functions to read and write the dmtimer registers are currently defined as follows ... static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg, int posted); static inline void __omap_dm_timer_write(struct omap_dm_timer *timer, u32 reg, u32 val, int posted); The posted variable indicates if the timer is configured to use the posted mode when performing register accesses. The posted mode configuration of the dmtimer is stored in the omap_dm_timer structure that is also being passed to the above functions and therefore we do not need to pass the posted variable separately. Therefore, simplify the above functions by removing the posted variable as an argument as this is not necessary. Signed-off-by: Jon Hunter <jon-hunter@ti.com> --- arch/arm/mach-omap2/timer.c | 14 +++++------ arch/arm/plat-omap/dmtimer.c | 10 ++++---- arch/arm/plat-omap/include/plat/dmtimer.h | 37 +++++++++++++---------------- 3 files changed, 29 insertions(+), 32 deletions(-)