How to get a device_t

[M. Warner Losh]

In message: <20030807113011.B7321 at freebsd1.cimlogic.com.au>
            John Birrell <jb at cimlogic.com.au> writes:
: On Wed, Aug 06, 2003 at 05:50:45PM -0600, M. Warner Losh wrote:
: > In message: <40313.1060165108 at critter.freebsd.dk>
: >             "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: > : In fact what you may want to do is hang the entire MMCR off the nexus
: > : as a bus, and hang the various drivers off that bus.
: 
: I have a card based on the SC520 too. (Note to Warner: this is the card I
: needed the higher port numbers for)

I gotta get me one of these :-)...

: I need to access the GPIO pins too. But before that, I need to get flash
: drivers working. Access to the flash chips also requires the MMCR. Does
: it really make sense to hang the flash devices off the MMCR "bus" when they
: are mapped into ISA bus space?

Well, I don't know.  The PC Cards that we have in the system are
mapped into the I/O and memory ranges traditionally reserved for the
ISA bus.  In ISA systems, this made sense because pccard was attached
to pcic was attached to isa.  However, now we have situations where
pccard is attached to cbb which is attached to pci.  There may be a
isab device with isa bus hanging off of it that makes the relationship
between the pccard devices cousins rather than nephews in the tree.
And there isn't any harm from that.  Wouldn't this be a similar
situation?

: >From my reading of the AMD docs, only the CPU core is identifiable
: via the CPUID instruction. The docs say that the first two bytes of
: the MMCR are the REVID and those can be used to "identify the device
: itself". The second byte is set to zero to "identify the product as
: the ElanSC520 microcontroller".  So if you know the MMCR is there,
: you can go to that byte and get confirmation!  Thanks AMD. It seems
: that the discovery via the host to PCI bridge is the only reliable
: way to go.

Can you send me a URL for that document?  I thought I understood
things, but making sure by reading it would sure help.

: My local hack is to make my flash drivers require the elan_mmcr
: option and then they can just go use the elan_mmcr global
: variable. I just need the elan device to be initialised earlier.

But adding it as a child of nexus in the host bridge code wouldn't
make it probe any earlier.  To do that you'd need to make it a true
child of nexus with a identify routine that would go out and try to
find the host bridge at a certain address and use the right kind of
bridge there to add the device.  You could then map the mmcr space to
a convenient location, and then dole it out to child drivers such that
the bus_space macros would do the right thing.  Since it is memory
mapped, this would be relatively easy to do.  This would also allow
you to make it known earlier in the boot process.  This is also very
much analygous to what pccard and cardbus does.  You wouldn't have the
problems that we have with picking resources in the cardbus bridge
code because it looks like the mmcr is at a fixed address (either by
design of the chip or by phk's big stick).

If you'd like, I can sketch out in code what I'm trying to say in
words here.

Warner