RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-30 Thread Grover, Andrew
I'm not sure what you mean by well-defined. Do you mean, does it have a fixed address? No, it is relocatable. The ACPI driver can find it because the base address is specified in the ACPI tables. After the ACPI driver is loaded the driver could export a pmtimer read function. This is great except

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-30 Thread Grover, Andrew
I'm not sure what you mean by well-defined. Do you mean, does it have a fixed address? No, it is relocatable. The ACPI driver can find it because the base address is specified in the ACPI tables. After the ACPI driver is loaded the driver could export a pmtimer read function. This is great except

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-29 Thread Woller, Thomas
TECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Incorrect mdelay() results on Power Managed Machines x86 > > > I know on ACPI systems you are guaranteed a PM timer running at ~3.57 > Mhz. > > Could udelay use that, or are there other ti

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-29 Thread Woller, Thomas
]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Incorrect mdelay() results on Power Managed Machines x86 I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz. Could udelay use that, or are there other timers that are better (maybe without the ACPI dependency

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Alan Cox
> I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz. > Could udelay use that, or are there other timers that are better (maybe > without the ACPI dependency)? We could use that if ACPI was present. It might be worth exploring. Is this PM timer well defined for accesses

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Grover, Andrew
Pavel Machek [mailto:[EMAIL PROTECTED]] > Sent: Sunday, March 25, 2001 4:07 PM > To: Alan Cox > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: Incorrect mdelay() results on Power Managed Machines x86 > > > Hi! > > > > On the Think

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Pavel Machek
Hi! > > During resume the IBM thinkpad with the cs46xx driver needs > > to delay 700 > > milleseconds, so if the machine is booted up on battery power, then to > > ensure that the delay is long enough, then a value of 3000 > > milleseconds is > > must be programmed into the driver (3

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Pavel Machek
Hi! > > On the ThinkPad 600E (at least), we get a Power Status Change APM event. > > Any reason we couldn't recalibrate the bogomips on a power status change, > at least for laptops we know appear to need it (I can make the DMI code look > for matches there..) Notice that this is not 100%

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Pavel Machek
Hi! During resume the IBM thinkpad with the cs46xx driver needs to delay 700 milleseconds, so if the machine is booted up on battery power, then to ensure that the delay is long enough, then a value of 3000 milleseconds is must be programmed into the driver (3 seconds!). all the

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Pavel Machek
Hi! On the ThinkPad 600E (at least), we get a Power Status Change APM event. Any reason we couldn't recalibrate the bogomips on a power status change, at least for laptops we know appear to need it (I can make the DMI code look for matches there..) Notice that this is not 100% solution.

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Grover, Andrew
Machek [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 25, 2001 4:07 PM To: Alan Cox Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Incorrect mdelay() results on Power Managed Machines x86 Hi! On the ThinkPad 600E (at least), we get a Power Status Change APM

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-28 Thread Alan Cox
I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz. Could udelay use that, or are there other timers that are better (maybe without the ACPI dependency)? We could use that if ACPI was present. It might be worth exploring. Is this PM timer well defined for accesses ? -

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread sfr
From: Alan Cox <[EMAIL PROTECTED]> > > > On the ThinkPad 600E (at least), we get a Power Status Change APM event. > > Any reason we couldn't recalibrate the bogomips on a power status change, > at least for laptops we know appear to need it (I can make the DMI code look > for matches there..)

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Woller, Thomas
lay is working when booted up on battery the patch may not be needed. > -Original Message- > From: Pavel Machek [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, March 22, 2001 5:29 PM > To: Woller, Thomas; '[EMAIL PROTECTED]' > Subject: Re: Incorrect mdelay() results on Powe

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Pavel Machek
Hi! > Problem: Certain Laptops (IBM Thinkpads is where i see the issue) reduce the > CPU frequency based upon whether the unit is on battery power or direct > power. When the Linux kernel boots up, then the cpu_khz (time.c) This is issue with my toshiba sattelite, too. I even had a patch to

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Alan Cox
> On the ThinkPad 600E (at least), we get a Power Status Change APM event. Any reason we couldn't recalibrate the bogomips on a power status change, at least for laptops we know appear to need it (I can make the DMI code look for matches there..) - To unsubscribe from this list: send the line

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Alan Cox
> If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X. > That doesn't have Speedstep. The speed changes are done by some circuitry > in the laptop. I can try to find out more if this would help. > The newer machines are using Speedstep. Ok Any info on how the laptop wants to

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Alan Cox
If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X. That doesn't have Speedstep. The speed changes are done by some circuitry in the laptop. I can try to find out more if this would help. The newer machines are using Speedstep. Ok Any info on how the laptop wants to

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Alan Cox
On the ThinkPad 600E (at least), we get a Power Status Change APM event. Any reason we couldn't recalibrate the bogomips on a power status change, at least for laptops we know appear to need it (I can make the DMI code look for matches there..) - To unsubscribe from this list: send the line

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread Pavel Machek
Hi! Problem: Certain Laptops (IBM Thinkpads is where i see the issue) reduce the CPU frequency based upon whether the unit is on battery power or direct power. When the Linux kernel boots up, then the cpu_khz (time.c) This is issue with my toshiba sattelite, too. I even had a patch to

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-23 Thread sfr
From: Alan Cox [EMAIL PROTECTED] On the ThinkPad 600E (at least), we get a Power Status Change APM event. Any reason we couldn't recalibrate the bogomips on a power status change, at least for laptops we know appear to need it (I can make the DMI code look for matches there..) No reason

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Dave Zarzycki
On Thu, 22 Mar 2001, Alan Cox wrote: > This is commonly done using the speedstep feature on intel cpus. Speedstep > can generate events so the OS knows about it but Intel are not telling > people about how this works. <...snip...> > We certainly could recalibrate the clock if we could get events

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread sfr
> Boot with the 'notsc' option is one approach. We certainly could recalibrate > the clock if we could get events out of ACPI, APM or some other source. Maybe > someone at IBM knows something on the thinkpad front here. If there is for > example an additional apm event or irq we can enable for

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Tim Wright
If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X. That doesn't have Speedstep. The speed changes are done by some circuitry in the laptop. I can try to find out more if this would help. The newer machines are using Speedstep. Tim On Thu, Mar 22, 2001 at 11:37:43PM +,

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Alan Cox
> thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC > enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time ... > boot and stay on battery power exclusively. did anyone else expect this > behaviour? Errmm no.. - To unsubscribe from this list:

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Woller, Thomas
> > I wonder if there is a way to modify mdelay to use a kernel timer if > > interval > 10msec? I am not familiar with this section of the kernel, > but I > > do know that Microsoft's similar function KeStallExecutionProcessor is > not > > recommended for more than 50 *micro*seconds. >

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Alan Cox
> I wonder if there is a way to modify mdelay to use a kernel timer if > interval > 10msec? I am not familiar with this section of the kernel, but I > do know that Microsoft's similar function KeStallExecutionProcessor is not > recommended for more than 50 *micro*seconds. Basically the same kind

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Grover, Andrew
> During resume the IBM thinkpad with the cs46xx driver needs > to delay 700 > milleseconds, so if the machine is booted up on battery power, then to > ensure that the delay is long enough, then a value of 3000 > milleseconds is > must be programmed into the driver (3 seconds!). all the >

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Alan Cox
> Problem: Certain Laptops (IBM Thinkpads is where i see the issue) reduce the > CPU frequency based upon whether the unit is on battery power or direct > power. When the Linux kernel boots up, then the cpu_khz (time.c) value is This is commonly done using the speedstep feature on intel cpus.

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Alan Cox
Problem: Certain Laptops (IBM Thinkpads is where i see the issue) reduce the CPU frequency based upon whether the unit is on battery power or direct power. When the Linux kernel boots up, then the cpu_khz (time.c) value is This is commonly done using the speedstep feature on intel cpus.

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Grover, Andrew
During resume the IBM thinkpad with the cs46xx driver needs to delay 700 milleseconds, so if the machine is booted up on battery power, then to ensure that the delay is long enough, then a value of 3000 milleseconds is must be programmed into the driver (3 seconds!). all the mdelay and

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Alan Cox
I wonder if there is a way to modify mdelay to use a kernel timer if interval 10msec? I am not familiar with this section of the kernel, but I do know that Microsoft's similar function KeStallExecutionProcessor is not recommended for more than 50 *micro*seconds. Basically the same kind of

RE: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Woller, Thomas
I wonder if there is a way to modify mdelay to use a kernel timer if interval 10msec? I am not familiar with this section of the kernel, but I do know that Microsoft's similar function KeStallExecutionProcessor is not recommended for more than 50 *micro*seconds. Basically

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Alan Cox
thanks, i just tested the "notsc" option (.config has CONFIG_X86_TSC enabled=y, but CONFIG_M586TSC is not enabled.. if that's ok), but this time ... boot and stay on battery power exclusively. did anyone else expect this behaviour? Errmm no.. - To unsubscribe from this list: send

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Tim Wright
If it's a 500MHz Thinkpad, then I'm guessing it's something like a 600X. That doesn't have Speedstep. The speed changes are done by some circuitry in the laptop. I can try to find out more if this would help. The newer machines are using Speedstep. Tim On Thu, Mar 22, 2001 at 11:37:43PM +,

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread sfr
Boot with the 'notsc' option is one approach. We certainly could recalibrate the clock if we could get events out of ACPI, APM or some other source. Maybe someone at IBM knows something on the thinkpad front here. If there is for example an additional apm event or irq we can enable for the

Re: Incorrect mdelay() results on Power Managed Machines x86

2001-03-22 Thread Dave Zarzycki
On Thu, 22 Mar 2001, Alan Cox wrote: This is commonly done using the speedstep feature on intel cpus. Speedstep can generate events so the OS knows about it but Intel are not telling people about how this works. ...snip... We certainly could recalibrate the clock if we could get events out