Date: Tue, 21 Nov 2000 22:36:01 -0700 From: Warner Losh <imp@village.org> To: Mike Smith <msmith@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <200011220536.WAA40087@harmony.village.org> In-Reply-To: Your message of "Tue, 21 Nov 2000 20:48:18 PST." <200011220448.eAM4mIF00882@mass.osd.bsdi.com> References: <200011220448.eAM4mIF00882@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200011220448.eAM4mIF00882@mass.osd.bsdi.com> 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 access to a byte stream that may live in many different spaces, even on the same card (this was true of 16-bit cards, I'm not sure of the 32-bit cards). Again, we have a disagreement about where the parsing should rightly be done and where information about the state of the parsing and resouce maps should be cached. These tuples aren't like PCI configuration space. That makes sense to have at the bridge level because no parsing is necessary. The accessors for the CIS just don't make sense because the CIS tuples are variable length and are more expensive to map in and out than the pci configuration space. The CIS is also read-only, whereas the pci config space is read/write to configure the card. The attribtue memory for 16-bit cards can be written to and is usually where the CIS lives, but that's something altogether different. Maybe I'm not explaining well, or maybe there are issues here that I don't understand. I am finding it hard to understand exactly what you are suggesting at times. I think I have it, but it just doesn't make sense. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011220536.WAA40087>