From: "Carlos R. Mafra" <crmafra2@gmail.com>
To: Daniel Walker <dwalker@mvista.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
venkatesh.pallipadi@intel.com
Subject: Re: x86: Clean up computation of HPET .mult variables
Date: Tue, 6 May 2008 09:59:20 -0300 [thread overview]
Message-ID: <20080506125920.GA26295@beyonder.ift.unesp.br> (raw)
In-Reply-To: <1210044218.17132.109.camel@localhost.localdomain>
On Mon 5.May'08 at 20:23:38 -0700, Daniel Walker wrote:
>
> On Mon, 2008-05-05 at 23:13 -0300, Carlos R. Mafra wrote:
> > So the savings in my patch is due to using the period directly, and
> > not the frequency. That's what my idea was, so if you object then
> > my attempt was a failure and should be forgotten :-)
> >
> > Or maybe I should create a clocksource_period2mult to replace
> > clocksource_hz2mult and save the extra operation in more places too?
>
> The one concern I have is the rounding that is done in the
> clocksource_hz2mult(). The div_sc doesn't include it ..
So that would be a point in favour of using div_sc(), right?
> You could add a
> clocksource_period2mult(), that would help out any one later that has a
> period instead of hz ..
Hmm, clocksource_period2mult() would be just a rename of div_sc(), see
for example how clocksource_hpet.mult is computed with my patch:
clocksource_hpet.mult = div_sc(hpet_period, FSEC_PER_NSEC, HPET_SHIFT);
However, hpet_clockevent.mult would also require the exchange of
the first two arguments, due to the different definition of 'mult' in
clockchips.h and clocksource.h
So I would like to ask if this different definition of mult
variables in clockevent versus clocksource is intentional or not.
And do you agree that your first suggestion of using clocksource_hz2mult
makes the code a bit bigger due to the extra computation of the frequency?
My patch saves 49 bytes, and I thought that being careful in the code
comments would make this change a safe thing (because everyone will
understand how the computation is done and that there is a difference
in the definitions).
next prev parent reply other threads:[~2008-05-06 13:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 23:11 x86: Clean up computation of HPET .mult variables Carlos R. Mafra
2008-05-05 23:58 ` Daniel Walker
2008-05-06 2:13 ` Carlos R. Mafra
2008-05-06 3:23 ` Daniel Walker
2008-05-06 12:59 ` Carlos R. Mafra [this message]
2008-05-06 16:21 ` Daniel Walker
2008-05-06 20:50 ` Carlos R. Mafra
2008-05-07 2:17 ` Daniel Walker
2008-05-07 3:39 ` Carlos R. Mafra
2008-05-07 4:21 ` Daniel Walker
2008-05-07 7:13 ` Ingo Molnar
2008-05-06 12:43 ` Ingo Molnar
2008-05-06 13:13 ` Carlos R. Mafra
2008-05-06 18:51 ` rtc-cmos.c: Build fix Carlos R. Mafra
2008-05-07 7:10 ` Ingo Molnar
2008-05-07 21:31 ` Andrew Morton
2008-05-09 8:32 ` Ingo Molnar
2008-05-09 12:33 ` Carlos R. Mafra
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=20080506125920.GA26295@beyonder.ift.unesp.br \
--to=crmafra2@gmail.com \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).