Date: Sun, 19 Mar 2000 12:58:06 -0700 From: Warner Losh <imp@village.org> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: Doug Rabson <dfr@nlsystems.com>, freebsd-new-bus@FreeBSD.ORG Subject: Re: when is dinfo instantiated? Message-ID: <200003191958.MAA08753@harmony.village.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003191958.MAA08753>