ide/dma not working from 2.6.19 to 2.6.21

ide/dma not working from 2.6.19 to 2.6.21

[Bahadir Balban]

Hi,

I have a PCI Promise TX2 Ultra133 controller with a harddisk on an ARM
platform (which is a barebone system with no BIOS). This setup used to
work with the old linux-ide drivers on 2.6.19 but it does not work
with 2.6.22-rc4, or 2.6.21. Here's the error output:

PDC20269: chipset revision 2
<6>PDC20269: ROM enabled at 0xa0210000
PDC20269: ROM enabled at 0xa0210000
PDC20269: PLL input clock is 37736 kHz
PDC20269: PLL input clock is 37736 kHz
<6>PDC20269: 100% native mode on irq 84
PDC20269: 100% native mode on irq 84
<7>PCI: Enabling bus mastering for device 0000:07:01.0
<6>    ide0: BM-DMA at 0x90050040-0x90050047    ide0: BM-DMA at
0x90050040-0x90050047, BIOS settings
: hda:pio, hdb:pio, BIOS settings: hda:pio, hdb:pio

<6>    ide1: BM-DMA at 0x90050048-0x9005004f    ide1: BM-DMA at
0x90050048-0x9005004f, BIOS settings
: hdc:pio, hdd:pio, BIOS settings: hdc:pio, hdd:pio

<7>Probing IDE interface ide0...
hda: HDS728080PLAT20, hda: HDS728080PLAT20, ATA DISK drive
ATA DISK drive
<4>Warning: Primary channel requires an 80-pin cable for operation.
Warning: Primary channel requires an 80-pin cable for operation.
<4>hda reduced to Ultra33 mode.
hda reduced to Ultra33 mode.
ide0 at 0x90050050-0x90050057,0x90050062 on irq 84ide0 at
0x90050050-0x90050057,0x90050062 on irq 84

<7>Probing IDE interface ide1...
<7>Probing IDE interface ide1...
<6>hda: max request size: 512KiB
hda: max request size: 512KiB
<4>hda: lost interrupt
hda: lost interrupt
<4>hda: lost interrupt
hda: lost interrupt
<4>hda: lost interrupt
hda: lost interrupt
<6>hda: 160836480 sectors (82348 MB)hda: 160836480 sectors (82348 MB)
w/1719KiB Cache w/1719KiB Cach
e, CHS=16383/255/63, CHS=16383/255/63, UDMA(33), UDMA(33)

<4>hda: lost interrupt
hda: lost interrupt
<6>hda: cache flushes supported
hda: cache flushes supported
<6> hda: hda:<4>hda: dma_timer_expiry: dma status == 0x21
<4>hda: dma_timer_expiry: dma status == 0x21
<4>hda: DMA timeout error
hda: DMA timeout error
hda: dma timeout error: status=0x51 { hda: dma timeout error:
status=0x51 { DriveReady DriveReady Se
ekComplete SeekComplete Error Error }
}
hda: dma timeout error: error=0x84 { hda: dma timeout error:
error=0x84 { DriveStatusError DriveStat
usError BadCRC BadCRC }}

ide: failed opcode was: ide: failed opcode was: unknown
unknown
<4>hda: lost interrupt
hda: lost interrupt

On 2.6.21 I have been using:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_OFFBOARD=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y

On 2.6.19 I have exactly the same but also:

CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_AUTO=y

Could this have caused a problem?

Does IDE support in linux depend on certain BIOS settings or any other
motherboard specific details? I am asking because neither the new ata
nor the old ide layer worked for the cards I tried on ARM (JMB363,
IT8212, Promise TX2 133 -> worked only with 2.6.19 old ide layer).

Finally is there a simplest, known-to-work pci ide controller you can
suggest? So that I can start looking from there.

Thank you,
Bahadir

Re: ide/dma not working from 2.6.19 to 2.6.21

[Sergei Shtylyov]

Hello.

Bahadir Balban wrote:

> I have a PCI Promise TX2 Ultra133 controller with a harddisk on an ARM
> platform (which is a barebone system with no BIOS). This setup used to
> work with the old linux-ide drivers on 2.6.19

    You were very lucky then bacause actually it usually failed on anything 
non-x86. ;-)

> but it does not work
> with 2.6.22-rc4, or 2.6.21. Here's the error output:

    I guess this might be related to the driver update in 2.6.20-rc1 then -- I 
made the driver calibrate the chip's PLL, so that it might work for non-x86 
case too (where Promise BIOS isn't available to do this). The code is 
basically the same as in the libata's pata_2027x driver...

> PDC20269: chipset revision 2
> <6>PDC20269: ROM enabled at 0xa0210000
> PDC20269: ROM enabled at 0xa0210000

    Hm, why all the messages are printed twice? :-O
    (I'll cut out the dupes to save bandwidth).

> PDC20269: PLL input clock is 37736 kHz

    37.736 MHz is a pretty strange PLL clock... Basically, it's the halved PCI 
clock, and that value signifies your PCI is probably running at 75 MHz -- 
which is serious overclocking... :-/
    That could explain why the driver managed to work before -- the default 
DPLL settings fit for 66 MHz PCI but made the UltraDMA fail with CRC errors on 
the plain 33 MHz PCI, IIRC...
    I may suggest replacing #undef DEBUG by #define DEBUG in this driver, 
rebuilding the kernel and posting the driver's output...

> <6>PDC20269: 100% native mode on irq 84
> <7>PCI: Enabling bus mastering for device 0000:07:01.0
> <6>    ide0: BM-DMA at 0x90050040-0x90050047, BIOS settings: hda:pio, hdb:pio
> <6>    ide1: BM-DMA at 0x90050048-0x9005004f, BIOS settings: hdc:pio, hdd:pio
> <7>Probing IDE interface ide0...
> hda: HDS728080PLAT20, ATA DISK drive
> <4>Warning: Primary channel requires an 80-pin cable for operation.
> <4>hda reduced to Ultra33 mode.
> hda reduced to Ultra33 mode.

    Oh, now I understand why it used to work for you before 2.6.20 -- UltraDMA 
only failed with 80-conductor cable on non-x86. :-)
    Have you been using the 40-conductor cable all the time?

> ide0 at 0x90050050-0x90050057,0x90050062 on irq 84
> <7>Probing IDE interface ide1...
> <6>hda: max request size: 512KiB
> <4>hda: lost interrupt
> <4>hda: lost interrupt
> <4>hda: lost interrupt

    Hm, that's interesting -- I'm not sure how the driver rewrite could have 
affected the interrupt delivery for PIO commands (there's no prior "DMA 
interrupt recovery" messages).  Might be some other issue here...

> <6>hda: 160836480 sectors (82348 MB) w/1719KiB Cache, CHS=16383/255/63, UDMA(33)
> <4>hda: lost interrupt
> <6>hda: cache flushes supported
> <6> hda: <4>hda: dma_timer_expiry: dma status == 0x21
> <4>hda: DMA timeout error
> hda: dma timeout error: status=0x51 { DriveReady SeekComplete Error }
> hda: dma timeout error: error=0x84 { DriveStatusError BadCRC }

    This is too familiar -- that's how the driver used to behave on

> ide: failed opcode was: unknown
> <4>hda: lost interrupt

> On 2.6.21 I have been using:
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_BLK_DEV_IDECD=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_BLK_DEV_PDC202XX_NEW=y
> CONFIG_IDE_GENERIC=y
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_OFFBOARD=y
> CONFIG_BLK_DEV_GENERIC=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y

> On 2.6.19 I have exactly the same but also:

> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_IDEDMA_AUTO=y

> Could this have caused a problem?

    No.

> Does IDE support in linux depend on certain BIOS settings or any other
> motherboard specific details? I am asking because neither the new ata
> nor the old ide layer worked for the cards I tried on ARM (JMB363,
> IT8212, Promise TX2 133 -> worked only with 2.6.19 old ide layer).

    As for the Promise -- it used to before 2.2.20-rc1, and it shouldn't since.

> Finally is there a simplest, known-to-work pci ide controller you can
> suggest? So that I can start looking from there.

    Your Promise card should actually be working...

> Thank you,
> Bahadir

MBR, Sergei

Re: ide/dma not working from 2.6.19 to 2.6.21

[Sergei Shtylyov]

I wrote:

>> ide0 at 0x90050050-0x90050057,0x90050062 on irq 84
>> <7>Probing IDE interface ide1...
>> <6>hda: max request size: 512KiB
>> <4>hda: lost interrupt
>> <4>hda: lost interrupt
>> <4>hda: lost interrupt

>    Hm, that's interesting -- I'm not sure how the driver rewrite could 
> have affected the interrupt delivery for PIO commands (there's no prior 
> "DMA interrupt recovery" messages).  Might be some other issue here...

>> <6>hda: 160836480 sectors (82348 MB) w/1719KiB Cache, 
>> CHS=16383/255/63, UDMA(33)
>> <4>hda: lost interrupt
>> <6>hda: cache flushes supported
>> <6> hda: <4>hda: dma_timer_expiry: dma status == 0x21
>> <4>hda: DMA timeout error
>> hda: dma timeout error: status=0x51 { DriveReady SeekComplete Error }
>> hda: dma timeout error: error=0x84 { DriveStatusError BadCRC }

>    This is too familiar -- that's how the driver used to behave on

    ...non-x86 targets before the 2.6.20-rc1 change -- although it usually 
exhibited it on higher speeds until the IDE core fekk back to UltraATA/33 or 
/44, then it started to work...

>> Does IDE support in linux depend on certain BIOS settings or any other
>> motherboard specific details? I am asking because neither the new ata
>> nor the old ide layer worked for the cards I tried on ARM (JMB363,
>> IT8212, Promise TX2 133 -> worked only with 2.6.19 old ide layer).

>    As for the Promise -- it used to before 2.2.20-rc1, and it shouldn't 
> since.

    I meant "used to depend on BIOS settings" here.

MBR, Sergei

Re: ide/dma not working from 2.6.19 to 2.6.21

[Albert Lee]

Sergei Shtylyov wrote:
> Hello.
> 
> Bahadir Balban wrote:
> 
>> I have a PCI Promise TX2 Ultra133 controller with a harddisk on an ARM
>> platform (which is a barebone system with no BIOS). This setup used to
>> work with the old linux-ide drivers on 2.6.19
> 
> 
>    You were very lucky then bacause actually it usually failed on
> anything non-x86. ;-)
> 
>> but it does not work
>> with 2.6.22-rc4, or 2.6.21. Here's the error output:
> 
> 
>    I guess this might be related to the driver update in 2.6.20-rc1 then
> -- I made the driver calibrate the chip's PLL, so that it might work for
> non-x86 case too (where Promise BIOS isn't available to do this). The
> code is basically the same as in the libata's pata_2027x driver...
> 
>> PDC20269: chipset revision 2
>> <6>PDC20269: ROM enabled at 0xa0210000
>> PDC20269: ROM enabled at 0xa0210000
> 
> 
>    Hm, why all the messages are printed twice? :-O
>    (I'll cut out the dupes to save bandwidth).
> 
>> PDC20269: PLL input clock is 37736 kHz
> 
> 
>    37.736 MHz is a pretty strange PLL clock... Basically, it's the
> halved PCI clock, and that value signifies your PCI is probably running
> at 75 MHz -- which is serious overclocking... :-/
>    That could explain why the driver managed to work before -- the
> default DPLL settings fit for 66 MHz PCI but made the UltraDMA fail with
> CRC errors on the plain 33 MHz PCI, IIRC...
>    I may suggest replacing #undef DEBUG by #define DEBUG in this driver,
> rebuilding the kernel and posting the driver's output...
> 

I don't know whether this is related or not. Recently I noticed that
the PLL clock being detected higher than expected as 20MHz on my box.
(It used be 16.6 MHz since my PCI bus is running at 33MHz...)

Reloading the pata_pdc2027x module then the problem goes away.
I guess maybe somehow mdelay() is not as precise as before...

--
albert

(dmesg attached for reference)
The PLL clock is wrongly detected as 20MHz on my box, kernel 2.6.22-rc3.

[ 5545.255266] pata_pdc2027x 0000:02:05.0: version 0.9
[ 5545.255489] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
[ 5545.374703] pata_pdc2027x 0000:02:05.0: PLL input clock 20027 kHz
[ 5545.404872] scsi2 : pata_pdc2027x
[ 5545.430357] scsi3 : pata_pdc2027x
[ 5545.433338] ata3: PATA max UDMA/133 cmd 0xe09897c0 ctl 0xe0989fda bmdma 0xe0989000 irq 0
[ 5545.433671] ata4: PATA max UDMA/133 cmd 0xe09895c0 ctl 0xe0989dda bmdma 0xe0989008 irq 0
[ 5545.916581] ata3.00: ATAPI, max UDMA/33
[ 5545.916590] ata3.01: ATAPI, max UDMA/33
[ 5546.080361] ata3.00: configured for UDMA/33
[ 5546.244197] ata3.01: configured for UDMA/33
[ 5546.410493] scsi 2:0:0:0: CD-ROM            LITE-ON  CD-RW SOHR-5238S 4S07 PQ: 0 ANSI: 5
[ 5546.437658] scsi 2:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-4163B A105 PQ: 0 ANSI: 5
[ 5546.604481] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray
[ 5546.604808] Uniform CD-ROM driver Revision: 3.20
[ 5546.607596] sr 2:0:0:0: Attached scsi CD-ROM sr0
[ 5546.612168] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
[ 5546.614075] sr 2:0:1:0: Attached scsi CD-ROM sr1
[ 5640.334685] ata3.00: disabled
[ 5640.334695] ata3.01: disabled
[ 5640.403451] ACPI: PCI interrupt for device 0000:02:05.0 disabled
==============================================================================================
The PLL clock clock is correct after rmmod and reload the module:

[ 5644.153643] pata_pdc2027x 0000:02:05.0: version 0.9
[ 5644.153723] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
[ 5644.252954] pata_pdc2027x 0000:02:05.0: PLL input clock 16714 kHz
[ 5644.303470] scsi4 : pata_pdc2027x
[ 5644.319285] scsi5 : pata_pdc2027x
[ 5644.321207] ata5: PATA max UDMA/133 cmd 0xe09897c0 ctl 0xe0989fda bmdma 0xe0989000 irq 0
[ 5644.321215] ata6: PATA max UDMA/133 cmd 0xe09895c0 ctl 0xe0989dda bmdma 0xe0989008 irq 0
[ 5644.803308] ata5.00: ATAPI, max UDMA/33
[ 5644.803629] ata5.01: ATAPI, max UDMA/33
[ 5644.967144] ata5.00: configured for UDMA/33
[ 5645.130975] ata5.01: configured for UDMA/33
[ 5645.287539] scsi 4:0:0:0: CD-ROM            LITE-ON  CD-RW SOHR-5238S 4S07 PQ: 0 ANSI: 5
[ 5645.291669] sr0: scsi3-mmc drive: 52x/52x writer cd/rw xa/form2 cdda tray
[ 5645.294295] sr 4:0:0:0: Attached scsi CD-ROM sr0
[ 5645.300189] scsi 4:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-4163B A105 PQ: 0 ANSI: 5
[ 5645.305716] sr1: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray
[ 5645.306736] sr 4:0:1:0: Attached scsi CD-ROM sr1
[albertcc@p4ht-s june_2007]$ 

Re: ide/dma not working from 2.6.19 to 2.6.21

[Alan Cox]

> Reloading the pata_pdc2027x module then the problem goes away.
> I guess maybe somehow mdelay() is not as precise as before...

It's not the most accurate of things once power management and the like
get invovled. HT doesn't help it either. You should have get much more
accurate timing information if you query gettimeofday before/after and do
a few loops.

Alan

Re: ide/dma not working from 2.6.19 to 2.6.21

[Albert Lee]

Alan Cox wrote:
>>Reloading the pata_pdc2027x module then the problem goes away.
>>I guess maybe somehow mdelay() is not as precise as before...
> 
> 
> It's not the most accurate of things once power management and the like
> get invovled. HT doesn't help it either. You should have get much more
> accurate timing information if you query gettimeofday before/after and do
> a few loops.
> 

Thanks for the advice. Patch to follow.

--
albert

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

[Albert Lee]

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 <albertcc@tw.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
---

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 0000: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 0000: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.000000000 +0800
+++ 01_gettimeofday/drivers/ata/pata_pdc2027x.c	2007-06-26 13:08:34.000000000 +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) * 1000000 +
+		(end_time.tv_usec - start_time.tv_usec);
+
+	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);

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

[Jeff Garzik]

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 <albertcc@tw.ibm.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> ---
> 
> 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 0000: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 0000:02:05.0: PLL input clock 16817 kHz
> 
> After the patch, the PLL input clock detected looks more accurate.
> For your review, thanks.

applied

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

[Sergei Shtylyov]

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

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

[Bartlomiej Zolnierkiewicz]

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 <albertcc@tw.ibm.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> ---
> 
> 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 0000: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 0000: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.000000000 +0800
> +++ 01_gettimeofday/drivers/ata/pata_pdc2027x.c	2007-06-26 13:08:34.000000000 +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) * 1000000 +
> +		(end_time.tv_usec - start_time.tv_usec);
> +
> +	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);

[PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Albert Lee]

Recently the PLL input clock of Promise 2027x 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 <albertcc@tw.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
---
(I have the Promise adapter at hand, so it's easier for me to verify.)
Attached please find the patch and the test result on my box for your review:
[   72.186805] PDC20275: chipset revision 1
[   72.196768] start[1039788039] end[1039620652] pll[16804952]
[   72.196819] PDC20275: PLL input clock is 16804 kHz
[   72.226586] PDC20275: 100% native mode on irq 10

Maybe Bahadir could also help to verify if it helps to his "hda lost interrupt" problem.

--- linux-2.6.22-rc7/drivers/ide/pci/pdc202xx_new.c.ori	2007-07-02 14:40:08.000000000 +0800
+++ linux-2.6.22-rc7/drivers/ide/pci/pdc202xx_new.c	2007-07-03 13:06:40.000000000 +0800
@@ -306,11 +306,13 @@ static long __devinit read_counter(u32 d
  */
 static long __devinit detect_pll_input_clock(unsigned long dma_base)
 {
+	struct timeval start_time, end_time;
 	long start_count, end_count;
-	long pll_input;
+	long pll_input, usec_elapsed;
 	u8 scr1;
 
 	start_count = read_counter(dma_base);
+	do_gettimeofday(&start_time);
 
 	/* Start the test mode */
 	outb(0x01, dma_base + 0x01);
@@ -322,6 +324,7 @@ static long __devinit detect_pll_input_c
 	mdelay(10);
 
 	end_count = read_counter(dma_base);
+	do_gettimeofday(&end_time);
 
 	/* Stop the test mode */
 	outb(0x01, dma_base + 0x01);
@@ -333,7 +336,10 @@ static long __devinit detect_pll_input_c
 	 * Calculate the input clock in Hz
 	 * (the clock counter is 30 bit wide and counts down)
 	 */
-	pll_input = ((start_count - end_count) & 0x3ffffff) * 100;
+	usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 1000000 +
+		(end_time.tv_usec - start_time.tv_usec);
+	pll_input = ((start_count - end_count) & 0x3ffffff) / 10 *
+		(10000000 / usec_elapsed);
 
 	DBG("start[%ld] end[%ld]\n", start_count, end_count);
 

Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Sergei Shtylyov]

Hello.

Albert Lee wrote:
> Recently the PLL input clock of Promise 2027x is sometimes detected
> higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
      ^ h

> 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
                                        ^ a
> calculate the PLL input clock accordingly.

> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

    Except for types in description:

Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

MBR, Sergei ;-)

Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Bartlomiej Zolnierkiewicz]

On Tuesday 03 July 2007, Albert Lee wrote:
> Recently the PLL input clock of Promise 2027x 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 <albertcc@tw.ibm.com>

applied, thanks!

Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Bartlomiej Zolnierkiewicz]

On Tuesday 03 July 2007, Sergei Shtylyov wrote:
> Hello.
> 
> Albert Lee wrote:
> > Recently the PLL input clock of Promise 2027x is sometimes detected
> > higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
>       ^ h
> 
> > 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
>                                         ^ a
> > calculate the PLL input clock accordingly.

typos fixed manually

> > Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> 
>     Except for types in description:
> 
> Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

added

Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:

> typos fixed manually

>>>Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

>>    Except for types in description:

    Said he, while making his own typo. :-)

>>Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>

MBR, Sergei

Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Albert Lee]

Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
> 
>> typos fixed manually
> 
> 
>>>> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> 
> 
>>>    Except for types in description:
> 
> 
>    Said he, while making his own typo. :-)
> 

:)

--
albert

Re: [PATCH 1/1] ide: pdc202xx_new PLL input clock fix

[Bahadir Balban]

On 7/3/07, Albert Lee <albertcc@tw.ibm.com> wrote:
> Recently the PLL input clock of Promise 2027x 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 <albertcc@tw.ibm.com>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> ---

> Maybe Bahadir could also help to verify if it helps to his "hda lost interrupt" problem.


Hi,

As per the "hda lost interrupt" problem, I tried 2.6.22 and it didn't
make any difference. Then I tried 2.6.21 with pdc202xx_new.c file from
2.6.19 (the working one). I had to only retain
pdcnew_config_drive_xfer_rate() from 2.6.21 to make it compile, and I
still had the same result. I guess this means its a change outside the
driver that breaks it on my platform? I will git-bisect and see.

Thanks,
Bahadir

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

[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

[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 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

[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

[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 ?

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 ?

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

[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

[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

[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 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

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

[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]

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

[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

[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

[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