All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@ti.com>, Paul Walmsley <paul@pwsan.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 08/10] ARM: OMAP: Clean-up timer posted mode support
Date: Mon, 10 Sep 2012 17:58:02 -0700	[thread overview]
Message-ID: <20120911005802.GE1303@atomide.com> (raw)
In-Reply-To: <504E62C8.8030100@ti.com>

* 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

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 08/10] ARM: OMAP: Clean-up timer posted mode support
Date: Mon, 10 Sep 2012 17:58:02 -0700	[thread overview]
Message-ID: <20120911005802.GE1303@atomide.com> (raw)
In-Reply-To: <504E62C8.8030100@ti.com>

* 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

  reply	other threads:[~2012-09-11  0:58 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05 19:04 [PATCH 00/10] ARM: OMAP: DMTIMER fixes and clean-up Jon Hunter
2012-09-05 19:04 ` Jon Hunter
2012-09-05 19:04 ` [PATCH 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767 Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-06  5:07   ` Vaibhav Hiremath
2012-09-06  5:07     ` Vaibhav Hiremath
2012-09-06 14:06     ` Jon Hunter
2012-09-06 14:06       ` Jon Hunter
2012-09-06 14:42       ` Jon Hunter
2012-09-06 14:42         ` Jon Hunter
2012-09-06 15:20         ` Jon Hunter
2012-09-06 15:20           ` Jon Hunter
2012-09-13 10:26           ` Hiremath, Vaibhav
2012-09-13 10:26             ` Hiremath, Vaibhav
2012-09-13 10:24       ` Hiremath, Vaibhav
2012-09-13 10:24         ` Hiremath, Vaibhav
2012-09-05 19:04 ` [PATCH 02/10] ARM: OMAP: Fix timer posted mode support Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-06 12:57   ` Vaibhav Hiremath
2012-09-06 12:57     ` Vaibhav Hiremath
2012-09-06 14:20     ` Jon Hunter
2012-09-06 14:20       ` Jon Hunter
2012-09-06 16:01       ` Jon Hunter
2012-09-06 16:01         ` Jon Hunter
2012-09-13 10:24         ` Hiremath, Vaibhav
2012-09-13 10:24           ` Hiremath, Vaibhav
2012-09-05 19:04 ` [PATCH 03/10] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-05 19:04 ` [PATCH 04/10] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-05 19:04 ` [PATCH 05/10] ARM: OMAP2+: Don't use __omap_dm_timer_reset() Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-05 19:04 ` [PATCH 06/10] ARM: OMAP: Fix dmtimer reset for timer1 Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-05 19:04 ` [PATCH 07/10] ARM: OMAP: Clean-up dmtimer reset code Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-05 19:04 ` [PATCH 08/10] ARM: OMAP: Clean-up timer posted mode support Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-07 22:22   ` Tony Lindgren
2012-09-07 22:22     ` Tony Lindgren
2012-09-10 21:59     ` Jon Hunter
2012-09-10 21:59       ` Jon Hunter
2012-09-11  0:58       ` Tony Lindgren [this message]
2012-09-11  0:58         ` Tony Lindgren
2012-09-11 16:26         ` Jon Hunter
2012-09-11 16:26           ` Jon Hunter
2012-09-11 16:34           ` Tony Lindgren
2012-09-11 16:34             ` Tony Lindgren
2012-09-13  3:26             ` Jon Hunter
2012-09-13  3:26               ` Jon Hunter
2012-09-05 19:04 ` [PATCH 09/10] ARM: OMAP: Add dmtimer interrupt disable function Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-06 12:58   ` Vaibhav Hiremath
2012-09-06 12:58     ` Vaibhav Hiremath
2012-09-06 14:26     ` Jon Hunter
2012-09-06 14:26       ` Jon Hunter
2012-09-05 19:04 ` [PATCH 10/10] ARM: OMAP: Remove unnecessary call to clk_get() Jon Hunter
2012-09-05 19:04   ` Jon Hunter
2012-09-06 12:58 ` [PATCH 00/10] ARM: OMAP: DMTIMER fixes and clean-up Vaibhav Hiremath
2012-09-06 12:58   ` Vaibhav Hiremath
2012-09-06 14:30   ` Jon Hunter
2012-09-06 14:30     ` Jon Hunter

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=20120911005802.GE1303@atomide.com \
    --to=tony@atomide.com \
    --cc=jon-hunter@ti.com \
    --cc=khilman@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.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.