> Hi!
Hey! Hmm. Odd, this email never got to me directly, instead I found it
through lkml. Hopefully my mail isn't bouncing somewhere...
> > +static void delay_pit(unsigned long loops)
> > +{
> > + int d0;
> > + __asm__ __volatile__(
> > + "\tjmp 1f\n"
> > + ".align 16\n"
> > + "1:\tjmp 2f\n"
> > + ".align 16\n"
> > + "2:\tdecl %0\n\tjns 2b"
> > + :"=&a" (d0)
> > + :"0" (loops));
> > +}
> > +
>
> But... this is not using pit to do the delay, right? It is sensitive
> to CPU clock changes, pit-delay should not be.
You're right, basically I took the previous __loop_delay() and
__rtsc_delay() and moved them to delay_pit() and delay_tsc(),
respectively. I guess the naming is somewhat confusing, but since this
was meant as just a cleanup, I'm trying to use the same code in the same
conditions.(ie: when using the PIT time-source, use the loop delay. when
using the TSC time-source, use the TSC delay). A changing the name or a
comment explaining it would def clear that up.
You do bring up an interesting idea: actually using the PIT to do
__delay. I think its possible, but not really worth it, as the PIT is
such a nasty bit of hardware to deal with. I'd guess that just reading
the PIT would likely delay for more time then what was actually
requested.
Thanks for the feedback!
-john
Hi!
> Hey! Hmm. Odd, this email never got to me directly, instead I found it
> through lkml. Hopefully my mail isn't bouncing somewhere...
ibm had some mail problems --- nasty storm of bounces. I don'tknow if
it is related.
>
>
> > > +static void delay_pit(unsigned long loops)
> > > +{
> > > + int d0;
> > > + __asm__ __volatile__(
> > > + "\tjmp 1f\n"
> > > + ".align 16\n"
> > > + "1:\tjmp 2f\n"
> > > + ".align 16\n"
> > > + "2:\tdecl %0\n\tjns 2b"
> > > + :"=&a" (d0)
> > > + :"0" (loops));
> > > +}
> > > +
> >
> > But... this is not using pit to do the delay, right? It is sensitive
> > to CPU clock changes, pit-delay should not be.
>
> You're right, basically I took the previous __loop_delay() and
> __rtsc_delay() and moved them to delay_pit() and delay_tsc(),
> respectively. I guess the naming is somewhat confusing, but since this
> was meant as just a cleanup, I'm trying to use the same code in the same
> conditions.(ie: when using the PIT time-source, use the loop delay. when
> using the TSC time-source, use the TSC delay). A changing the name or a
> comment explaining it would def clear that up.
>
> You do bring up an interesting idea: actually using the PIT to do
> __delay. I think its possible, but not really worth it, as the PIT is
> such a nasty bit of hardware to deal with. I'd guess that just reading
> the PIT would likely delay for more time then what was actually
> requested.
Well, loop_delay() was big (fatal!) problem -- it can actaully wait
for *less* time than told to. That happens if notebook boots during
"battery low" and than goes to AC power. Thinkpad 560X is example of
such behaviour. Slow (but working!) PIT seems to be only option on
such machine.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Sat, 2003-01-18 at 05:54, Pavel Machek wrote:
> Well, loop_delay() was big (fatal!) problem -- it can actaully wait
> for *less* time than told to. That happens if notebook boots during
> "battery low" and than goes to AC power. Thinkpad 560X is example of
> such behaviour. Slow (but working!) PIT seems to be only option on
> such machine.
I need to look more at the cpu_freq code, but I suspect it could it help
solve or lessen the problem (if we can detect the event on those older
systems). Regardless, you make a good point, so if I get the time I'll
look into a real PIT based delay.
Thanks for the feeback.
-john
Hi!
> > Well, loop_delay() was big (fatal!) problem -- it can actaully wait
> > for *less* time than told to. That happens if notebook boots during
> > "battery low" and than goes to AC power. Thinkpad 560X is example of
> > such behaviour. Slow (but working!) PIT seems to be only option on
> > such machine.
>
> I need to look more at the cpu_freq code, but I suspect it could it help
> solve or lessen the problem (if we can detect the event on those
> > older
> systems). Regardless, you make a good point, so if I get the time
> > I'll
It is possible to lessen the problem by measuring speed and
recalibrating if it changes, but due to delay between measuring and
recalibrating it is still not 100% reliable.
> look into a real PIT based delay.
>
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.