Date: Sat, 17 Jul 1999 23:54:07 +0100 From: Scott Mitchell <s.mitchell@computer.org> To: Warner Losh <imp@village.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: <19990717235407.55307@goatsucker.org> In-Reply-To: <199907142219.QAA58852@harmony.village.org>; from Warner Losh on Wed, Jul 14, 1999 at 04:19:39PM -0600 References: <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
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. > int pccard_unmap_cis(int slot) > > Unmaps the CIS. This frees any resource used by the slot to map its > CIS. It returns 0 on success, and an errno value if not. > > vaddr_t pccard_cis_addr(int slot) > > Return the virtual address of the CIS. The CIS must be mapped before > call this function. Drivers may read/write this memory. Reading this > memory will get the CIS entries. Drivers are responsible for > interpreting the CIS. Writing to CIS locations generally is used to > configure the card and does not change the CIS stored on the card. If > the card is not mapped, then 0 will be returned. It is not valid to > access memory returned by this call after a call to > pccard_unmap_cis. > > Future interfaces may ease the burdon on driver writers, but this > interface will be supported for a while. > > Does this fill your needs? 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. 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. For my needs though, the interface you've presented is fine. Many thanks! Cheers, Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" s.mitchell@computer.org | 0xAA775B8B | -- Anon 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?19990717235407.55307>