From owner-freebsd-new-bus Sun Mar 19 9:37:28 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 774BA37B63F for ; Sun, 19 Mar 2000 09:37:25 -0800 (PST) (envelope-from dfr@nlsystems.com) 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 12Wjdk-000P3W-0B; Sun, 19 Mar 2000 17:37:24 +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 RAA24058; Sun, 19 Mar 2000 17:38:53 GMT (envelope-from dfr@nlsystems.com) Date: Sun, 19 Mar 2000 17:44:34 +0000 (GMT) From: Doug Rabson To: "David E. Cross" Cc: freebsd-new-bus@freebsd.org Subject: Re: when is dinfo instantiated? In-Reply-To: <200003190753.CAA56296@cs.rpi.edu> 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 Sun, 19 Mar 2000, David E. Cross wrote: > I am writing resource reservation and allocation code for PCI buses. > > What I am currently doing is hooking into pci_attach() in sys/pci/pci.c > (new function by my creation). It gets the softc for this instance of the > pci bus (again, my modification). In this softc it stores a resource list > of all of the resources that are allocated to the bridge. This currently > is membase, memlimit, iobase, iolimit, secondary bus, and subordinate > bus. Then as each child on the bus is probed its resource allocations > are marked 'in use' in the parent's softc, any children with invalid, or > unallocated resources may then be filled in dynamically. > > The problem that I am having is that 'device_get_ivars(dev);' in the > 'pci_attach()' function is returning NULL. Going through the code it > appears that pci_new_probe() should take care of this. That is, the > parent of the current bus (and all buses have parents, right?) should set > that structure correctly? Apparently not. What am I missing? This structure should be created by pci_readcfg which is called from pci_add_children. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sun Mar 19 11: 5:51 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 273DC37B684 for ; Sun, 19 Mar 2000 11:05:39 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA66603; Sun, 19 Mar 2000 14:05:32 -0500 (EST) Message-Id: <200003191905.OAA66603@cs.rpi.edu> To: Doug Rabson Cc: "David E. Cross" , freebsd-new-bus@freebsd.org Subject: Re: when is dinfo instantiated? In-Reply-To: Message from Doug Rabson of "Sun, 19 Mar 2000 17:44:34 GMT." Date: Sun, 19 Mar 2000 14:05:31 -0500 From: "David E. Cross" Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, that is what I thought. It would appear that something is not doing its job... below is a my current test case 'pci_attach()' function in pci.c: static int pci_attach(device_t dev) { printf("dinfo: 0x%08lx\n", device_get_ivars(dev)); return (bus_generic_attach(dev)); } This is the only change I have made to the kernel, with the exception of changing the device_method_t for pci.c to point to that attach method. On bootup I get the following messages (dmesg | grep dinfo): dinfo: 0x00000000 dinfo: 0x00000000 I am correct in thinking that the ivars should be set by the parent of a device? Am I making an icorrect assumption that I should be able to get information for a PCI bus from this interface? -- David Cross | email: crossd@cs.rpi.edu Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sun Mar 19 11:58:29 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 B456537B6C6 for ; Sun, 19 Mar 2000 11:58:19 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA14724; Sun, 19 Mar 2000 12:58:13 -0700 (MST) (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 MAA08753; Sun, 19 Mar 2000 12:58:07 -0700 (MST) Message-Id: <200003191958.MAA08753@harmony.village.org> To: "David E. Cross" Subject: Re: when is dinfo instantiated? Cc: Doug Rabson , freebsd-new-bus@FreeBSD.ORG In-reply-to: Your message of "Sun, 19 Mar 2000 14:05:31 EST." <200003191905.OAA66603@cs.rpi.edu> References: <200003191905.OAA66603@cs.rpi.edu> Date: Sun, 19 Mar 2000 12:58:06 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200003191905.OAA66603@cs.rpi.edu> "David E. Cross" writes: : static int : pci_attach(device_t dev) : { : : printf("dinfo: 0x%08lx\n", device_get_ivars(dev)); : return (bus_generic_attach(dev)); : } : : This is the only change I have made to the kernel, with the exception : of changing the device_method_t for pci.c to point to that attach method. : : On bootup I get the following messages (dmesg | grep dinfo): : dinfo: 0x00000000 : dinfo: 0x00000000 : : : I am correct in thinking that the ivars should be set by the parent of a : device? I'm confused here. The pci bus' parent will need to set the ivars for the bus instance. The pci bus' parent is generally the nexus, which doesn't set ivar information for the child instance. : Am I making an icorrect assumption that I should be able to get information : for a PCI bus from this interface? Maybe. Are you expecting the parent pci bus to set the idev for the child pci bus that you are looking at? Are you confusing parent and child? The pci_probe routine will call pci_add_children to add children for each of the slots on the pci bus. If a slot has a config, then that child is added as a child of pci and its config info is set as the ivar for the child, and pci_add_resources is called to populate the child's resource structures. I think that the bridge chip will have the ivars of the parent bus, but that bridge chip doesn't set ivars for the child pci bus that it creates, nor should it. Maybe this is what you are running into. To be fair, I've not followed the discussion closely, so maybe this was already talked about earlier. If my assumptions aren't clear, maybe ascii-art trees of what you are doing might help explain to me what is going on and what you are trying to do. I know you are working on the cardbus stuff. I hope that you aren't trying to make the cardbus bus interface look identical to the pci interface by creating a pci bus there. We really need to have a separate bus for cardbus because it is only pci-bus-like. It isn't a pci bus. Here's how I envisioned the tree looking, with footnotes to say what kind of ivar each device has. Let us assume that it is a cardbus bridge with two cards connected, ep0 in slot 0 and ahc0 in slot 1 pci0[e] + cardbus-bridge0[a] + cardbus0[b] | + cardbus1[b] --+ ahc0[c] +... | + pccard0[b] ---+ ep0[d] | + pccard1[b] [a] is an ivar created by the pci bus, which is a pci_config IIRC. [b] is nothing since cardbus-bridge isn't a bus. [c] is a cardbus_ivar, describing the cardbus resources that the aha 1480 is using (I've omitted the cam scsi bus things here) [d] is a pccard_devinfo in the current pccard code, and something else in NEWCARD. [e] Will usually contain NULL, since it is either the child of a pci bridge, or of nexus (I think). Niether one of them set ivars on their children. BTW, I had thought about having the above look different, with the pcic device in there somewhere, but realized that would make things very hard to manage in the mixed 32-bit and 16-bit card case like above. I also thought about having some kind of slot manager in there, which might turn out to be useful, but for now I'd been thinking of putting that functionality into cardbus-bridge and pcic separately since they don't have that much in common. 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 Sun Mar 19 14:34:19 2000 Delivered-To: freebsd-new-bus@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id A746937B7CA for ; Sun, 19 Mar 2000 14:34:16 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id RAA71131; Sun, 19 Mar 2000 17:34:06 -0500 (EST) Message-Id: <200003192234.RAA71131@cs.rpi.edu> To: Warner Losh Cc: "David E. Cross" , Doug Rabson , freebsd-new-bus@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: when is dinfo instantiated? In-Reply-To: Message from Warner Losh of "Sun, 19 Mar 2000 12:58:06 MST." <200003191958.MAA08753@harmony.village.org> Date: Sun, 19 Mar 2000 17:34:05 -0500 From: "David E. Cross" Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm confused here. The pci bus' parent will need to set the ivars > for the bus instance. The pci bus' parent is generally the nexus, > which doesn't set ivar information for the child instance. > > : Am I making an icorrect assumption that I should be able to get information > : for a PCI bus from this interface? > > Maybe. Are you expecting the parent pci bus to set the idev for the > child pci bus that you are looking at? Are you confusing parent and > child? > > The pci_probe routine will call pci_add_children to add children for > each of the slots on the pci bus. If a slot has a config, then that > child is added as a child of pci and its config info is set as the > ivar for the child, and pci_add_resources is called to populate the > child's resource structures. > > I think that the bridge chip will have the ivars of the parent bus, > but that bridge chip doesn't set ivars for the child pci bus that it > creates, nor should it. Maybe this is what you are running into. Ok... I think I am following this :) Basically, what I need is the type 1 header config for this bridge chip that a particular 'pci_attach()' is being called on behalf of. -- David Cross | email: crossd@cs.rpi.edu Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Sun Mar 19 17: 1: 4 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 0774237B828 for ; Sun, 19 Mar 2000 17:01:02 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA15634; Sun, 19 Mar 2000 18:01:00 -0700 (MST) (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 SAA10871; Sun, 19 Mar 2000 18:00:52 -0700 (MST) Message-Id: <200003200100.SAA10871@harmony.village.org> To: "David E. Cross" Subject: Re: when is dinfo instantiated? Cc: Doug Rabson , freebsd-new-bus@FreeBSD.ORG In-reply-to: Your message of "Sun, 19 Mar 2000 17:34:05 EST." <200003192234.RAA71131@cs.rpi.edu> References: <200003192234.RAA71131@cs.rpi.edu> Date: Sun, 19 Mar 2000 18:00:52 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200003192234.RAA71131@cs.rpi.edu> "David E. Cross" writes: : Basically, what I need is the type 1 header config for this bridge chip : that a particular 'pci_attach()' is being called on behalf of. You'll need to widen the pci interface if you need to talk to the parent bridge chip's config. 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 Mar 23 13:19:48 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 E7DB037BA8D for ; Thu, 23 Mar 2000 13:19:42 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA35812 for ; Thu, 23 Mar 2000 14:19:41 -0700 (MST) (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 OAA43780 for ; Thu, 23 Mar 2000 14:19:37 -0700 (MST) Message-Id: <200003232119.OAA43780@harmony.village.org> To: new-bus@freebsd.org Subject: Comments on the hints driver Date: Thu, 23 Mar 2000 14:19:37 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've create a simple little hint driver, patch attached, that will read in all of the kernel environment variables and process some of them. If you have hint.aic.0.irq=#10 then for aic0 the irq hint is set to 10. If you have hint.ed.0.sensitive=#0 then ed devices aren't treated as senstive and probed first. You could even have something like hint.wintv.-1.format=PAL which makes PAL the default format for wintv driver. One could entend this to include sysctls as well: sysctl.net.ip.tcp.log_in_vain=1 and we could have a way of setting sysctls from the boot blocks. My code doesn't do this last bit yet. Note, that I've had to make the printcap-like #number syntax for the hints because otherwise I wouldn't know which resource hint routine to call. This wouldn't be needed with sysctl since the type is encoded, iirc, in the sysctl data structure. The code has been lightly tested, and appears to work. Properly applied, I think this could be the basis for a better userconfig editor. One would then just save the hints to get the persistance that is needed for some applications. It would certainly move us more steps away from the reliance on config to propigate hint information into the kernel. Comments? Well, other than this shouldn't be in subr_bus.c :-) Warner Index: subr_bus.c =================================================================== RCS file: /base/FreeBSD-tsc-4/sys/kern/subr_bus.c,v retrieving revision 1.5 diff -u -r1.5 subr_bus.c --- subr_bus.c 2000/03/01 21:17:29 1.5 +++ subr_bus.c 2000/03/23 19:38:54 @@ -2473,3 +2473,111 @@ } #endif + +/* + * I'm not sure this is the best place for this, but this is where I'm doing + * it :-) + */ + +static devclass_t hints_devclass; + +/* + * We use the identify routine to get the hints for all the other devices + * + * hint.aha.0.bus_speedup=#1 + * hint.aha.1.irq=#10 + * hint.wl.0.netid="PLUG" + * hint.wl.1.netid="XYZZY" + */ + +/* + * Find the next entry after the one which (cp) falls within, return a + * pointer to its start or NULL if there are no more. + */ +static char * +kernenv_next(char *cp) +{ + if (cp != NULL) { + while (*cp != 0) + cp++; + cp++; + if (*cp == 0) + cp = NULL; + } + return(cp); +} + +static void +hints_identify(driver_t *driver, device_t parent) +{ + char *cp, *ep, *op, *walker; + int len; + int val; + char name[20]; + int unit; + char resname[255]; + + for (cp = kern_envp; cp != NULL; cp = kernenv_next(cp)) { + for (ep = cp; (*ep != '=') && (*ep != 0); ep++) + ; + len = ep - cp; + if (*ep == '=') + ep++; + if (strncmp(cp, "hint.", 5) == 0) { + walker = cp; + walker += 5; + op = walker; + while (*walker && *walker != '.') + walker++; + if (*walker != '.') + continue; + if (walker - op > sizeof(name)) + continue; + strncpy(name, op, walker - op - 1); + name[walker - op - 1] = '\0'; + walker++; + op = walker; + while (*walker && *walker != '.') + walker++; + if (*walker != '.') + continue; + unit = strtol(op, &walker, NULL); + if (*walker != '.') + continue; + walker++; + op = walker; + while (*walker && *walker != '.') + walker++; + if (*walker != '.') + continue; + if (walker - op > sizeof(resname)) + continue; + strncpy(resname, op, walker - op - 1); + resname[walker - op - 1] = '\0'; + walker++; + if (walker + 1 != ep) + continue; + if (*ep == '#') { + val = strtol(ep + 1, NULL, NULL); + resource_set_int(name, unit, resname, val); + } else { + resource_set_string(name, unit, resname, ep); + } + } + } +} + +static device_method_t hints_methods[] = { + /* Device interface */ + DEVMETHOD(device_identify, hints_identify), + + { 0, 0 } +}; + +static driver_t hints_driver = { + "hints", + hints_methods, + 1, /* no softc */ +}; + +DRIVER_MODULE(nexus, hints, hints_driver, hints_devclass, 0, 0); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message