Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jun 2000 14:52:00 +0200 (CEST)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
To:        hackers@FreeBSD.org
Subject:   PATCH: `sym' driver changes for testing.
Message-ID:  <Pine.LNX.4.10.10006041448020.307-100000@linux.local>

next in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10006041448020.307-100000>