Date: Sun, 30 Nov 1997 00:21:33 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: John Kelly <jak@cetlink.net> Cc: Bruce Evans <bde@zeta.org.au>, hackers@FreeBSD.ORG Subject: Re: 650 UART, SIO driver, 8259 PIC Message-ID: <19971130002133.00410@hydrogen.nike.efn.org> In-Reply-To: <348095b5.441871@mail.cetlink.net>; from John Kelly on Sat, Nov 29, 1997 at 11:01:21PM %2B0000 References: <199711292017.HAA16179@godzilla.zeta.org.au> <348095b5.441871@mail.cetlink.net>
next in thread | previous in thread | raw e-mail | index | archive | help
John Kelly scribbled this message on Nov 29: > I now see the value of the UNIX status register (which SIO ignores) on > my shared interrupt multiport board. The board maker did not even > document how it works, but I would guess that for each UART it has a > bit which follows the state of the UART's INT output. I may poke > around on the board to see if that's true. You could simply read the > status register to see if all eight were low and then safely exit the > ISR. And you could also avoid checking every UART every time you > enter the ISR. actually.. I have a couple AST/4 compatible boards that have 4 16550's (actually clones, and one set is even 16650's), and they have a documented status register that you can read to see if there are any pending interrupts... in the documentation they tell you that this is the way to service interrupts from the board... I've thought about upgrading sio so that it would understand the existance of it, but there were a number of problems... the status register is stored in the scratch register of the fourth port of the board... also, on the AST/4 the port to write to, to clear ALL the interrupts on the board is defined by the IRQ that the board is on (the boards that I have will ALWAYS clear no matter what port you write to, but you need to make sure it's compatible)... then you have to decide you to tell each port what it's number in the status register... you don't want to have to force some aweful hack like requiring the port number to be congruent to device number mod 4... that would just be terrible (though most people do something similar).. then to make matters worse... BOTH boards could possible be on the same interrupt, and you have to check both port 4's scratch registers to see who generated the port... after all this came to light, I stopped work on it as there really was no easy way to describe the different configurations in the flags of the device... and this was even before Bruce used another bit to store what one is the serial console... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971130002133.00410>