Re: [Geekos-devel] Re: IDE driver details

['Parc' <ne...@ri...>]

On Tue, Jan 29, 2002 at 04:06:58PM -0800, Vishal Soni wrote:
> Hi,
> 
> I need a calibrated delay of approx. 400ns for communicating with IDE
> drives. 
> 
> There are two possible options.
> 
> Use timer interrupts: I can use them if they are not going to be used by
> any other components of the kernel. This also is not a good idea because
> we frequently need to wait for 400ns in IDE -drive communication. This
> will increase the number of interrupts. Probably couple of them each
> time u try to access a sector. 
>  
Give me a little time and I can probably get either an RTC timer or a
8254 secondary timer together.  I believe the most common way is with
the RTC.

> Second is to use loop with NOP's in it and execute it to get
> approximately a 400nsecond delay. 
> For eg. if NOP takes 4 clock cycles and my clock has 100ns duty cycle I
> can get 400ns delay by putting 4 NOP in my delay loop.

NOP gets optimized out by bochs, and some processors may do odd things.
VMWare would also not like it.  Another way to do it might be to watch
the DRAM refresh status.  It runs at 66Mhz, so watch it's flip-flops
for enough time.

> 
> This works fine if we assume all processors have 100ns clock duty
> cycle...but this not the case because different versions of Intel/AMD
> processors have different speeds.
> 
> If you guys have any Ideas regarding this let me know?? I will try to
> look into Linux source reference how they handle such situations. I know
> Linux uses something called BogoMIPS. But I am not sure how it works.

See above.

> 
> Let me know if you guys have some other amazing ideas to handle this
> situation

The least invasive way right now is to use the DRAM refresh.
Look for a nanosleep to appear shortly, since you need it.  I imagine
the controller can handle longer pauses than required, so you could just
sleep(1).  Yeah, it's WAY too long, but if it works...

> 
> Thanks,
> 
> Vishal
> 

No prob

-parc