Re: [PATCH] Poll-based IDE driver

From: Alan Cox
Date: Wed Oct 08 2003 - 16:51:00 EST


On Mer, 2003-10-08 at 10:43, Srivatsa Vaddagiri wrote:
> 1. Taking control of the drive
> It is possible that the kernel IDE driver was very _actively_
> using the dump drive when my driver takes over. For ex, there
> may be active DMA requests pending with the drive when
> my driver takes control ..

In 2.4 we issue one command at a time in 2.6 we may have several TCQ
commands queued. You may need to test if the drive is busy, wait and if
neccessary reset and recover it. If possible avoid the reset because
that means the drive will need some reconfiguration (see specs)

> Currently all my drive does to take control of the drive
> is to disable drive interrupts (set nIEN bit). It then
> starts issuing PIO WRITE commands to write data to disk.

Make sure you disable interrupts before using nIEN. Not all older
devices honour nIEN so you can get suprises

> Do I need to do anything else in order to take
> control of the drive?
>
> Do I need to explicitly program the drive for PIO transfer
> mode before I start issuing it PIO write commands?

The PIO mode on the controller and drive should have been set correctly
by the base IDE driver at boot time.

> 2. Power Management
> Tackling Sleep state may involve a drive reset followed by
> reinitializing drive parameters which will make my driver
> more complex (as I may have to take care of reset sequence of
> various chipsets separately). For now, I would like my driver
> not supporting the sleep state.

Makes sense. Many drives seem to come out of sleep state themselves
anyway.

> 3. Shutdown sequence
> You mentioned that I need to follow proper shutdown sequence
> when I am done writing to the drive. Apart from
> flushing (if the drive supports it) is there anything
> more to the shutdown sequence?

Flush the cache, and place the drive in a suitable standby/sleep state -
follow the code in ide-disk.c for the way we do it in the main code.

> 4. Relinquishing control of the drive
> Currently all I am doing to give control back to
> the kernel IDE driver is to re-enable the drive
> interrupts (clear nIEN).
>
> Is there anything more I need to be taking care of?

Hard question. I think that providing you mark the drive busy, wait
for the IDE layer to complete any pending commands and restore the state
afterwards it ought to be possible. Would need a lot of thought and more
time than I have right now to think about it since getting it wrong
might lose requests and generate very hard to pin down errors.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/