Date: Sun, 20 Feb 2000 18:17:29 +0000 (GMT) From: Andrew Gordon <arg@arg1.demon.co.uk> To: Hellmuth Michaelis <hm@kts.org> Cc: Doug Rabson <dfr@nlsystems.com>, current@freebsd.org, freebsd-isdn@freebsd.org Subject: Re: Big ATA problems Message-ID: <Pine.BSF.4.21.0002201751190.20100-100000@server.arg.sj.co.uk> In-Reply-To: <20000220103745.EB14A1F17@bert.kts.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 20 Feb 2000, Hellmuth Michaelis wrote: > > A typical isic hardware has an ISAC and an HSCX chip onboard. The ISAC > chip does the D-channel handling and uses offsets 0-0x2b and 0x30-0x3b, > the HSCX (B-channels) uses offsets 0-0x3b and 0x40-0x73. But in the case of the teles16.3, it does _not_ use offsets 0x00-0x3b in the HSCX or ISAC: the ASIC on the card has 'folded' the address space so that the fifo appears at an address 3 bytes after the last register (0x3e with the current scheme - see tels0163_read_fifo()). The existing driver only uses offsets 0x20-0x3e relative to its assumed base address (and offsets 0x40 upwards are mapped separately). Note that the base address of 0x160 is a figment of the driver's imagination: the card is labelled as occupying 0xd80, and hence occupies 0x180/0x580/0x980 due to ISA address decoding rules. The 0x160 is only a convenience to make the driver's address calculations the same as the other cards - which is no longer necessary now that the driver has been restructured to have sc->readreg/writereg and can do things differently for each type of card. > The card in question allocates 3 portranges for this uses with each 0x40 > bytes in length. > > In case there is is already an IDE controller allocated at 0x170 and a > Teles 16.3 tries to allocate a range of 0x40 at 0x160 it cannot do so. > > So where is the bug ? There is definitely a bug that it doesn't seem to allocate a (larger) portrange at 0xd80 - the output shown in an earlier message in this thread suggested that only a single byte at 0xd80 was allocated. The probe code accesses 0xd80, 0xd81, 0xd82, and testing indicates that it goes up to at least 0xd87, probably in fact all the way to 0xd1f. I am 99% certain that it is also incorrect to protect 0x160-0x17f (etc.). The driver certainly doesn't access registers in these ranges, and simple testing suggests that the card doesn't drive the bus for these regions. Unfortunately, my only 16.3 card is in a machine that is in use, so I can only do non-destructive testing on it. I will be able to test it properly in a couple of weeks when this machine has been retired. > This all looks perfectly reasonable to me with the exception that we > could start argueing about whether it would be reasonable to split the > allocation ranges for the ISAC and to save (if at all possible, there > are some more registers at the end of the HSCX on the card) some bytes > in the HSCX case. This would be wrong - the driver needs to protect all the address space occupied by the card, since it will be driving the bus for all these addresses and so another (PnP) device must not be assigned addresses in the "hole". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0002201751190.20100-100000>