Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Mikael Pettersson]

On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote:
> > > Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
> > 
> > Did this ever get resolved?
> 
> All went quiet so I assume its gone away ?

-ENOTIME

The regression is still there in 2.6.23-rc3 (I just checked),
but I haven't had time to debug it yet. I'll try to do something
about it this weekend.

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Jeff Garzik]

Mikael Pettersson wrote:
> On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote:
>>>> Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
>>> Did this ever get resolved?
>> All went quiet so I assume its gone away ?
> 
> -ENOTIME
> 
> The regression is still there in 2.6.23-rc3 (I just checked),
> but I haven't had time to debug it yet. I'll try to do something
> about it this weekend.

Still broken?

	Jeff

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Mikael Pettersson]

On Sun, 14 Oct 2007 13:31:34 -0400, Jeff Garzik wrote:
> Mikael Pettersson wrote:
> > On Thu, 16 Aug 2007 21:19:40 +0100, Alan Cox wrote:
> >>>> Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
> >>> Did this ever get resolved?
> >> All went quiet so I assume its gone away ?
> > 
> > -ENOTIME
> > 
> > The regression is still there in 2.6.23-rc3 (I just checked),
> > but I haven't had time to debug it yet. I'll try to do something
> > about it this weekend.
> 
> Still broken?

No, my fix was included in 2.6.23-rc4.

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Mikael Pettersson]

On Wed, 11 Jul 2007 10:45:35 +0800, Albert Lee wrote:
> Mikael Pettersson wrote:
> > 
> > 
> > 2.6.22 + this prints the following on my G3:
> > 
> > pata_pdc2027x 0000:00:0e.0: version 0.9
> > usec_elapsed for mdelay(37) [35431]
> > start time: [1184112028]s [775333]us 
> > end   time: [1184112028]s [810764]us 
> > pata_pdc2027x 0000:00:0e.0: PLL input clock 1691741 kHz
> > pata_pdc2027x: Invalid PLL input clock 1691741kHz, give up!
> > 
> 
> My x86 box got this:
> Jul 11 10:02:17 p4ht-s kernel: [  260.746980] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
> Jul 11 10:02:17 p4ht-s kernel: [  260.882905] usec_elapsed for mdelay(37) [36734]
> Jul 11 10:02:17 p4ht-s kernel: [  260.882911] start time: [1184119336]s [999802]us 
> Jul 11 10:02:17 p4ht-s kernel: [  260.882914] end   time: [1184119337]s [36536]us 
> Jul 11 10:02:17 p4ht-s kernel: [  260.882917] pata_pdc2027x 0000:02:05.0: PLL input clock 16829 kHz
> 
> So, it seems both mdelay(37) and do_gettimeofday() are working properly on PowerMac G3.
> Maybe the calculated wrong PLL input is due to wrong reading of the counter register?
> Could you please try the attached debug patch for more clue, thanks.

This, supposedly debug-only, patch gives me much better PLL calibration:

pata_pdc2027x 0000:00:0e.0: version 0.9
bccrh [0] bccrl [0]
bccrhv[0] bccrlv[0]
bccrh [7FCF] bccrl [15ED]
bccrhv[7FCF] bccrlv[15D4]
start[0] end[1072141805] 
usec_elapsed for mdelay(100) [105500]
start time: [1184152411]s [689475]us 
end   time: [1184152411]s [794975]us 
PLL input clock[-1563248254]Hz
usec_elapsed for mdelay(37) [35432]
start time: [1184152411]s [818033]us 
end   time: [1184152411]s [853465]us 
bccrh [7FC9] bccrl [1A4B]
bccrhv[7FC9] bccrlv[1A4B]
bccrh [7F98] bccrl [3038]
bccrhv[7F98] bccrlv[301F]
start[1071946315] end[1070346296] 
usec_elapsed for mdelay(100) [103571]
start time: [1184152411]s [874717]us 
end   time: [1184152411]s [978288]us 
PLL input clock[15440000]Hz
usec_elapsed for mdelay(37) [35431]
start time: [1184152411]s [997039]us 
end   time: [1184152412]s [32470]us 
pata_pdc2027x 0000:00:0e.0: PLL input clock 15440 kHz

and from then on things are fine.

Weird. I'll try with an older gcc later (been using gcc-4.2.0 so far).

/Mikael

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Albert Lee]

Mikael Pettersson wrote:
> On Wed, 11 Jul 2007 10:45:35 +0800, Albert Lee wrote:
> 
>>So, it seems both mdelay(37) and do_gettimeofday() are working properly on PowerMac G3.
>>Maybe the calculated wrong PLL input is due to wrong reading of the counter register?
>>Could you please try the attached debug patch for more clue, thanks.
> 
> 
> This, supposedly debug-only, patch gives me much better PLL calibration:
> 
> pata_pdc2027x 0000:00:0e.0: version 0.9
> bccrh [0] bccrl [0]
> bccrhv[0] bccrlv[0]
> bccrh [7FCF] bccrl [15ED]
> bccrhv[7FCF] bccrlv[15D4]
> start[0] end[1072141805] 
> usec_elapsed for mdelay(100) [105500]
> start time: [1184152411]s [689475]us 
> end   time: [1184152411]s [794975]us 
> PLL input clock[-1563248254]Hz
> usec_elapsed for mdelay(37) [35432]
> start time: [1184152411]s [818033]us 
> end   time: [1184152411]s [853465]us 
> bccrh [7FC9] bccrl [1A4B]
> bccrhv[7FC9] bccrlv[1A4B]
> bccrh [7F98] bccrl [3038]
> bccrhv[7F98] bccrlv[301F]
> start[1071946315] end[1070346296] 
> usec_elapsed for mdelay(100) [103571]
> start time: [1184152411]s [874717]us 
> end   time: [1184152411]s [978288]us 
> PLL input clock[15440000]Hz
> usec_elapsed for mdelay(37) [35431]
> start time: [1184152411]s [997039]us 
> end   time: [1184152412]s [32470]us 
> pata_pdc2027x 0000:00:0e.0: PLL input clock 15440 kHz
> 
> and from then on things are fine.
> 
> Weird. I'll try with an older gcc later (been using gcc-4.2.0 so far).
> 

Is the problem reproducible with more reload loops? Maybe we could try
something like:

#!/bin/sh
while : ; do 
  rmmod pata_pdc2027x
  sleep 1
  modprobe pata_pdc2027x
done

and "tail -f /var/log/messages|grep PLL > pll_test.log" to check the
PLL clock.
--
albert

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Mikael Pettersson]

On Tue, 10 Jul 2007 11:52:59 +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);

2.6.22 + this prints the following on my G3:

pata_pdc2027x 0000:00:0e.0: version 0.9
usec_elapsed for mdelay(37) [35431]
start time: [1184112028]s [775333]us 
end   time: [1184112028]s [810764]us 
pata_pdc2027x 0000:00:0e.0: PLL input clock 1691741 kHz
pata_pdc2027x: Invalid PLL input clock 1691741kHz, give up!

/Mikael

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Albert Lee]

Mikael Pettersson wrote:
> 
> 
> 2.6.22 + this prints the following on my G3:
> 
> pata_pdc2027x 0000:00:0e.0: version 0.9
> usec_elapsed for mdelay(37) [35431]
> start time: [1184112028]s [775333]us 
> end   time: [1184112028]s [810764]us 
> pata_pdc2027x 0000:00:0e.0: PLL input clock 1691741 kHz
> pata_pdc2027x: Invalid PLL input clock 1691741kHz, give up!
> 

My x86 box got this:
Jul 11 10:02:17 p4ht-s kernel: [  260.746980] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
Jul 11 10:02:17 p4ht-s kernel: [  260.882905] usec_elapsed for mdelay(37) [36734]
Jul 11 10:02:17 p4ht-s kernel: [  260.882911] start time: [1184119336]s [999802]us 
Jul 11 10:02:17 p4ht-s kernel: [  260.882914] end   time: [1184119337]s [36536]us 
Jul 11 10:02:17 p4ht-s kernel: [  260.882917] pata_pdc2027x 0000:02:05.0: PLL input clock 16829 kHz

So, it seems both mdelay(37) and do_gettimeofday() are working properly on PowerMac G3.
Maybe the calculated wrong PLL input is due to wrong reading of the counter register?
Could you please try the attached debug patch for more clue, thanks.

--
albert

diff -Nrup 00_libata-dev/drivers/ata/pata_pdc2027x.c 01_debug/drivers/ata/pata_pdc2027x.c
--- 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-11 10:41:41.000000000 +0800
@@ -574,8 +574,8 @@ retry:
 
 	counter = (bccrh << 15) | bccrl;
 
-	PDPRINTK("bccrh [%X] bccrl [%X]\n", bccrh,  bccrl);
-	PDPRINTK("bccrhv[%X] bccrlv[%X]\n", bccrhv, bccrlv);
+	printk(KERN_ERR "bccrh [%X] bccrl [%X]\n", bccrh,  bccrl);
+	printk(KERN_ERR "bccrhv[%X] bccrlv[%X]\n", bccrhv, bccrlv);
 
 	/*
 	 * The 30-bit decreasing counter are read by 2 pieces.
@@ -584,7 +584,7 @@ retry:
 	 */
 	if (retry && !(bccrh == bccrhv && bccrl >= bccrlv)) {
 		retry--;
-		PDPRINTK("rereading counter\n");
+		printk(KERN_ERR "rereading counter\n");
 		goto retry;
 	}
 
@@ -722,8 +722,21 @@ static long pdc_detect_pll_input_clock(s
 	pll_clock = (start_count - end_count) / 100 *
 		(100000000 / usec_elapsed);
 
-	PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
-	PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);
+	printk(KERN_ERR "start[%ld] end[%ld] \n", start_count, end_count);
+	printk(KERN_ERR "usec_elapsed for mdelay(100) [%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);
+	printk(KERN_ERR "PLL input clock[%ld]Hz\n", pll_clock);
+
+	/* mdelay(37) for comparison */
+	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);
 
 	return pll_clock;
 }

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Mikael Pettersson]

(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:

--- dmesg-2.6.22-rc5	2007-06-23 20:45:45.000000000 +0200
+++ dmesg-2.6.22	2007-07-10 00:39:51.000000000 +0200
@@ -1,6 +1,6 @@
 Using PowerMac machine description
 Total memory = 768MB; using 2048kB for hash table (at cfe00000)
-Linux version 2.6.22-rc5 (mikpe@eisbock) (gcc version 4.2.0) #1 Sat Jun 23 20:38:48 CEST 2007
+Linux version 2.6.22 (mikpe@eisbock) (gcc version 4.2.0) #1 Tue Jul 10 00:29:58 CEST 2007
 Found a Heathrow mac-io controller, rev: 1, mapped at 0xfdf80000
 PowerMac motherboard: PowerMac G3 (Gossamer)
 Entering add_active_range(0, 0, 196608) 0 entries of 256 used
@@ -32,7 +32,7 @@
 console handover: boot [udbg0] -> real [tty0]
 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 771456k/786432k available (2344k kernel code, 14560k reserved, 116k data, 94k bss, 148k init)
+Memory: 771584k/786432k available (2340k kernel code, 14544k reserved, 116k data, 94k bss, 148k init)
 Calibrating delay loop... 33.38 BogoMIPS (lpj=166912)
 Mount-cache hash table entries: 512
 device-tree: Duplicate name in /pci/mac-io, renamed to "ide#1"
@@ -108,17 +108,15 @@
  sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9
 sd 0:0:0:0: [sda] Attached SCSI disk
 pata_pdc2027x 0000:00:0e.0: version 0.9
-pata_pdc2027x 0000:00:0e.0: PLL input clock 16000 kHz
+pata_pdc2027x 0000:00:0e.0: PLL input clock 1691742 kHz
+pata_pdc2027x: Invalid PLL input clock 1691742kHz, give up!
 scsi1 : pata_pdc2027x
 scsi2 : pata_pdc2027x
-ata1: PATA max UDMA/133 cmd 0xf10197c0 ctl 0xf1019fda bmdma 0xf1019000 irq 0
-ata2: PATA max UDMA/133 cmd 0xf10195c0 ctl 0xf1019dda bmdma 0xf1019008 irq 0
-ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480
+ata1: PATA max UDMA/133 cmd 0xf10197c0 ctl 0xf1019fda bmdma 0xf1019000 irq 24
+ata2: PATA max UDMA/133 cmd 0xf10195c0 ctl 0xf1019dda bmdma 0xf1019008 irq 24
 ata1.00: ATA-5: IBM-DTLA-307030, TX4OA6AA, max UDMA/100
 ata1.00: 60036480 sectors, multi 0: LBA 
-ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480
 ata1.00: configured for UDMA/100
-ATA: abnormal status 0x8 on port 0xf10195df
 scsi 1:0:0:0: Direct-Access     ATA      IBM-DTLA-307030  TX4O PQ: 0 ANSI: 5
 sd 1:0:0:0: [sdb] 60036480 512-byte hardware sectors (30739 MB)
 sd 1:0:0:0: [sdb] Write Protect is off
@@ -128,7 +126,36 @@
 sd 1:0:0:0: [sdb] Write Protect is off
 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
- sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >
+ sdb:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+         res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/100
+ata1: EH complete
+ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+         res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/100
+ata1: EH complete
+ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+         res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/100
+ata1: EH complete
+ata1.00: limiting speed to UDMA/66:PIO4
+ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+         res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/66
+ata1: EH complete
+ sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >
 sd 1:0:0:0: [sdb] Attached SCSI disk
 mice: PS/2 mouse device common for all mice
 TCP cubic registered

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.

/Mikael

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Albert Lee]

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);
 

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Jeff Garzik]

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:

Did this ever get resolved?

	Jeff

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

[Alan Cox]

> > Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
> 
> Did this ever get resolved?

All went quiet so I assume its gone away ?