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

[Mikael Pettersson]

On Thu, 21 Jun 2007 12:47:30 +0100, "Bahadir Balban" <bahadir.balban@gmail.com> 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 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).

Try kernel 2.6.21 or newer and the libata driver for this card
instead (pata_pdc2027x). I'm using that in a PowerMac whose
firmware doesn't initialise the card at boot, and it works for me.

What kind of ARM board is this?

/Mikael

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