From: Albert Lee <albertcc@tw.ibm.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: jeff@garzik.org, alan@lxorguk.ukuu.org.uk,
bahadir.balban@gmail.com, dwm@enoyolf.org,
linux-ide@vger.kernel.org, linuxppc-dev@ozlabs.org,
sshtylyov@ru.mvista.com
Subject: Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
Date: Tue, 10 Jul 2007 11:52:59 +0800 [thread overview]
Message-ID: <4693029B.2070706@tw.ibm.com> (raw)
In-Reply-To: <200707092304.l69N4Ggd023137@harpo.it.uu.se>
Mikael Pettersson wrote:
> (cc:ing linuxppc-dev)
>
> On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
>
>>Recently the PLL input clock of pata_pdc2027x is sometimes detected
>>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
>>It seems sometimes the mdelay() function is not as precise as it
>>used to be. Per Alan's advice, HT or power management might affect
>>the precision of mdelay().
>>
>>This patch calls gettimeofday() to mesure the time elapsed and
>>calculate the PLL input clock accordingly.
>
>
> Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
>
<snip>
>
> In fairness, this is a slightly non-standard PowerMac G3, in that it
> has a G4 upgrade processor. The firmware doesn't recognise the CPU
> and gives some CPU core frequency-related properties too low values.
> However, the bus frequency property _is_ correct, which is what
> most or all timing stuff should be based on.
>
> Looks like a platform bug.
>
According to the document, do_gettimeofday() has microsecond
resolution. Since the driver calls mdelay(100) (100000 microseconds),
it won't affect the PLL input clock calculation much if somehow
do_gettimeofday() drifts several (say 100) microseconds.
Could you please apply the attached debug patch and collect more info
on the PowerMac G3. Hopefully we can have more clue. Thanks.
--
albert
(BTW, maybe opening a bug in bugzilla.kernel.org would help the
debugging.)
--- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-07-07 09:58:55.000000000 +0800
+++ 01_debug/drivers/ata/pata_pdc2027x.c 2007-07-10 11:18:38.000000000 +0800
@@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s
pll_clock = (start_count - end_count) / 100 *
(100000000 / usec_elapsed);
+ do_gettimeofday(&start_time);
+ mdelay(37);
+ do_gettimeofday(&end_time);
+ usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 1000000 +
+ (end_time.tv_usec - start_time.tv_usec);
+ printk(KERN_ERR "usec_elapsed for mdelay(37) [%ld]\n", usec_elapsed);
+ printk(KERN_ERR "start time: [%ld]s [%ld]us \n", start_time.tv_sec, start_time.tv_usec);
+ printk(KERN_ERR "end time: [%ld]s [%ld]us \n", end_time.tv_sec, end_time.tv_usec);
+
PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);
WARNING: multiple messages have this Message-ID (diff)
From: Albert Lee <albertcc@tw.ibm.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: dwm@enoyolf.org, jeff@garzik.org, linux-ide@vger.kernel.org,
bahadir.balban@gmail.com, linuxppc-dev@ozlabs.org,
alan@lxorguk.ukuu.org.uk
Subject: Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
Date: Tue, 10 Jul 2007 11:52:59 +0800 [thread overview]
Message-ID: <4693029B.2070706@tw.ibm.com> (raw)
In-Reply-To: <200707092304.l69N4Ggd023137@harpo.it.uu.se>
Mikael Pettersson wrote:
> (cc:ing linuxppc-dev)
>
> On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
>
>>Recently the PLL input clock of pata_pdc2027x is sometimes detected
>>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
>>It seems sometimes the mdelay() function is not as precise as it
>>used to be. Per Alan's advice, HT or power management might affect
>>the precision of mdelay().
>>
>>This patch calls gettimeofday() to mesure the time elapsed and
>>calculate the PLL input clock accordingly.
>
>
> Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
>
<snip>
>
> In fairness, this is a slightly non-standard PowerMac G3, in that it
> has a G4 upgrade processor. The firmware doesn't recognise the CPU
> and gives some CPU core frequency-related properties too low values.
> However, the bus frequency property _is_ correct, which is what
> most or all timing stuff should be based on.
>
> Looks like a platform bug.
>
According to the document, do_gettimeofday() has microsecond
resolution. Since the driver calls mdelay(100) (100000 microseconds),
it won't affect the PLL input clock calculation much if somehow
do_gettimeofday() drifts several (say 100) microseconds.
Could you please apply the attached debug patch and collect more info
on the PowerMac G3. Hopefully we can have more clue. Thanks.
--
albert
(BTW, maybe opening a bug in bugzilla.kernel.org would help the
debugging.)
--- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-07-07 09:58:55.000000000 +0800
+++ 01_debug/drivers/ata/pata_pdc2027x.c 2007-07-10 11:18:38.000000000 +0800
@@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s
pll_clock = (start_count - end_count) / 100 *
(100000000 / usec_elapsed);
+ do_gettimeofday(&start_time);
+ mdelay(37);
+ do_gettimeofday(&end_time);
+ usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 1000000 +
+ (end_time.tv_usec - start_time.tv_usec);
+ printk(KERN_ERR "usec_elapsed for mdelay(37) [%ld]\n", usec_elapsed);
+ printk(KERN_ERR "start time: [%ld]s [%ld]us \n", start_time.tv_sec, start_time.tv_usec);
+ printk(KERN_ERR "end time: [%ld]s [%ld]us \n", end_time.tv_sec, end_time.tv_usec);
+
PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);
next prev parent reply other threads:[~2007-07-10 3:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-09 23:04 [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix Mikael Pettersson
2007-07-09 23:04 ` Mikael Pettersson
2007-07-10 3:52 ` Albert Lee [this message]
2007-07-10 3:52 ` Albert Lee
2007-08-16 19:11 ` Jeff Garzik
2007-08-16 19:11 ` Jeff Garzik
2007-08-16 20:19 ` Alan Cox
2007-08-16 20:19 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2007-10-14 18:33 Mikael Pettersson
2007-10-14 18:33 ` Mikael Pettersson
2007-08-17 20:51 Mikael Pettersson
2007-08-17 20:51 ` Mikael Pettersson
2007-10-14 17:31 ` Jeff Garzik
2007-10-14 17:31 ` Jeff Garzik
2007-07-11 10:26 Mikael Pettersson
2007-07-11 10:26 ` Mikael Pettersson
2007-07-16 9:12 ` Albert Lee
2007-07-16 9:12 ` Albert Lee
2007-07-10 23:14 Mikael Pettersson
2007-07-11 2:45 ` Albert Lee
2007-07-11 2:45 ` Albert Lee
2007-06-21 11:47 ide/dma not working from 2.6.19 to 2.6.21 Bahadir Balban
2007-06-21 15:28 ` Sergei Shtylyov
2007-06-25 5:22 ` Albert Lee
2007-06-25 9:10 ` Alan Cox
2007-06-26 5:05 ` Albert Lee
2007-06-26 5:43 ` [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix Albert Lee
2007-07-02 14:14 ` Jeff Garzik
2007-07-02 18:13 ` Bartlomiej Zolnierkiewicz
2007-07-02 18:00 ` Sergei Shtylyov
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=4693029B.2070706@tw.ibm.com \
--to=albertcc@tw.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=albertl@mail.com \
--cc=bahadir.balban@gmail.com \
--cc=dwm@enoyolf.org \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikpe@it.uu.se \
--cc=sshtylyov@ru.mvista.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.