Subject: Re: Support for polled IDE controllers
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Ben Harris <bjh21@netbsd.org>
List: tech-kern
Date: 06/11/2001 22:51:46
On Mon, 11 Jun 2001, Manuel Bouyer wrote:
> On Sat, Jun 09, 2001 at 01:38:06PM +0100, Ben Harris wrote:
> > I've got a couple of IDE controllers that don't have their interrupt lines
> > wired up, and I'd like the NetBSD wdc driver to handle them. I've
> > arranged this by adding a new capability, WDC_CAPABILITY_NOIRQ, and having
> > the three functions that can queue transfers (wdc_ata_bio(),
> > wdc_exec_command() and wdc_atapi_scsipi_request()) check that and mark all
> > transfers as polled if it's set.
[...]
> Hum I'm not sure how to make this work properly, especially with the
> new scsipi code for ATAPI (you've already found some problems with this).
>
> Maybe the best way would be to do the pool from a callout, or in a specific
> kernel thread ?
Ew. That seems significantly more painful from my point-of-view. I was
hoping to be able to take advantage of the infrastucture we already have
for handling polled transfers, rather than having to invent a whole new
mechanism. It might have the advantage that the CPU could do other stuff
in between polling the drive, but I'm not sure that's a big enough gain
for the amount of work.
> Otherwise we need a way to pass this capability up to wd or scsipi, so that
> the polling flag can be set from the beggining. Setting it in the
> middle of the xfer won't work.
Well, my patch effectively already passes it up to wd, since it has to
know to mark its xfers as polled. The ATAPI side is trickier, but there
are already polled SCSI controllers (e.g. ncr5380 with
NCR5380_FORCE_POLL), so I don't think pushing knowledge of polling
adaptors up to scspi_execute_xs (where it looks like it belongs) would be
terribly inappropriate. I'll see if I can work out how to do it.
--
Ben Harris <bjh21@netbsd.org>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>