From owner-freebsd-new-bus Mon Oct 2 22:59:26 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 9A57537B502 for ; Mon, 2 Oct 2000 22:59:22 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id BAA70383 for ; Tue, 3 Oct 2000 01:59:21 -0400 (EDT) Date: Tue, 3 Oct 2000 01:59:21 -0400 (EDT) From: "Matthew N. Dodd" To: new-bus@FreeBSD.ORG Subject: bus_generic_{get,set}_resource() functions. Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-729685027-970552761=:1566" Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-729685027-970552761=:1566 Content-Type: TEXT/PLAIN; charset=US-ASCII Find attached for comment and review code implementing bus_generic_{get,set}_resource() functions for use by bus drivers that make use of the 'struct resource_list' method of tracking resources. A new BUS METHOD 'BUS_GET_RESOURCE_LIST' is added which allows a bus to retreive the resource list of a child without having to know anything about how/where it is stored. This allows us to reduce code duplication a fair bit. Likely we can create bus_generic_{alloc,release}_resource() functions for the same benefit. Comments? -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | --0-729685027-970552761=:1566 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="rsrc_generic.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="rsrc_generic.diff" SW5kZXg6IGtlcm4vc3Vicl9idXMuYw0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9jdnMvc3JjL3N5cy9rZXJuL3N1YnJfYnVzLmMsdg0K cmV0cmlldmluZyByZXZpc2lvbiAxLjgwDQpkaWZmIC11IC1yMS44MCBzdWJy X2J1cy5jDQotLS0ga2Vybi9zdWJyX2J1cy5jCTIwMDAvMDkvMTcgMjM6NTc6 NTIJMS44MA0KKysrIGtlcm4vc3Vicl9idXMuYwkyMDAwLzA5LzE5IDA1OjAz OjI5DQpAQCAtMTk2NCw2ICsxOTcwLDEzIEBADQogICAgIHJldHVybiBFTk9F TlQ7DQogfQ0KIA0KK2ludA0KK2J1c19nZW5lcmljX2dldF9yZXNvdXJjZV9s aXN0IChkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkLA0KKwkJCSAgICAg ICBzdHJ1Y3QgcmVzb3VyY2VfbGlzdCAqcmwpDQorew0KKwlyZXR1cm4gRU5P RU5UOw0KK30NCisNCiB2b2lkDQogYnVzX2dlbmVyaWNfZHJpdmVyX2FkZGVk KGRldmljZV90IGRldiwgZHJpdmVyX3QgKmRyaXZlcikNCiB7DQpAQCAtMjA0 Niw2ICsyMDU5LDU5IEBADQogCQkJCQkJcikpOw0KIAllbHNlDQogCQlyZXR1 cm4gKEVJTlZBTCk7DQorfQ0KKw0KK2ludA0KK2J1c19nZW5lcmljX2dldF9y ZXNvdXJjZSAoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5 cGUsIGludCByaWQsDQorCQkJICB1X2xvbmcgKnN0YXJ0cCwgdV9sb25nICpj b3VudHApDQorew0KKwlzdHJ1Y3QgcmVzb3VyY2VfbGlzdCAqCQlybCA9IE5V TEw7DQorCXN0cnVjdCByZXNvdXJjZV9saXN0X2VudHJ5ICoJcmxlID0gTlVM TDsNCisJaW50CQkJCXJldHZhbCA9IDA7DQorDQorCXJldHZhbCA9IEJVU19H RVRfUkVTT1VSQ0VfTElTVChkZXYsIGNoaWxkLCBybCk7DQorCWlmIChyZXR2 YWwpDQorCQlyZXR1cm4gKHJldHZhbCk7DQorDQorCXJsZSA9IHJlc291cmNl X2xpc3RfZmluZChybCwgdHlwZSwgcmlkKTsNCisJaWYgKCFybGUpIA0KKwkJ cmV0dXJuIEVOT0VOVDsNCisNCisJKnN0YXJ0cCA9IHJsZS0+c3RhcnQ7DQor CSpjb3VudHAgPSBybGUtPmNvdW50Ow0KKw0KKwlyZXR1cm4gKDApOw0KK30N CisNCitpbnQNCitidXNfZ2VuZXJpY19zZXRfcmVzb3VyY2UgKGRldmljZV90 IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLA0KKwkJ CSAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgY291bnQpDQorew0KKwlzdHJ1Y3Qg cmVzb3VyY2VfbGlzdCAqCQlybCA9IE5VTEw7DQorCWludAkJCQlyZXR2YWwg PSAwOw0KKw0KKwlyZXR2YWwgPSBCVVNfR0VUX1JFU09VUkNFX0xJU1QoZGV2 LCBjaGlsZCwgcmwpOw0KKwlpZiAocmV0dmFsKQ0KKwkJcmV0dXJuIChyZXR2 YWwpOw0KKw0KKwlyZXNvdXJjZV9saXN0X2FkZChybCwgdHlwZSwgcmlkLCBz dGFydCwgKHN0YXJ0ICsgY291bnQgLSAxKSwgY291bnQpOw0KKw0KKwlyZXR1 cm4gKDApOw0KK30NCisNCit2b2lkDQorYnVzX2dlbmVyaWNfZGVsZXRlX3Jl c291cmNlIChkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCBpbnQgdHlw ZSwgaW50IHJpZCkNCit7DQorCXN0cnVjdCByZXNvdXJjZV9saXN0ICoJCXJs ID0gTlVMTDsNCisJaW50CQkJCXJldHZhbCA9IDA7DQorDQorCXJldHZhbCA9 IEJVU19HRVRfUkVTT1VSQ0VfTElTVChkZXYsIGNoaWxkLCBybCk7DQorCWlm IChyZXR2YWwpDQorCQlyZXR1cm47DQorDQorCXJlc291cmNlX2xpc3RfZGVs ZXRlKHJsLCB0eXBlLCByaWQpOw0KKw0KKwlyZXR1cm47DQogfQ0KIA0KIC8q DQpJbmRleDoga2Vybi9idXNfaWYubQ0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KUkNTIGZpbGU6IC9jdnMvc3JjL3N5cy9rZXJuL2J1c19pZi5tLHYNCnJl dHJpZXZpbmcgcmV2aXNpb24gMS4xNw0KZGlmZiAtdSAtcjEuMTcgYnVzX2lm Lm0NCi0tLSBrZXJuL2J1c19pZi5tCTIwMDAvMDQvMDggMTQ6MTc6MDkJMS4x Nw0KKysrIGtlcm4vYnVzX2lmLm0JMjAwMC8wOC8yNCAwOToyNDoxNQ0KQEAg LTIzNiwzICsyMzYsMTIgQEANCiAJaW50CQl0eXBlOw0KIAlpbnQJCXJpZDsN CiB9Ow0KKw0KKyMNCisjIFJldHVybiBhIHN0cnVjdCByZXNvdXJjZV9saXN0 Lg0KKyMNCitNRVRIT0QgaW50IGdldF9yZXNvdXJjZV9saXN0IHsNCisJZGV2 aWNlX3QJZGV2Ow0KKwlkZXZpY2VfdAljaGlsZDsNCisJc3RydWN0IHJlc291 cmNlX2xpc3QgKnJsOw0KK30gREVGQVVMVCBidXNfZ2VuZXJpY19nZXRfcmVz b3VyY2VfbGlzdDsNCkluZGV4OiBzeXMvYnVzLmgNCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NClJDUyBmaWxlOiAvY3ZzL3NyYy9zeXMvc3lzL2J1cy5oLHYN CnJldHJpZXZpbmcgcmV2aXNpb24gMS4zNw0KZGlmZiAtdSAtcjEuMzcgYnVz LmgNCi0tLSBzeXMvYnVzLmgJMjAwMC8wOS8wNyAwMTozMjo1OQkxLjM3DQor Kysgc3lzL2J1cy5oCTIwMDAvMDkvMDcgMjI6MzA6MDUNCkBAIC0xNzcsOCAr MTc3LDExIEBADQogaW50CWJ1c19nZW5lcmljX2F0dGFjaChkZXZpY2VfdCBk ZXYpOw0KIGludAlidXNfZ2VuZXJpY19kZWFjdGl2YXRlX3Jlc291cmNlKGRl dmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLA0KIAkJCQkJ aW50IHJpZCwgc3RydWN0IHJlc291cmNlICpyKTsNCit2b2lkCWJ1c19nZW5l cmljX2RlbGV0ZV9yZXNvdXJjZSAoZGV2aWNlX3QsIGRldmljZV90LCBpbnQs IGludCk7DQogaW50CWJ1c19nZW5lcmljX2RldGFjaChkZXZpY2VfdCBkZXYp Ow0KIHZvaWQJYnVzX2dlbmVyaWNfZHJpdmVyX2FkZGVkKGRldmljZV90IGRl diwgZHJpdmVyX3QgKmRyaXZlcik7DQoraW50CWJ1c19nZW5lcmljX2dldF9y ZXNvdXJjZV9saXN0IChkZXZpY2VfdCwgZGV2aWNlX3QsIHN0cnVjdCByZXNv dXJjZV9saXN0ICopOw0KK2ludAlidXNfZ2VuZXJpY19nZXRfcmVzb3VyY2Ug KGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBpbnQsIHVfbG9uZyAqLCB1X2xv bmcgKik7DQogaW50CWJ1c19wcmludF9jaGlsZF9oZWFkZXIoZGV2aWNlX3Qg ZGV2LCBkZXZpY2VfdCBjaGlsZCk7DQogaW50CWJ1c19wcmludF9jaGlsZF9m b290ZXIoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCk7DQogaW50CWJ1 c19nZW5lcmljX3ByaW50X2NoaWxkKGRldmljZV90IGRldiwgZGV2aWNlX3Qg Y2hpbGQpOw0KQEAgLTE5MSw2ICsxOTQsNyBAQA0KIGludAlidXNfZ2VuZXJp Y19zZXR1cF9pbnRyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsDQog CQkJICAgICAgIHN0cnVjdCByZXNvdXJjZSAqaXJxLCBpbnQgZmxhZ3MsDQog CQkJICAgICAgIGRyaXZlcl9pbnRyX3QgKmludHIsIHZvaWQgKmFyZywgdm9p ZCAqKmNvb2tpZXApOw0KK2ludAlidXNfZ2VuZXJpY19zZXRfcmVzb3VyY2Ug KGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBpbnQsIHVfbG9uZywgdV9sb25n KTsNCiBpbnQJYnVzX2dlbmVyaWNfc2h1dGRvd24oZGV2aWNlX3QgZGV2KTsN CiBpbnQJYnVzX2dlbmVyaWNfc3VzcGVuZChkZXZpY2VfdCBkZXYpOw0KIGlu dAlidXNfZ2VuZXJpY190ZWFyZG93bl9pbnRyKGRldmljZV90IGRldiwgZGV2 aWNlX3QgY2hpbGQsDQo= --0-729685027-970552761=:1566-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Tue Oct 3 1:34: 4 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from mail.rdc1.va.home.com (ha1.rdc1.va.home.com [24.2.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 8C26637B502; Tue, 3 Oct 2000 01:34:00 -0700 (PDT) Received: from laptop.baldwin.cx ([24.6.244.187]) by mail.rdc1.va.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001003083358.NKOO26082.mail.rdc1.va.home.com@laptop.baldwin.cx>; Tue, 3 Oct 2000 01:33:58 -0700 Content-Length: 3917 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 03 Oct 2000 01:34:02 -0700 (PDT) From: John Baldwin To: new-bus@FreeBSD.org Subject: Generic memory barrier helper functions Cc: msmith@FreeBSD.org Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After talking with Mike, I whipped up some quick and dirty helper functions for a MI memory barrier API. Basically, you have the following four functions: barrier_acquire() - a read barrier barrier_release() - a write barrier barrier_fence() - a read/write barrier barrier_flush() - a barrier that flushes the CPU's cache I have a simple patch to implement all of these on both x86 and alpha with the exception of barrier_flush() on the alpha at http://www.FreeBSD.org/~jhb/patches/barrier.patch and inlined here: Index: alpha/include/bus.h =================================================================== RCS file: /usr/cvs/src/sys/alpha/include/bus.h,v retrieving revision 1.6 diff -u -r1.6 bus.h --- alpha/include/bus.h 2000/08/28 21:48:01 1.6 +++ alpha/include/bus.h 2000/10/03 06:26:09 @@ -364,6 +364,21 @@ #define bus_space_barrier(t, h, o, l, f) \ (t)->ab_ops->abo_barrier(t, (h)+(o), l, f) +#define barrier_acquire \ + bus_space_barrier(busspace_isa_mem, 0, BUS_SPACE_UNRESTRICTED, \ + BUS_SPACE_BARRIER_READ) + +#define barrier_release \ + bus_space_barrier(busspace_isa_mem, 0, BUS_SPACE_UNRESTRICTED, \ + BUS_SPACE_BARRIER_WRITE) + +#define barrier_fence \ + bus_space_barrier(busspace_isa_mem, 0, BUS_SPACE_UNRESTRICTED, \ + BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE) + +#define barrier_flush \ + :w + /* * Flags used in various bus DMA methods. */ Index: i386/include/bus_at386.h =================================================================== RCS file: /usr/cvs/src/sys/i386/include/bus_at386.h,v retrieving revision 1.10 diff -u -r1.10 bus_at386.h --- i386/include/bus_at386.h 2000/06/14 18:48:39 1.10 +++ i386/include/bus_at386.h 2000/10/03 07:04:55 @@ -1154,6 +1154,35 @@ /* + * Generic memory barrier functions. + */ +static __inline void +barrier_acquire(void) +{ + bus_space_barrier(I386_BUS_SPACE_MEM, 0, 0, ~0, BUS_SPACE_BARRIER_READ); +} + +static __inline void +barrier_release(void) +{ + bus_space_barrier(I386_BUS_SPACE_MEM, 0, 0, ~0, + BUS_SPACE_BARRIER_WRITE); +} + +static __inline void +barrier_fence(void) +{ + bus_space_barrier(I386_BUS_SPACE_MEM, 0, 0, ~0, + BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE); +} + +static __inline void +barrier_flush(void) +{ + __asm __volatile("wbinvd" : : : "memory"); +} + +/* * Flags used in various bus DMA methods. */ #define BUS_DMA_WAITOK 0x00 /* safe to sleep (pseudo-flag) */ Index: i386/include/bus_pc98.h =================================================================== RCS file: /usr/cvs/src/sys/i386/include/bus_pc98.h,v retrieving revision 1.11 diff -u -r1.11 bus_pc98.h --- i386/include/bus_pc98.h 2000/06/14 18:48:39 1.11 +++ i386/include/bus_pc98.h 2000/10/03 07:05:04 @@ -1456,6 +1456,35 @@ /* + * Generic memory barrier functions. + */ +static __inline void +barrier_acquire(void) +{ + bus_space_barrier(I386_BUS_SPACE_MEM, 0, 0, ~0, BUS_SPACE_BARRIER_READ); +} + +static __inline void +barrier_release(void) +{ + bus_space_barrier(I386_BUS_SPACE_MEM, 0, 0, ~0, + BUS_SPACE_BARRIER_WRITE); +} + +static __inline void +barrier_fence(void) +{ + bus_space_barrier(I386_BUS_SPACE_MEM, 0, 0, ~0, + BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE); +} + +static __inline void +barrier_flush(void) +{ + __asm __volatile("wbinvd" : : : "memory"); +} + +/* * Flags used in various bus DMA methods. */ #define BUS_DMA_WAITOK 0x00 /* safe to sleep (pseudo-flag) */ In my mind at least, I associate bus_space with new-bus, hence my posting to this list. Comments, questions? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Oct 4 1:26:12 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id B223137B503; Wed, 4 Oct 2000 01:26:05 -0700 (PDT) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 13gjsJ-000Alw-0B; Wed, 4 Oct 2000 08:26:04 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA12097; Wed, 4 Oct 2000 09:32:18 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 4 Oct 2000 09:25:58 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: new-bus@freebsd.org, msmith@freebsd.org Subject: Re: Generic memory barrier helper functions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 3 Oct 2000, John Baldwin wrote: > After talking with Mike, I whipped up some quick and dirty helper > functions for a MI memory barrier API. Basically, you have the following > four functions: > > barrier_acquire() - a read barrier > barrier_release() - a write barrier > barrier_fence() - a read/write barrier > barrier_flush() - a barrier that flushes the CPU's cache > > I have a simple patch to implement all of these on both x86 and alpha > with the exception of barrier_flush() on the alpha at > http://www.FreeBSD.org/~jhb/patches/barrier.patch and inlined here: It seems like a good idea although I'm not quite sure the functions should go in bus.h. I would probably have thought of putting them in atomic.h since one of their most important uses is for SMP communication. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Oct 4 12:19: 1 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from radiant.net (radiant.net [207.194.200.18]) by hub.freebsd.org (Postfix) with ESMTP id 20E9B37B502 for ; Wed, 4 Oct 2000 12:18:57 -0700 (PDT) Received: from shula [208.181.145.20] by radiant.net (SMTPD32-6.04) id A435CD0024; Wed, 04 Oct 2000 12:25:41 -0700 Reply-To: From: "Simon Block" To: Subject: PCI resources with bus_alloc_resource(9) Date: Wed, 4 Oct 2000 12:23:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear NewBus Guru's, I am sending this to you at the suggestion of Alex Langer: I am writing a driver for a PCI device I have a question about the man page for bus_alloc_resource(9). (I am using FreeBSD 4.1 STABLE). The man page states for the parameter that 'rid' points to: "For PCI it just happens to be the offset into pci config space which has a word that describes the re­source." My knowledge of PCI would dictate that this should be the value 0x3C (the offset in PCI configuration space where you find the Int PIN and Int Line registers). e.g. rid = 0x3C; sc->irq = bus_alloc_resource( dev, SYS_RES_IRQ, &rid, 0, ~0, 1, (RF_SHAREABLE | RF_ACTIVE) ); sc->irqid = 0x3C; /* save the value in the soft state */ However ALL the drivers on the system appear to use a value of 0 (zero) instead of 0x3C, and 0 appears to be the only way to get it to work (so it must be right)? Can anyone explain this? If this is the case what does the comment quoted above mean in the man page? PS. I have a driver that opens three independent PCI devices (they are all built into the one card as seperate PCI to local bus ASIC chips). My driver maps all the memory regions ok and will map the first two interrupts (using rid=0) but the mapping of the third interrupt fails. These mapping are called by the system as 3 distinct calls to the attach routine. Is there possibly a resource issue with IRQ's that would means I cannot get another one? Can I get around this somehow? On another platform (motherboard) we are having problems allocating the third memory region as well. How do we deal with these PCI resource issues? What are the limits? How can we modify them? Thanks in advance for any help. Regards, Simon Block Shula Consulting Incorporated 1-1430 Maple St Vancouver, BC V6J 3R9 Phone: 604 736 8791 Fax: 604 736 8796 Cell: 604 841 8791 Email: sblock@computer.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Oct 4 15:27:35 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by hub.freebsd.org (Postfix) with ESMTP id 6416137B502 for ; Wed, 4 Oct 2000 15:27:33 -0700 (PDT) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 13gx0c-000O7t-0U; Wed, 4 Oct 2000 23:27:31 +0100 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id XAA14026; Wed, 4 Oct 2000 23:33:49 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 4 Oct 2000 23:27:20 +0100 (BST) From: Doug Rabson To: Simon Block Cc: new-bus@freebsd.org Subject: Re: PCI resources with bus_alloc_resource(9) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 4 Oct 2000, Simon Block wrote: > Dear NewBus Guru's, > > I am sending this to you at the suggestion of Alex Langer: > > I am writing a driver for a PCI device I have a question about the man > page for bus_alloc_resource(9). (I am using FreeBSD 4.1 STABLE). > > The man page states for the parameter that 'rid' points to: > "For PCI it just happens to be the offset into pci config space which > has a word that describes the resource." > > My knowledge of PCI would dictate that this should be the value 0x3C > (the offset in PCI configuration space where you find the Int PIN and > Int Line registers). This only true for memory and port resources. For interrupts, the value of rid should be zero (not adaquetely documented, I know). -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Oct 4 15:30: 3 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7F48737B502 for ; Wed, 4 Oct 2000 15:30:00 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id e94MTwM17889; Wed, 4 Oct 2000 16:29:59 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA40747; Wed, 4 Oct 2000 16:29:58 -0600 (MDT) Message-Id: <200010042229.QAA40747@harmony.village.org> To: Doug Rabson Subject: Re: PCI resources with bus_alloc_resource(9) Cc: new-bus@FreeBSD.ORG In-reply-to: Your message of "Wed, 04 Oct 2000 23:27:20 BST." References: Date: Wed, 04 Oct 2000 16:29:58 -0600 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug Rabson writes: : This only true for memory and port resources. For interrupts, the value of : rid should be zero (not adaquetely documented, I know). This brings something else to mind. Has anybody looked at creating a pci interface for routing of interrupts? Many pci cardbus cards need this to operate properly. I could put the pcibios stuff directly into the drivers, but that seems to be less than desirable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Thu Oct 5 14:31:28 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 2845A37B502; Thu, 5 Oct 2000 14:31:11 -0700 (PDT) Received: from laptop.baldwin.cx (john@dhcp248.osd.bsdi.com [204.216.28.248]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e95LUsi15495; Thu, 5 Oct 2000 14:30:54 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 05 Oct 2000 14:31:06 -0700 (PDT) From: John Baldwin To: Doug Rabson Subject: Re: Generic memory barrier helper functions Cc: msmith@FreeBSD.org, new-bus@FreeBSD.org Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 04-Oct-00 Doug Rabson wrote: > On Tue, 3 Oct 2000, John Baldwin wrote: > >> After talking with Mike, I whipped up some quick and dirty helper >> functions for a MI memory barrier API. Basically, you have the following >> four functions: >> >> barrier_acquire() - a read barrier >> barrier_release() - a write barrier >> barrier_fence() - a read/write barrier >> barrier_flush() - a barrier that flushes the CPU's cache >> >> I have a simple patch to implement all of these on both x86 and alpha >> with the exception of barrier_flush() on the alpha at >> http://www.FreeBSD.org/~jhb/patches/barrier.patch and inlined here: > > It seems like a good idea although I'm not quite sure the functions should > go in bus.h. I would probably have thought of putting them in atomic.h > since one of their most important uses is for SMP communication. True I suppose, but they depend on bus_space_barrier(), so I would have thought that they were really bus_space helper functions. Also, can you suggest a barrier_flush() for the alpha? > -- > Doug Rabson Mail: dfr@nlsystems.com -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Oct 6 8: 1:53 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from neutron.cichlids.com (p3E9C112B.dip.t-dialin.net [62.156.17.43]) by hub.freebsd.org (Postfix) with ESMTP id 2DE3137B503 for ; Fri, 6 Oct 2000 08:01:47 -0700 (PDT) Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id B70C4AB9C; Fri, 6 Oct 2000 17:03:02 +0200 (CEST) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id D47DB14A9B; Fri, 6 Oct 2000 17:01:38 +0200 (CEST) Date: Fri, 6 Oct 2000 17:01:38 +0200 To: Doug Rabson Cc: new-bus@freebsd.org Subject: Re: PCI resources with bus_alloc_resource(9) Message-ID: <20001006170138.A29365@cichlids.cichlids.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dfr@nlsystems.com on Wed, Oct 04, 2000 at 11:27:20PM +0100 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Doug Rabson (dfr@nlsystems.com): > This only true for memory and port resources. For interrupts, the value of > rid should be zero (not adaquetely documented, I know). ^^^^^^ You could have said that. :) I'm going to re-work the bus_alloc_resource manpage anyways, so I'll take a look at this one, too. Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message