Date: Thu, 02 Dec 1999 13:30:46 -0700 From: Warner Losh <imp@village.org> To: new-bus@freebsd.org Subject: How do I map attribute memory... Message-ID: <199912022030.NAA04669@harmony.village.org>
next in thread | raw e-mail | index | archive | help
Thanks for the responces to the irq activation question. In newcard I'll move the activation to when the ISV is registered via bus_setup_intr. I may do this in oldcard as well, depending on how much I wanna work on the old code... Now, on to other matters. Different resource spaces. pccards have three resource spaces. They have shared memory, programmed I/O and attribute memory. The bridge chips support mapping the I/O ports into the host's I/O space. They also support mapping the shared memory and the attribute memory into the host's memory space. My question is how does newbus handle this? I don't see any place in the bus_alloc_resource to hang this information. One could add it as the resource argument, but that would require more hacking than I want to do to map a new type at the pcic bridge to the system space, and might have some undesirable side effects elsewhere. Overloading rid doesn't seem the right thing to do. I suppose I could add a flag bit, but what I really want is a parameter that says which address space is being allocated/activated, but that would force a lot of driver changes. My feeling is that a flag bit in the flags word, eg RF_ATTRIBUTE_MEM would be how I'd go and have the pcic (or any pccard bridge) driver look for this and do special things. I need this functionality generically for the pccard configuration code anyway... However, that seems the least wrong way to do it rather than actually being right. Comments? Warner P.S. Most normal pccards don't need this. The only thing that lives in the attribute space for them is the CIS and some write-only registers to activate the card, set which config to use, etc. There exists at least one modern pccard that uses it to control packets to be send or recieved :-(. Also the xircom folks need something similar, iirc. 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?199912022030.NAA04669>