mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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?





  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®