Date: Wed, 06 Aug 2003 19:45:32 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jb@cimlogic.com.au Cc: ticso@cicely.de Subject: Re: How to get a device_t Message-ID: <20030806.194532.21929682.imp@bsdimp.com> In-Reply-To: <20030807113011.B7321@freebsd1.cimlogic.com.au> References: <40313.1060165108@critter.freebsd.dk> <20030806.175045.73337045.imp@bsdimp.com> <20030807113011.B7321@freebsd1.cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030807113011.B7321@freebsd1.cimlogic.com.au> John Birrell <jb@cimlogic.com.au> writes: : On Wed, Aug 06, 2003 at 05:50:45PM -0600, M. Warner Losh wrote: : > In message: <40313.1060165108@critter.freebsd.dk> : > "Poul-Henning Kamp" <phk@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030806.194532.21929682.imp>