Date: Wed, 24 Sep 1997 23:11:29 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Nate Williams <nate@mt.sri.com>, mobile@FreeBSD.ORG, current@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: PCCARD in -current broken Message-ID: <19970924231129.47670@mi.uni-koeln.de> In-Reply-To: <19970924124106.61317@hydrogen.nike.efn.org>; from John-Mark Gurney on Wed, Sep 24, 1997 at 12:41:06PM -0700 References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org> <19970924155302.35730@mi.uni-koeln.de> <19970924124106.61317@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 24, John-Mark Gurney <gurney_j@efn.org> wrote: > > The "extent" registration code from NetBSD is > > quite generic, and could be used to register > > the resource usage. But I prefer to query the > > device data directly, instead of duplicating > > the information in some generic data base. > > you haven't looked at the extent stuff from NetBSD... all it does is Sure did I look at that code! It has been a few months ago, though. > allows you to "mark" used portions of a number set (say [0,15] for IRQs) > then you can quickly check to see if a resource is used... not who > owns the resource... extent keeps no info on who owns a resource... > just that a resource is used... Yes, I know this. It couldn't coalesce ranges, else. It offers faster lookup for a conflict, but I want to know what's causing a conflict, and for that reason I do not want to have resources registered anonymously. And before duplicating the information present in the driver in some registry, I prefer to directly use the information present in the driver private data. As I said before, the extent registration code allows for a faster check for a collision, but I'd rather be which driver conflicts with another one. Since the check will be performed at device attach time only, this should not cause problems. > yes.. but with the new dynamic loading code... the driver probe/attach > will be done at any time.. plus.. the current implementation can have > the conflicts to be double checked (i.e. it read the irq off the card > and it didn't match the irq passed, so it puts in the new irq, tells > it to reconfig the device)... plus.. how do you handle the finding of > resources for a device?? say you need to memory map something in the > 384k isa whole, want is aligned to some boundary, and don't want it to > cross another boundary?? extent will handle this automaticly for you... If a device has certain restrictions for addresses or other parameters, then the attach code should know about them. I agree, that the extent code simplifies finding a suitable address range in such a case. I was more interested in avoiding conflicts, and I'm willing to make the scan for an address region check all supported ranges against all registered devices. (Most ISA devices support only a very limited set of addresses, not as regular as you suggest above. The restrictions need not be (alignment, boundary to avoid), but often are some discrete tuples of values. IMHO, PnP ISA cards will actually be configured by the BIOS, if present. Else I expect a user land program to exist, which is able to query and calculate parameters to use for that card. The results should be stored in "boot.config" in text form. > > Other information in this generic device struct > > should be a unit number and an up pointer to the > > driver structure (again at least partially generic), > > which among function pointers contains the driver > > name. This would allow to build device names for > > all devices in a uniform way, for example for the > > reservation conflict message in res_check() ... :) > > this is one thing you couldn't do with extent is find who owns the > resource... it would be nice.. you could do that once you've found > that there is a conflict though... Hmmm, seems we approach these questions from quite opposite directions: You assume there is an extent registry, and see that per device resource checking could help identify the conflicting parties. I start with a desire to identify conflicting parties, if there are any, and think this is sufficient also if some address (or IRQ) has to be choosen to not conflict. (It may take several iterations, until a value is tried, that does not conflict, but I think this will take at most a few milliseconds per device that is attached and needs to find some non-conflicting value.) > umm... you do this.. it's just that the bus driver creates a private > extent map for it's resources... extent doesn't do that much for you, > it's just a set of functions that make writing the bus driver function > all that much easier... Well, in case of the PCI code, the PCI to PCI bridge provides "windows" from the primary to the secondary side. In a way, this is like an extent registration for the devices behind the bridge, but in fact, the windows are much more "real": They are stored in the "base" and "limit" registers of the bridge chip, and make the bridge appear as a device that decodes those addresses on the primary bus. A generic set of extent registration functions does not help here at all. And I doubt it does in other situations. Do you have "real" examples to the contrary ? > > The new ISA code definitely should use that interface, > > and no longer call register_intr() ... > > do you have any prototype structs of what you want things to look like.. > one thing I'm lacking is experience with different bus designes... so > making a truely generic structure is a bit more difficult for me... Well, I have a lot of details on paper, and I could start typing it in. I started looking at a device: - it is an instance with private variables - it is controlled by a driver, which has its own set of methods - it is attached in a bus specific way, the bus may be considered to be a "class" A bus may be considered as a device, which controls dependent devices. I'll need some time to find my notes about this, since they are in a big pile of papers and data books, about one meter in height :) One of my concerns was to find data structures, that are space efficient. I could make the PCI code use such structures, but as long as there is no support in the code for other buses, it doesn't provide any actual advantage. I'll forward an article I posted to the -current list in May to you in a seperate message. It is not what I ended with, though, but I do not have anything else in electronic form, right now ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970924231129.47670>