Re: Getting at cardbus CIS data from inside drivers
On Tue, Nov 21, 2000 at 01:28:46PM -0700, Justin T. Gibbs wrote: That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. As I see it, there are several ways this can be implemented, with several issues to consider. 1) How is the information passed? a) callback b) driver code calling cardbus_get_cistuple(dev, tuplenum) 2) When is the information passed? a) before probe (for callback) b) between probe and attach (for callback) c) automatically after attach (for callback) d) when child requests (for either) 3) When is the information read? a) Once when CIS is read and parsed initially by the bridge, and once when it's time to pass the info to child. b) Only once when CIS is read and parsed initially by the bridge. CIS info is stored in malloc'ed kernel memory c) This point may be moot if the cardbus bus does not read CIS, or if the bridge reading/parsing CIS step is delayed. Personally, I am somewhat torn between using callback or not, but I'm leaning more towards using an interface like cardbus_get_cistuple(). The reasoning behind this is that we may not know when, if ever, a driver would need CIS data. It might need this information in the probe code (unlikely for correctly implemented cardbus hardware and driver set, but IMHO we should keep the interface for cardbus and pccard the same, and pccard drivers might need this functionality) Having callbacks before attach that are actually useful might introduce a whole lot of messiness we don't need. As for point 3, I think that we should read the CIS prior to probe or attach of the child driver, and save the information in memory. My reasoning is that we can't be sure whether we can map and read the CIS after the driver is in control. For all we know the hardware might have been put into some mode where CIS reading would be turned off. True a driver programmer can get around that, but why not just stick it in the ivars to begin with? -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\Jonathan Chen [EMAIL PROTECTED] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Jonathan Chen writes: : As I see it, there are several ways this can be implemented, with several : issues to consider. : 1) How is the information passed? :a) callback :b) driver code calling cardbus_get_cistuple(dev, tuplenum) Yes. I think there's a strong preference for 1b. It also follows the card services model in the standard. : 2) When is the information passed? :a) before probe (for callback) :b) between probe and attach (for callback) :c) automatically after attach (for callback) :d) when child requests (for either) The 16bit code reads the CIS before the probe so that information in the CIS can be used during the probe to answer the probe question "Is this my device?". The 16-bit code currently uses the callback mechanism, but it is done at the request time (eg, go read the cis, and give me a callback to this function for each tuple). : 3) When is the information read? :a) Once when CIS is read and parsed initially by the bridge, and once : when it's time to pass the info to child. :b) Only once when CIS is read and parsed initially by the bridge. CIS : info is stored in malloc'ed kernel memory :c) This point may be moot if the cardbus bus does not read CIS, or if : the bridge reading/parsing CIS step is delayed. When needed, I think is the answer. There's no reason not to re-read the CIS occasionally, as it is fairly cheap to do so. There is a reason not to read it during normal operations of the driver (since it ties up a memory slot that might otherwise be used by the driver), but that's up to the driver to deside. : Personally, I am somewhat torn between using callback or not, but I'm : leaning more towards using an interface like cardbus_get_cistuple(). I'm leaning that way myself (cf other posts I've made). : The reasoning behind this is that we may not know when, if ever, a driver : would need CIS data. It might need this information in the probe code : (unlikely for correctly implemented cardbus hardware and driver set, but : IMHO we should keep the interface for cardbus and pccard the same, and : pccard drivers might need this functionality) Having callbacks before : attach that are actually useful might introduce a whole lot of messiness we : don't need. Right, callbacks were never intended to be a oneshot at some magic point during the probe/attach process, but rather a one per tuple callback in response to a specific request by the driver to read the CIS. : As for point 3, I think that we should read the CIS prior to probe or : attach of the child driver, and save the information in memory. My : reasoning is that we can't be sure whether we can map and read the CIS : after the driver is in control. For all we know the hardware might have : been put into some mode where CIS reading would be turned off. True a : driver programmer can get around that, but why not just stick it in the : ivars to begin with? Much of the parsed information in the 16-bit case is saved in the ivars, but the whole CIS isn't. We could save the whole CIS chain in the ivars, except for one important issue. registers. The pccard standard allows, and specifically talks about, CIS values that the parsing program doesn't understand. Vendors are free to have a CIS value of, say, 129 (any value = 128, save 255) and have it be the registers for the hardware that cause things to happen when read/written. This isn't very common (although the raylan driver comes closest), but it can happen. We could just ignore these tuples completely (which is what we're supposed to do anyway, per the spec), but that would leave driver writers out in the cold when it comes time access these tuples. Of course my tuple reading api I posted earlier didn't allow for this (I read the standard on my two plane trips this weekend) as it copied the CIS out to a user buffer. But most of this is moot because most drivers will just want to grab a network ID or a model number and won't care about the rest of the CIS space. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
The other interface will be an enumerative interface where you can get a callback for each CIS entry. These will be bus method based so that they will be the same between 16-bit and 32 bit code. I don't think the enumerative interface should be callback based. I'd rather have something that facilitates walking the CIS that can be used at anytime. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : The other interface will be an enumerative interface where you can get : a callback for each CIS entry. These will be bus method based so that : they will be the same between 16-bit and 32 bit code. : : I don't think the enumerative interface should be callback based. I'd : rather have something that facilitates walking the CIS that can be used : at anytime. That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
The problem with a read/seek interface is that you are consuming a resource (a memory window) while you are using it. Yes, but this is the client's resource to use anyway. You'd need an open/close on top of that as well to properly map things in to start and then free them at the end. Plus you might want a ftell sort of interface as well. I'll likely punt on the seek/ftell part. I think it was Jonathan that mentioned that at times when you read one entry you want to skip to another entry that it may reference. I don't have the spec to know, but that is why I thought the flexibility of having a seeking interface might be necessary. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : The problem with a read/seek interface is that you are consuming a : resource (a memory window) while you are using it. : : Yes, but this is the client's resource to use anyway. IIRC, it is shared at the bridge, so the client driver needs to conserve this resource. The comment was more of a thnking out loud for the need to have an open and close (or in this case map and unmap) around its use. : You'd need an : open/close on top of that as well to properly map things in to start : and then free them at the end. Plus you might want a ftell sort of : interface as well. I'll likely punt on the seek/ftell part. : : I think it was Jonathan that mentioned that at times when you read : one entry you want to skip to another entry that it may reference. : I don't have the spec to know, but that is why I thought the flexibility : of having a seeking interface might be necessary. That's one reason that I'd want the callback interface. There are pointers in CIS to other CIS entries that the driver shouldn't care about. However, these are relatively rare, but do appear in multi-function cards (at least for 16-bit cards) and so would likely need to be taken care of. I could have something that would skip ahead, but it wouldn't be a fully general seek/ftell function. That moves more of the processing into the driver than I'd rather see, but I don't see a clean way around it. IIRC, and I haven't looked it up, the CIS entries that would be problematical have two next pointers. One is for the next function, while the other is for the first entry specific to this function. The driver code could look at the CIS entry to tell what to do, and if it was the wrong function, call cis_skip_this_function(dev, cookie, cis); which would skip this function and position the read pointer hidden in the cookie to point to the first entry in the next function's cis (or more accurately, the first entry in the series of entries that are specific to that function). And if you provide this, then people will want to just look at the cis entries for their function only next, which is another interface. Or they will want to search for a certain kind of cis entry. I'm disinclined to make this interface too rich. Oh, and I'd have to make sure that the CIS pointers were sane, which can be hard. One of the problems with the NetBSD code, at least in the past, is that it was too believing that the CIS entries would be compliant with the specs. So certain 16-bit cards would crash the system. It is complications like this that lead me to want to not allow CIS reading at all, but rather provide the commonly parsed information easily to the driver. I don't want drivers groveling through all this stuff to find an ethernet address when the bus is able to parse the CIS and return this on request. Having said that, and based on my experience with some really whacko hardware in the 16-bit world, I think that I can't justify this stand because it makes writing a device driver for whacked out hardware impossible w/o gross hacks (cf older revs of if_xe.c). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. Let's be realistic; the right way to do this is going to be to use the ivar interface; cardbus_get_cistuple(dev, index) just like all the other PCI bus accessor functions. PCI will just need to pass the request through to its parent, assuming its parent is a cardbus bridge, or veto it otherwise. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
IIRC, and I haven't looked it up, the CIS entries that would be problematical have two next pointers. One is for the next function, while the other is for the first entry specific to this function. The driver code could look at the CIS entry to tell what to do, and if it was the wrong function, call cis_skip_this_function(dev, cookie, cis); which would skip this function and position the read pointer hidden in the cookie to point to the first entry in the next function's cis (or more accurately, the first entry in the series of entries that are specific to that function). No; the CIS parser should know which function it's being called on behalf of, and simply elide the tuples that don't relate to that function. It is complications like this that lead me to want to not allow CIS reading at all, but rather provide the commonly parsed information easily to the driver. I don't want drivers groveling through all this stuff to find an ethernet address when the bus is able to parse the CIS and return this on request. Having said that, and based on my experience with some really whacko hardware in the 16-bit world, I think that I can't justify this stand because it makes writing a device driver for whacked out hardware impossible w/o gross hacks (cf older revs of if_xe.c). Export the commonly-known stuff through the "right" interface (eg. cardbus_get_cistuple(dev, CARDBUS_CIS_STATION_ADDRESS)) and then provide a backdoor (cardbus_get_cistuple(dev, CARSBUS_CIS_RAW + index)) for the evil side, perhaps. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : That's what I mean. You call this, and it will remap the CIS (if it : has been unmapped), walk it for you and pass you a pointer to each CIS : entry one at a time to the function you specify. : : Warner : : I'd rather have a seek/read interface than have a callback. : : Let's be realistic; the right way to do this is going to be to use the : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : PCI bus accessor functions. PCI will just need to pass the request : through to its parent, assuming its parent is a cardbus bridge, or veto : it otherwise. Why does this have to go even to the bridge? The cardbus bus code already deals with the CIS and it should be the one to arrange things to happen. We can tweak the current cardbus CIS reading stuff to do this and maybe combine it somewhat with the pccard CIS reading stuff. Also, the index doesn't make so much sense because each CIS entry is a variable length, so we'd have to walk the chain. The length is variable, which doesn't work so well with the accessor function which tend to like things to be = sizeof(long). Also, this isn't a PCI thing, so no PCI code should be called. :-) For mapping some parts of the CIS, I think that you need to do that at the cardbus bridge, which means that you can only do that for the cardbus children that are attached. Going up through multiple bridges isn't going to work. This is especially true for the 16-bit CIS entries. Eg, if you have something like the following: pci --- pccbb0 --- cardbus0 --- pcib --- pci -- pccbb0 -- cardbus1 -- dc then when the dc driver wants to map the CIS, the cardbus bus will ask the pccbb to map it, which will go up the usual food chain for mapping, but after it leaves the pccbb it is just a normal map request. The second cardbus bridge (pccbb0) doesn't get into the act of mapping the CIS. Once mapped, cardbus1 will be returning the CIS to dc and also handling the jump discontinuties that can happen in the CIS. This is why I want to have cardbus be its own bus that happens to implement all the pci bus things properly. It is, in C++ terms, a subclass: it is a pci bus plus a few other things. I don't think we should try to shoehorn it all into the PCI bus code. Something tells me that it will result in chaos. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
: Let's be realistic; the right way to do this is going to be to use the : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : PCI bus accessor functions. PCI will just need to pass the request : through to its parent, assuming its parent is a cardbus bridge, or veto : it otherwise. Why does this have to go even to the bridge? Because it's the bridge driver that has to parse the CIS; it needs it to eg. set power and so forth. And because the bus code should be generic. The cardbus bus code already deals with the CIS and it should be the one to arrange things to happen. We can tweak the current cardbus CIS reading stuff to do this and maybe combine it somewhat with the pccard CIS reading stuff. Also, the index doesn't make so much sense because each CIS entry is a variable length, so we'd have to walk the chain. Index is the tuple index, not the byte offset in the CIS; sorry I didn't make that clear. Also, this isn't a PCI thing, so no PCI code should be called. :-) Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers to do stuff with them up through the stack. This really isn't any different. For mapping some parts of the CIS, I think that you need to do that at the cardbus bridge, which means that you can only do that for the cardbus children that are attached. Going up through multiple bridges isn't going to work. This is especially true for the 16-bit CIS entries. Yeah; I don't think I was proposing anything like this. Eg, if you have something like the following: pci --- pccbb0 --- cardbus0 --- pcib --- pci -- pccbb0 -- cardbus1 -- dc then when the dc driver wants to map the CIS, the cardbus bus will ask the pccbb to map it, which will go up the usual food chain for mapping, but after it leaves the pccbb it is just a normal map request. The second cardbus bridge (pccbb0) doesn't get into the act of mapping the CIS. Once mapped, cardbus1 will be returning the CIS to dc and also handling the jump discontinuties that can happen in the CIS. This is why I want to have cardbus be its own bus that happens to implement all the pci bus things properly. It is, in C++ terms, a subclass: it is a pci bus plus a few other things. I don't think we should try to shoehorn it all into the PCI bus code. Something tells me that it will result in chaos. I think that you're overrating the things that need to be "shoehorned" into PCI to make it a comfortable superset of stock PCI + hot-plug PCI + CardBus. So far all we have is passing through a CIS tuple accessor function. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. : Export the commonly-known stuff through the "right" interface : (eg. cardbus_get_cistuple(dev, CARDBUS_CIS_STATION_ADDRESS)) and then : provide a backdoor (cardbus_get_cistuple(dev, CARSBUS_CIS_RAW + index)) : for the evil side, perhaps. Right now pccard exports this as: uchar8_t ether_addr[ETEHR_ADDR_LEN]; pccard_get_ether(dev, ether_addr); where pccard_get_ether is generated by really ugly, but usefully stolen from pci, macros in dev/pccard/pccardvar.h. The OLDCARD code set this from the userland after parsing the CIS. NEWCARD currently doesn't implement this correctly, but will need to do so shortly. I'd like to do exactly the same thing for cardbus: uchar8_t ether_addr[ETEHR_ADDR_LEN]; cardbus_get_ether(dev, ether_addr); to make things easy. I don't think that we can easily do the index thing for CIS entries, for reasons that I've talked about before. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : : Let's be realistic; the right way to do this is going to be to use the : : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : : PCI bus accessor functions. PCI will just need to pass the request : : through to its parent, assuming its parent is a cardbus bridge, or veto : : it otherwise. : : Why does this have to go even to the bridge? : : Because it's the bridge driver that has to parse the CIS; it needs it to : eg. set power and so forth. And because the bus code should be generic. I don't think that the bridge driver should parse the CIS. The bus driver should do the parsing. The bridge driver may be asked by the bus driver to do mapping and such, but it shouldn't do the parsing of the CIS. This is a card services vs socket services issue. I want to be able to implement card services and socket services (maybe in a form different than the pccard spec states). Other card services, from the spec, include resource management (which the bus does), cis traversal, bulk memory services, cis verification, and event managment (note that socket services generate these events and card services respond to them) and some power management issues. All the flash MDTs are handled here as well. Many of these are unique to cardbus and pccard. Many of these are shared with pci. The mapping into FreeBSD's newbus has been a little fuzzy. The experience from the 16-bit days was that one can have different PCIC bridges that the pccard bus sits on top of. There are at least 4 different APIs to talk to the pcic bridge that I know of (pcic (i82365), pcic98 (a custom NEC part found on some pc98 laptops (including mine!)), tcic (an 8-bit pccard interface) and some sbus chip that I know nothing about). We don't want to have the CIS parsing code replicated in each one. While there is only one known cardbus bridge API today, I don't want to architect something that will be hard to have a different one should it become necessary if there's a cardbusII bridge based on pcix that has a legacy way to support cardbus1 (for example). : The cardbus bus code : already deals with the CIS and it should be the one to arrange things : to happen. We can tweak the current cardbus CIS reading stuff to do : this and maybe combine it somewhat with the pccard CIS reading stuff. : Also, the index doesn't make so much sense because each CIS entry is a : variable length, so we'd have to walk the chain. : : Index is the tuple index, not the byte offset in the CIS; sorry I didn't : make that clear. I'm not sure that I follow what you mean by tuple index then. Is that the Nth CIS, or the CIS of type N? If it is the Nth cis, then we do have to walk N-1 CIS tuples to find it. If it is the CIS of type N, then how do we do multiple ones of type N (which is legal and happens for the config entries)? The CIS is an array of bytes. It lives in 1 or more address spaces. Each CIS tuple contains a length (which is used to find the next one). Some CIS tuples are multi-function chaining tuples and contain two lengths, one of the current CIS tuple, and the aggregate length of all tuples for this function. I do not recall if there's a function number in it, but that is implicit from where we are in the CIS. Each CIS tuple is between 2 and 254 bytes long. To find the Nth one, I have to know where the N-1th one ends for all values of N 0. The 0th element is pointed to by the CIS pointer in the pci config space. : Also, this isn't a PCI thing, so no PCI code should be called. :-) : : Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers : to do stuff with them up through the stack. This really isn't any : different. I do think it is different, but maybe we're arguing about semantics here. I'm talking about having the cardbus bus (cardbusN) code do the parsing of the CIS, while asking for assistance from the cardbus bridge code (pccbbN) to apply power to the slot, map in address spaces, etc. The carbus bus code can generically parse the CIS and dole it out to its children by asking the bridge to do certain specific things. The bridge shouldn't be doing the actual parsing. This is a layering argument. The bus is where the resource allocation book keeping takes place, and we'd need it to do that for the CIS stuff that has been mapped so that if the card driver is a bad citizen, it can cleanup properly. I guess I fear putting the cardbus bus function in the cardbus bridge and teaching a regular pci bus to pass them through. I'd rather have the pci bus code reject such attempts and the cardbus bus code process them. : I think that you're overrating the things that need to be "shoehorned" : into PCI to make it a comfortable superset of stock PCI + hot-plug PCI + : CardBus. So far all we have is passing through a CIS tuple accessor : function. 8) It isn't just an accessor to a configuration space, like PCI has. It is
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. The ROM BAR is only implemented for function 0 and the ROM contains information for all functions of the chip. So, functions greater than 0 must have the flexibility to activate at least the ROM BAR on function 0 as well as access that region. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. The ROM BAR is only implemented for function 0 and the ROM contains information for all functions of the chip. So, functions greater than 0 must have the flexibility to activate at least the ROM BAR on function 0 as well as access that region. Does the driver need the ROM, or the CIS which may be inside the ROM? If the driver needs structured information from inside the ROM, this falls into the same category as the CIS. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : The ROM BAR is only implemented for function 0 and the ROM : contains information for all functions of the chip. So, functions : greater than 0 must have the flexibility to activate at least the ROM : BAR on function 0 as well as access that region. I think there's a difference between where the CIS actually lives, and the CIS chains for the each function. cardbus cards give each function its own CIS chain. These CIS chains can live in configuration space, in memory space or the expansion ROM (which I assume is the same thing as the ROM BAR on function 0, but maybe I'm mistaken) and the bridge is responsible for properlly mapping the last two. The config space presents the biggest problem because we don't have any way to access it with the bus_space(9) functions, so special code is needed in the cardbus bus driver to know where to read from. I talked with YAMAMOTO shigeru-san at BSDcon about an extension to the bus_space code to allow user defined regions/functions to be used so that one can write generic code to access each of these regions with bus_space_read/write_N. Since this is getting off topic, I'll leave it there, but it looked cool and many of the issues I could think of to bring up were handled well. I also made an error in a previous message. 16-bit and 32bit cis parsing is somewhat different. 16-bit cards effectively have the functions comingled with global entries, while cardbus segregates them. With cardbus the iterated chain would just contain CIS entries for that function. They designed things this way so that the functions could be completely separate, integrated only on an ASIC at the last minute before being placed on a cardbus card :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
function its own CIS chain. These CIS chains can live in configuration space, in memory space or the expansion ROM (which I assume is the same thing as the ROM BAR on function 0, but maybe I'm mistaken) and the bridge is responsible for properlly mapping the last two. The config space presents the biggest problem because we don't have any way to access it with the bus_space(9) functions, so special code is needed in the cardbus bus driver to know where to read from. The code reading the CIS should be using callbacks into the hardware-specific code, which will know how to read/write PCI configuration space. Having said that, there's a good argument to be made for adding PCI configuration space as a new bus_space type. Any thoughts on why this might be a bad idea? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Bill Paul writes: : Is there any support planned for externalizing the CIS info somehow, : i.e. by providing bus methods to call the CIS parsing routines? Another : way to do it would be to pass the info down to the child device using : ivars. I would imaging that there's similar support for this in Windows, : otherwise Intel's driver wouldn't work. Yes. There's two things we're planning on exporting. First is to export parsed data as various Ivars, like we do for the the 16-bit cards. This will likely be the interface that you want to use, since we know about network nic addresses. The whole CIS parsing for cardbus is a little bogus at the moment, so we're looking at making it much less bogus. The other interface will be an enumerative interface where you can get a callback for each CIS entry. These will be bus method based so that they will be the same between 16-bit and 32 bit code. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
