Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
> > Unfortunately this breaks pata_pdc2027x on my PowerMac G3: > > Did this ever get resolved? All went quiet so I assume its gone away ? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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 :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[1544]Hz > usec_elapsed for mdelay(37) [35431] > start time: [1184152411]s [997039]us > end time: [1184152412]s [32470]us > pata_pdc2027x :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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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 :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 :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 > :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 :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 :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[1544]Hz usec_elapsed for mdelay(37) [35431] start time: [1184152411]s [997039]us end time: [1184152412]s [32470]us pata_pdc2027x :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 - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
Mikael Pettersson wrote:
>
>
> 2.6.22 + this prints the following on my G3:
>
> pata_pdc2027x :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 :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
: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 :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.0
+0800
+++ 01_debug/drivers/ata/pata_pdc2027x.c2007-07-11 10:41:41.0
+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 *
(1 / 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) * 100 +
+ (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;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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:
> >
>
> >
> > 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) (10 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.0
> +0800
> +++ 01_debug/drivers/ata/pata_pdc2027x.c 2007-07-10 11:18:38.0
> +0800
> @@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s
> pll_clock = (start_count - end_count) / 100 *
> (1 / usec_elapsed);
>
> + do_gettimeofday(&start_time);
> + mdelay(37);
> + do_gettimeofday(&end_time);
> + usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 +
> + (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 :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 :00:0e.0: PLL input clock 1691741 kHz
pata_pdc2027x: Invalid PLL input clock 1691741kHz, give up!
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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:
>
>
> 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) (10 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.0
+0800
+++ 01_debug/drivers/ata/pata_pdc2027x.c2007-07-10 11:18:38.0
+0800
@@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s
pll_clock = (start_count - end_count) / 100 *
(1 / usec_elapsed);
+ do_gettimeofday(&start_time);
+ mdelay(37);
+ do_gettimeofday(&end_time);
+ usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 +
+ (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);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
(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-rc52007-06-23 20:45:45.0 +0200 +++ dmesg-2.6.222007-07-10 00:39:51.0 +0200 @@ -1,6 +1,6 @@ Using PowerMac machine description Total memory = 768MB; using 2048kB for hash table (at cfe0) -Linux version 2.6.22-rc5 ([EMAIL PROTECTED]) (gcc version 4.2.0) #1 Sat Jun 23 20:38:48 CEST 2007 +Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 4.2.0) #1 Tue Jul 10 00:29:58 CEST 2007 Found a Heathrow mac-io controller, rev: 1, mapped at 0xfdf8 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 :00:0e.0: version 0.9 -pata_pdc2027x :00:0e.0: PLL input clock 16000 kHz +pata_pdc2027x :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 - To unsubscribe from
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
Bartlomiej Zolnierkiewicz wrote: Hi, Could you also fix pdc202xx_new driver? "buggy" code should be very similar if not identical... I was going to do that but since I'm only working part-time in the last few days, this keeps being deferred. Also, I need to find the card... MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
Hi,
Could you also fix pdc202xx_new driver?
"buggy" code should be very similar if not identical...
On Tuesday 26 June 2007, 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.
>
> Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
> Cc: Alan Cox <[EMAIL PROTECTED]>
> ---
>
> Did more test. For mdelay(100) the usec_elapsed is usually 99287.
> However, sometimes the usec_elapsed is 118934, longer than expected.
>
> Jun 26 12:12:29 p4ht-s kernel: [ 9156.490991] ACPI: PCI Interrupt
> :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
> Jun 26 12:12:29 p4ht-s kernel: [ 9156.610175] usec_elapsed[118934]
> Jun 26 12:12:29 p4ht-s kernel: [ 9156.610511] pata_pdc2027x :02:05.0: PLL
> input clock 16817 kHz
>
> After the patch, the PLL input clock detected looks more accurate.
> For your review, thanks.
>
> diff -Nrup 00_libata-dev/drivers/ata/pata_pdc2027x.c
> 01_gettimeofday/drivers/ata/pata_pdc2027x.c
> --- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-06-01 12:08:21.0
> +0800
> +++ 01_gettimeofday/drivers/ata/pata_pdc2027x.c 2007-06-26
> 13:08:34.0 +0800
> @@ -689,10 +689,12 @@ static long pdc_detect_pll_input_clock(s
> void __iomem *mmio_base = host->iomap[PDC_MMIO_BAR];
> u32 scr;
> long start_count, end_count;
> - long pll_clock;
> + struct timeval start_time, end_time;
> + long pll_clock, usec_elapsed;
>
> /* Read current counter value */
> start_count = pdc_read_counter(host);
> + do_gettimeofday(&start_time);
>
> /* Start the test mode */
> scr = readl(mmio_base + PDC_SYS_CTL);
> @@ -705,6 +707,7 @@ static long pdc_detect_pll_input_clock(s
>
> /* Read the counter values again */
> end_count = pdc_read_counter(host);
> + do_gettimeofday(&end_time);
>
> /* Stop the test mode */
> scr = readl(mmio_base + PDC_SYS_CTL);
> @@ -713,7 +716,11 @@ static long pdc_detect_pll_input_clock(s
> readl(mmio_base + PDC_SYS_CTL); /* flush */
>
> /* calculate the input clock in Hz */
> - pll_clock = (start_count - end_count) * 10;
> + usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 +
> + (end_time.tv_usec - start_time.tv_usec);
> +
> + pll_clock = (start_count - end_count) / 100 *
> + (1 / usec_elapsed);
>
> PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
> PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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. Signed-off-by: Albert Lee <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> --- Did more test. For mdelay(100) the usec_elapsed is usually 99287. However, sometimes the usec_elapsed is 118934, longer than expected. Jun 26 12:12:29 p4ht-s kernel: [ 9156.490991] ACPI: PCI Interrupt :02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10 Jun 26 12:12:29 p4ht-s kernel: [ 9156.610175] usec_elapsed[118934] Jun 26 12:12:29 p4ht-s kernel: [ 9156.610511] pata_pdc2027x :02:05.0: PLL input clock 16817 kHz After the patch, the PLL input clock detected looks more accurate. For your review, thanks. applied - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
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.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
Did more test. For mdelay(100) the usec_elapsed is usually 99287.
However, sometimes the usec_elapsed is 118934, longer than expected.
Jun 26 12:12:29 p4ht-s kernel: [ 9156.490991] ACPI: PCI Interrupt
:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
Jun 26 12:12:29 p4ht-s kernel: [ 9156.610175] usec_elapsed[118934]
Jun 26 12:12:29 p4ht-s kernel: [ 9156.610511] pata_pdc2027x :02:05.0: PLL
input clock 16817 kHz
After the patch, the PLL input clock detected looks more accurate.
For your review, thanks.
diff -Nrup 00_libata-dev/drivers/ata/pata_pdc2027x.c
01_gettimeofday/drivers/ata/pata_pdc2027x.c
--- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-06-01 12:08:21.0
+0800
+++ 01_gettimeofday/drivers/ata/pata_pdc2027x.c 2007-06-26 13:08:34.0
+0800
@@ -689,10 +689,12 @@ static long pdc_detect_pll_input_clock(s
void __iomem *mmio_base = host->iomap[PDC_MMIO_BAR];
u32 scr;
long start_count, end_count;
- long pll_clock;
+ struct timeval start_time, end_time;
+ long pll_clock, usec_elapsed;
/* Read current counter value */
start_count = pdc_read_counter(host);
+ do_gettimeofday(&start_time);
/* Start the test mode */
scr = readl(mmio_base + PDC_SYS_CTL);
@@ -705,6 +707,7 @@ static long pdc_detect_pll_input_clock(s
/* Read the counter values again */
end_count = pdc_read_counter(host);
+ do_gettimeofday(&end_time);
/* Stop the test mode */
scr = readl(mmio_base + PDC_SYS_CTL);
@@ -713,7 +716,11 @@ static long pdc_detect_pll_input_clock(s
readl(mmio_base + PDC_SYS_CTL); /* flush */
/* calculate the input clock in Hz */
- pll_clock = (start_count - end_count) * 10;
+ usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 +
+ (end_time.tv_usec - start_time.tv_usec);
+
+ pll_clock = (start_count - end_count) / 100 *
+ (1 / usec_elapsed);
PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
