From owner-freebsd-hackers Sun Jun 4 6:15:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id DF15C37B811 for ; Sun, 4 Jun 2000 06:15:20 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-107-212.villette.club-internet.fr (ppp-107-212.villette.club-internet.fr [194.158.107.212]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA25942 for ; Sun, 4 Jun 2000 15:12:07 +0200 (MET DST) Date: Sun, 4 Jun 2000 14:52:00 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: hackers@FreeBSD.org Subject: PATCH: `sym' driver changes for testing. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have made available the following `sym' driver patch for testing: http://people.freebsd.org/~groudier/sym-1.6.0-20000604.diffs This patch is against driver version in -current. Changes are pretty=20 trivial and mostly nil-potent for ia32, but it seemed to me they may=20 need some testings, especially on Alpha, (and comments if any are=20 welcome) prior to committing them: 1) Use `bus space' for IO/MMIO instead of legacy IO/MMIO methods. 2) Add preliminary support for big endian. For now, a couple of byte order primitives are defined in the=20 driver code. 3) Add 2 macros OUTL_DSP and OUTONB_STD that perform a memory barrier=20 prior to the IO, since we want the chip to have a consistent view=20 of driver internal data structure each time we restart it. This ensure proper ordering and makes driver code simpler. 4) Add barrier definitions we should need for ia64 and powerpc. These=20 definitions will go away when the kernel will provide them. These additions and changes are intended to help kernel ports once their=20 boot stage will be reached ;-). They also clarify ordering concerns in the driver. The barriers used by=20 the driver are slightly paranoid and in most places only write (store)=20 barriers should be enough. This will be refined when real testing with=20 systems implementing kind of weak ordering will be possible. Status: - All places where the driver has to restart the SCRIPTS processor=20 by writing the DSP or setting the STD bit in dcntl are not time=20 critical and so paranoid barriers will not affect performances. - The driver performs explicit ordering from the C code in 2 places: * To queue the job -> 2 barriers that could be `write memory barriers'. * To ensure INTFLY clear has been seen by chip prior to scanning=20 the done queue, a dummy read is peformed under interrupt. Not perfect but just cool. :) G=E9rard. PS: This posting went to -hackers and not -scsi since the patch does not=20 address scsi concerns. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message