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: Mon, 5 May 2008 23:13:23 -0300 [thread overview]
Message-ID: <20080506021321.GA4928@Pilar.virtua.com.br> (raw)
In-Reply-To: <1210031888.17132.85.camel@localhost.localdomain>
On Mon 5.May'08 at 16:58:08 -0700, Daniel Walker wrote:
>
> On Mon, 2008-05-05 at 20:11 -0300, Carlos R. Mafra wrote:
>
> > - tmp = (u64)hpet_period << HPET_SHIFT;
> > - do_div(tmp, FSEC_PER_NSEC);
> > - clocksource_hpet.mult = (u32)tmp;
> > + clocksource_hpet.mult = div_sc(hpet_period, FSEC_PER_NSEC, HPET_SHIFT);
> >
>
> There's helper functions that should be used called clocksource_hz2mult
> and one called clocksource_khz2mult. I think they're more accurate than
> using div_sc.
Ok, but they take the frequency as the input while the "natural" variable
we have is the period, because that's what we get from the hardware (at
least for the HPET, if I understood it correctly).
If I want to use clocksource_hz2mult then I have
to do one more operation (to find the frequency) before calling it (and
that's what the other part of the patch which you didn't quote is
actually doing).
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?
next prev parent reply other threads:[~2008-05-06 2:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 23:11 Carlos R. Mafra
2008-05-05 23:58 ` Daniel Walker
2008-05-06 2:13 ` Carlos R. Mafra [this message]
2008-05-06 3:23 ` Daniel Walker
2008-05-06 12:59 ` Carlos R. Mafra
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=20080506021321.GA4928@Pilar.virtua.com.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
all inboxes | Powered by JetHome®