linux-mips
[Top] [All Lists]

Re: [PATCH 3/5] Deforest the function pointer jungle in the time code.

To: "Ralf Baechle" <ralf@linux-mips.org>, "Maciej W. Rozycki" <macro@linux-mips.org>
Subject: Re: [PATCH 3/5] Deforest the function pointer jungle in the time code.
From: "Franck Bui-Huu" <vagabon.xyz@gmail.com>
Date: Sun, 17 Jun 2007 15:36:53 +0200
Cc: "Sergei Shtylyov" <sshtylyov@ru.mvista.com>, linux-mips@linux-mips.org
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jVVk35wTIvPDOdQ1J+MBWbi9+RYVF3v/GbKQ8EwBdnFFA4eNIGyVi9tE9nH9dlg7XRyTON02LtYW6stTLdyxGqm+/5nNJFllGaMVAygz8FL9nkfHLlcFb1qVyPmAysOv8R3EbeGZbqOd6T6q/6pUvwCCBsCvgPNz9nBswiI3zFM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GZaaNkYYE11Ts6GqDa3wlxSLmEITR82gWdIoQAey6qUV6iPXbC0PYOK4KCVp9gJ2Sz8oNsD/pjfV1kxWbFcFEyAmenwclW0whIZSFKye8U7ud6I578qXzhqEmf629jBpYjTdVehixGLVBD3RjCXuRLSqfOKlYZso00+VWhNrT/4=
In-reply-to: <20070615134948.GB16133@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <11818164011355-git-send-email-fbuihuu@gmail.com> <11818164023940-git-send-email-fbuihuu@gmail.com> <20070614111748.GA8223@alpha.franken.de> <cda58cb80706140643g63c3bf34sbd5b843a15653c3d@mail.gmail.com> <Pine.LNX.4.64N.0706141501080.25868@blysk.ds.pg.gda.pl> <cda58cb80706140731j1b6e8e36l96d4423db1ffd9e7@mail.gmail.com> <Pine.LNX.4.64N.0706141648540.25868@blysk.ds.pg.gda.pl> <cda58cb80706150159j5c3d5b7p4293dc529d5ee97c@mail.gmail.com> <20070615134948.GB16133@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
On 6/15/07, Ralf Baechle <ralf@linux-mips.org> wrote:
On Fri, Jun 15, 2007 at 10:59:00AM +0200, Franck Bui-Huu wrote:

> > Please note that this generic calibration code may be used for
> >calibrating the CP0 timer too -- all that you need is defining
>
> Actually the current patchset breaks it since it changes the calibration
> code to be used only for the cp0 hpt calibration. I'll change that.

To many this really fun it also needs to become possible to calibrate
each processor's clock individually - not all MIPS MP systems run their
clocks at the same rate.


OK I've updated patch 5/5, taking into account several raised points.
First of all I put the cp0 hpt clock driver into a file named
"hpt-cp0.c". Therefore there should be no more ambiguties on what
we're taking about. Moreover if a platform needs a new hpt clock
driver it could call it "hpt-foo.c". BTW, Ralf, you made such a driver
for 'i8253' device, can we rename it "hpt-i8253.c" ?

The interface should be simple enough to let all platforms do what
they want without any complexities or hacks. It should be also now
possible to read from platform code and easily understand what they
do/need.

For example for DEC, this should result into:

unsigned dec_calibrate_timer(int cpu)
{
       <...>
       ralf_generic_calibrate_timer(cpu); /* ;) */
       <...>
}

void plat_timer_setup(void)
{
        setup_ds1287_timer();   /* implemented in hpt-ds1287.c ? */

        if (cpu_has_counter) {
                struct cp0_hpt_info info;

                info.get_freq = dec_calibrate_timer;
                info.irq = dec_irq;
                
                setup_cp0_hpt(&info);
        } else if (IOASIC) {
                setup_hpt_ioasic();
        }
}

and with appropriate rating it should do what you want.

Note that 'dec_calibrate_timer' will be called on each cpu the system
has. So it should be possible to calibrate each processor's clock
individually without too much pain.

I have still few questions:

a) mips_hpt_frequency is still used in a few places. I'm not sure it's
a good thing to keep specially since it's broken in it's current form.
For example it doesn't deal with SMP, if a new clock event is loaded
later we'll need to change its value accordingly. Do you think we can
kill it safely ?

b) Are there some weird MIPS CPUs out there which don't read/ack cp0
hpt in the normal way ?

c) the clocksource rating currently depends on the hpt frequency. It's
more important for this kind of device to have the best frequency
stability whereas high frequency is more valuable for a clock event
device. Should we remove this depedency for the clock source rating.

I attached the patch since I can't cut'n past it into GMAIL interface
without space damages (sigh).

Thanks
--
              Franck

Attachment: 0006-Implement-clockevents-for-R4000-style-cp0-timer.patch
Description: Text Data

<Prev in Thread] Current Thread [Next in Thread>