From owner-freebsd-isdn Mon Dec 14 10:51:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA25437 for freebsd-isdn-outgoing; Mon, 14 Dec 1998 10:51:44 -0800 (PST) (envelope-from owner-freebsd-isdn@FreeBSD.ORG) Received: from linteuto.teuto.de (linteuto.teuto.de [194.77.23.26]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA25432 for ; Mon, 14 Dec 1998 10:51:42 -0800 (PST) (envelope-from martin@rumolt.teuto.de) Received: from rumolt.teuto.de (root@rumolt.teuto.de [212.8.203.81]) by linteuto.teuto.de (8.8.7/8.8.7) with ESMTP id TAA07193; Mon, 14 Dec 1998 19:51:31 +0100 Received: from hwart (hwart.teuto.de [212.8.203.83]) by rumolt.teuto.de (8.8.8/8.8.7) with SMTP id OAA02523; Mon, 14 Dec 1998 14:31:42 +0100 (MET) From: "Martin Husemann" To: "Martin Recktenwald" , "Gerald Heinig" Cc: Subject: RE: ISAC & HSCX questions Date: Mon, 14 Dec 1998 14:31:42 +0100 Message-ID: <000001be2766$164cec40$53cb08d4@hwart.teuto.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-isdn@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Maybe because you can write at the FIFO where you want but it will > alway store the bytes in the order you wrote them? This is a typical hardware designer game: the chip (internaly) has a receive-FIFO and a transmit-FIFO. They are fifos, as the chip always places bytes at one end of the receive fifo and you always read the first-in byte from the other end. Same for the write access to the transmit fifo (only the other way around). Now: to minimize the address decoding part of the chip they overlapped both fifos: all read accesses go to the receive fifo, all write acceses to the transmit fifo (from that point of view the R/W signal is just another address bit). Now for the driver writer: to optimize the access you'll like to use a "string" opcode, like on the i386 "iosb", which does multiple transfers from the same port to a buffer. Whith some luck you can read a full fifo content by one instruction. Unfortunately some architectures don't have io-ports but instead use memory-mapped io. The same architectures often don't have an 'iosb' aequivalent (see the 68000 family). To play the same 'single instruction full fifo fetch' trick there the hardware designers chose to ignore the lower address bits when accessing the fifo: you code a memory block transfer, just like in C "memcpy(dest_buffer, rx_fifo, 32);", which can be done with autoincrement addressing modes on the 68000. Many modern cards use this feature to reduce the size of the mapped io area of the card: they split access to the chipset in two steps: first you write the address of the register you would like to access to an address latch register, then you access one data register. You'll need a minimum of two io-ports (four to eight used on real-world cards) for such a card, which suits well into the ISA-PnP world. And the "iosb" trick still works: just write the fifo address once into the latch, then do "iosb" on the data port. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isdn" in the body of the message