From owner-freebsd-hackers Fri Jun 2 12:28:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id DFF8537C09A for ; Fri, 2 Jun 2000 12:28:24 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA03790; Fri, 2 Jun 2000 12:31:13 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006021931.MAA03790@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: hackers@FreeBSD.ORG Subject: Re: 4.0 - Isa devices not being probed In-reply-to: Your message of "Fri, 02 Jun 2000 10:10:47 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Fri, 02 Jun 2000 12:31:13 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Typically, a driver may want to order some operations and also not = break > > > post buffering each time a write is performed. It may for example w= ant to > > > order some operations, but not flush all writes immediately. I didn= 't see > > > how to tell bus about that. > > = > > The bus_space_barrier() interface takes the bus tag and handle as = > > arguments, so the ordering operations can make decisions about how th= ey = > > should behave based on what you're operating on. > = > Hmmm... This stuff happens to do the expected work on FreeBSD-alpha, bu= t > the bus_space_barrier() apparent semantic seems more restrictive. What = we > may want is to have some handle on the order a sequence of memory _and_= > mmio operations is actually carried out to the system bus. I think I'm understanding you here; you want to be able to ensure that a = set of eg. mmio-to-bus operations are completed before a following = memory-write operation is performed, in an architecture where write = ordering is not guaranteed? In this case, perhaps the NetBSD wbflush() addon is what actually = addresses your concerns? To be honest, I haven't ever run across a peripheral where this sort of timing would be a concern; I have a hard = time visualising what you'd want this for (but would appreciate being = informed if you have the time). > But the > bus_space_barrier() semantic only seems to care about mmio operations. = (I > have had a look into NetBSD ppc. Here too, bus_space_barrier() does the= > expected work, despite the apparent restrictive semantic of this verb) In the "bus space" way of thinking, all memory operations are mmio, even = if the mapped space is in system memory. > On the other hand, I didn't found the kernel interface for byte orderin= g > operations (think about NetBSD htole32() and friends). We haven't (yet) ported to a non-little-endian architecture. You can = reasonably expect that we will follow the NetBSD folks' lead on this, as = they've had plenty of time to come up with solutions that work. (Unless = you or someone else comes up with violent objections, of course.) > > Just so. The real joy, of course, comes when you're trying to make a= = > > drive behave "correctly" on a wide range of different machines. 8) > = > I actually want it to be a joy, but for now it is a nightmare, unless I= = > decide to do the real work from the device driver. Unfortunately, I > haven't time enough to study all existing architectures and existing > bridges variants. > This let the expected joy not to be about to come. ;-) 8) -- = \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message