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

2007-10-14 Thread 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 ? > > > > -ENO

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

2007-10-14 Thread 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

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

2007-08-17 Thread 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 t

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

2007-08-16 Thread 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 ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

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

2007-08-16 Thread 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 p

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

2007-07-16 Thread 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 atta

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

2007-07-11 Thread 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 :00:0e.0: version 0.9 > > usec_elapsed for mdelay(37) [35431] > > start time: [1184112028]s [775333]us > > end time: [1184112028]

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

2007-07-10 Thread Albert Lee
Mikael Pettersson wrote: > > > 2.6.22 + this prints the following on my G3: > > pata_pdc2027x :00:0e.0: version 0.9 > usec_elapsed for mdelay(37) [35431] > start time: [1184112028]s [775333]us > end time: [1184112028]s [810764]us > pata_pdc2027x :00:0e.0: PLL input clock 1691741 kHz

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

2007-07-10 Thread 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

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

2007-07-09 Thread 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 p

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

2007-07-09 Thread 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 Ala