Date: Sun, 25 Jul 1999 18:27:09 -0600 From: Warner Losh <imp@village.org> To: Scott Mitchell <s.mitchell@computer.org> Cc: obrien@NUXI.com, ade@lovett.com, phk@FreeBSD.ORG, freebsd-xircom@lovett.com, mobile@FreeBSD.ORG Subject: Re: Reading CIS from kernel? Message-ID: <199907260027.SAA36187@harmony.village.org> In-Reply-To: Your message of "Sat, 17 Jul 1999 23:54:07 BST." <19990717235407.55307@goatsucker.org> References: <19990717235407.55307@goatsucker.org> <19990714185101.09845@goatsucker.org> <19990713182203.A68393@nuxi.com> <19990710162730.60563@goatsucker.org> <19990713182203.A68393@nuxi.com> <199907140652.AAA53151@harmony.village.org> <19990714185101.09845@goatsucker.org> <199907142219.QAA58852@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <19990717235407.55307@goatsucker.org> Scott Mitchell writes: : On Wed, Jul 14, 1999 at 04:19:39PM -0600, Warner Losh wrote: : > Can I get your comments on the following interface? : > : > int pccard_map_cis(int slot) : > : > Maps the slot's cis into memory. You must call the before any of the : > following. It returns 0 on success, or an error from : > /usr/include/sys/errno.h (most likely EBUSY if there are no memory : > windows available). : : I assume this means 'maps a bunch of attribute memory' rather than just the : CIS. In the Xircom cards, for instance, there are a few clusters of : writeable config registers plus the CIS all scattered around the first few : KB of attribute space. We need to be able to get at all of that. Yes. It will map the address space. Reads to this space get the CIS, while writes will happen to the attribute memory, which is used to configure the card... : The only thing I'd add right now would be something to 'get me the next : tuple with id X', maybe : : vaddr_t pccard_cis_next_tuple(int slot, int id, vaddr_t start) : : where start is the address of the tuple to start searching from. I guess : you could also use id == -1 as a wildcard to step through all the tuples. : Pretty much every driver would need something like this, it'd be nice if : they didn't all have to reinvent it. Agreed, so maybe... Where does one get the start address from, however? : How will the map function deal with the multiple chains of tuples that some : cards can have (perhaps split between attribute and common memory)? I've : never actually seen this myself, but I assume it must be used by some : cards. ISTR multifunction cards can have branches in their tuple chains : too. Ugh. Which would require imposing more structure on the CIS than : just a pointer to some mapped memory. But, that's just another layer on : top of the basic mapping and could easily be added later. I've never seen those either. I didn't see any special code in the current pccard code, but I could have overlooked it. It was my understanding, which I must admit I haven't checked, that the CIS could not overflow into the common memory area. I think that the mindshare book says something to this effect. : For my needs though, the interface you've presented is fine. Many thanks! OK. I'll write a man page and implement the functions. This should fix the xe driver in -current, no? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907260027.SAA36187>