Eric W. Biederman wrote:

>ollie <[EMAIL PROTECTED]> writes:
>
>>P.S. Actually, we are doing almost the same as what you described.
>>
>
>
>There are some similiarities and the basic principles are the same,
>but the techniques are noticeably different.  
>
>Your maximum wait appears to be 26 seconds instead of 30.
>0xFFFF * 400us.
>
I think it is the neceressary evil. You have to poll ther register and 
set some time out.

>
>Also I'm not at all a fan of inb_p/outb_p.  I get the feeling
>sometimes there is deep magic involved, in the pause length selected.
>Or even if the pause is what is really desired.   At least so far I
>haven't heard a clear explination of what the gain of outputing a
>value to another port is.
>
>I've attached my code so you can compare.
>
>Just skimming it I am certain your ide code won't detect cd's or
>any other packet devices.  Because after a reset they are required
>to clear bits 6,5,4,3,2 and 0 after reset in the status register.
>

Yea, I did not deal with this device. We are not to the point to boot 
from CD.

>
>Polling the sector count register until it takes a stable value 
>(implying that BSY has finally cleared) is sane, but unless your
>objective is to support slave devices without a master it is much
>more sane to simply poll BSY in the status register.
>
>
>The IDE spec says while BSY is set all other values are undefined.
>
>Running around and poking into other registers when you haven't read
>BSY to make certain it is clear gives me the creeps.
>

The reason I am writing/reading on sector count register is as 
mysterious to me. For some reason, all the
IDE controller I tried does not report BSY line correctly during 
power-up i.e. they are not BUSY. So
polling BSY bit along is no enough. I have to write and then read back 
some controller register and wait
it to  be stabilized. I think the probing/sinp-up procedure should have 
two phases:

    1. wait the internal logic of IDE controller to come up. I think we 
are too fast that the controller
        may not be ready in its power cycle or internal firmware execution.

    2. polling the Drive media to spin up.

How do you think ??

>
>Beyond that it looks like you have put together some good
>infrastructure.  
>

BTW, there are some strange code like write to port 0xeb and RECALIBATE 
command
in the UTC ide code. Should we remove them or they are actually doing 
something important ??

Ollie


Reply via email to