On Sat, Mar 11, 2000 at 02:32:10PM +0000, Roger Brooks wrote:
> Last night I got the driver working with both channels of the HPT366.
> After Manuel's comments, I started lookign very closely at the interrupt
> handler, and realised that I'd bogged the code to check if the interrupt
> belongs to that channel (I was reading a register at the right offset,
> but in configuration space, not I/O space :%).

Good news !!!

> 
> I'll do a bit more testing, and should be able to post a new version of the
> patch in a day or so.  However, I'd like advice on another point.  Manuel's
> comments about using the Abit Hot-Rod (the PCI card version of the HPT366)
> in a non-i386 machine set me thinking.  In the i386, the Highpoint BIOS
> sets up a 32 bit "tuning register" with a magic number which depends on
> disk I/O mode and PCI bus speed.  As I don't have the HPT366 docs, I don't
> know if they describe how to generate this magic number.  However, the driver
> prints out the value at boot time, so you could obtain the magic numbers
> for a particular PCI bus speed by starting with a UDMA mode 4 drive and
> reducing the I/O mode through all the UDMA, DMA and PIO modes in the
> Highpoint BIOS, with each reboot giving you the next magic number.
> 
> The Linux driver which I have been working from has three such tables,
> for 25, 33 and 40MHz bus clock.  The FreeBSD driver has something similar.
> Although I've reproduced the code, I think it's a bit questionable because
> in order to determine the bus clock, it looks at the magic number already
> written to the register by the BIOS.  The only point of this code is that
> if you have used a flags value on the "wdN" config file line, it will
> retune the chip to your preferred I/O mode.

In NetBSD this is also used for the 'downgrade' code: when the driver
detects the actual mode is not working rigth (too many CRC errors,
timeouts, etc ...) it will try a lower mode.

> 
> Now for the problem.  If you don't have the BIOS to set the chip up, how can
> the driver find the bus clock speed?  I can't find anything in the PCI code
> which seems to do this.  How many machines have PCI bus clocks which aren't
> 33 MHz?  How many of those are something other than 25 or 40 MHz?  I suppose
> I could get the bus clock from a config file option, but that seems a bit
> tacky, so say the least.

I've got some though about this for the other IDE chipsets too (also note
you forgot a valid PCI speed: 30Mhz, and a unsupported one: 37.5Mhz):
There's no easy way for the kernel to know what the pci bus speed is.
I've been looking at several PCI chipsets docs and not all of them
provide this info. Maybe the BIOS could tell us, but I'm not sure of this.
So I tried to do the work without this info.
40Mhz is an illegal value, the PCI specs only allows 33Mhz or lower,
so does most PCI chipsets and most PCI boards (some video boards have problems
at 37Mhz, I ran into this). My Asus socket 7 mainboard allows speeds higther
than 33Mhz, but the Intel chipset used doesn't support it, and it's
explicitely stated in the mainboard's docs that this is not a recommended
config.  Also it seems that in the non-i386 world the only PCI bus speed
encountered is 33Mhz; this seems to also be true for modern motherboards/CPUs
(unless you overclock, but then it's at your own risk).
Now, if we set up timings for 33Mhz and the PCI bus is running at a lower
value, we'll just use a lower timing than expected on the IDE bus. This should
be harmless.  If the PCI bus is running at higther speed than 33Mhz then the
IDE timing could be higther than it should (it may also be still in allowed
range, it depends on the chipset and the mode used), but most drives should
be able to deal with it. You're just jumping into the funs of overclocking.

So, to be consistent with the other chipset supported by pciide assume a
PCI bus speed of 33Mhz.

--
Manuel Bouyer <bouyer@antioche.eu.org>
--