Date: Wed, 24 Sep 1997 12:41:06 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Stefan Esser <se@freebsd.org> Cc: Nate Williams <nate@mt.sri.com>, mobile@freebsd.org, current@freebsd.org Subject: Re: PCCARD in -current broken Message-ID: <19970924124106.61317@hydrogen.nike.efn.org> In-Reply-To: <19970924155302.35730@mi.uni-koeln.de>; from Stefan Esser on Wed, Sep 24, 1997 at 03:53:02PM %2B0200 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser scribbled this message on Sep 24: > On Sep 23, John-Mark Gurney <gurney_j@efn.org> wrote: > > > The code is finished, but I did not commit > > > it to -current, since I was waiting for the > > > new ISA device probe/attach code to become > > > available. > > > > oh... if your waiting for the work that I'm working on.. commit the > > changes now.. I don't think that I'll have anything workable in the > > next month... as next monday is the first day of classes, and I've been > > working this week... so I haven't made any progress yet... > > Well, as I wrote before, I do not intend to > commit that resource check code, since I do > no longer consider it the correct approach. > > I rather want to have a "generic" device > struct, which is common to all device types > (including, for example, SCSI drives), and > which offers a few pointers to methods, upper > data structures (i.e. driver and bus specific) > and device parameters. (Very much like the > Ethernet drivers do, BTW.) > > I'd expect to be able to call a bus-specific > function that allows me to check the resource > usage of a device. A function prototype might > be: > > res_check(gendev *dev, int res_type, int flags) > > This function could redirect the call through > a function pointer obtained from dev->xxx and > that function could for PCI support res_type > values of memory range, port range, IRQ set > and DRQ set. The SCSI code should provide a > function that checked the SCSI ID. The flags > parameter could be used to mark a registration > as "shared", or to allow to check for not yet > registered but prefered resources of some ISA > PnP card. > > 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 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... > The device private data contains all the > information about the resource usage in a way > that allows to represent sparse data (like the > set of IRQs or DMA channels used). It is also yes.. it will... > easy to check for resources this device would > use, if it was attached. This may be of use in > code that plans address ranges for ISA PnP > devices that can be mapped to certain addresses. > > No need to register a resource, BTW. As soon as > the device struct is available to the probe code > (either as a DATA_SET or the isa_devtab_xxx array), > the device's data is available to the resource > check functions. Only the device state has to be > set (unused, attached, possibly intermediate > states). > > The test for resource usage would search through > the bus and device tree, but in many cases the > search of a subtree can be avoided (e.g. a PCI > to PCI bridge will claim all address ranges it > maps to the secondary side, and thus only devices > on a PCI bus directly connected to the CPU have > to be checked. This reduces the number of tests > that have to be performed in a system with lots > of devices. I do not expect the checking against > device private data to be much more inefficient > than a extent registry, and it is done at driver > probe/attach time only, anyway. 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... > 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... > I have put some effort in working out the details, > but those changes are of no big use, if they are > not applied to all device types (i.e. ISA/EISA/ > PCI-Buses, card drivers for these buses, SCSI > device drivers, SCSI device structures). > > > have you actually looked at the extent stuff from NetBSD?? you still > > have to write the wrappers around the extent to use the resources, it's > > just that it provides a way to do mapping of sections of units... > > Yes, sure. And I have a simple registration data > base in my kernel, which does just register the > resource usage. What I do not like about it is: > > 1) I have to register all resources at attach > time and to unregister them when the device > is shutdown. I'd rather flip just a single > bit in the device data structure, which has > to contain all the information anyway. > > 2) The extent code is "tagged on to the side", > and I'd rather just define the prototype of > the check function and let each bus driver > provide an implementation that complies with > the definition. 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, ISA interrupts should be registered in > > > a way that guarantees they are not shared. > > > I agree.. but this should be on a bus dependant side... and with the > > new isa_device stuff I have invisioned.... we will be able to do more > > dynamic sharing of irqs... suchs as marking irqs as only used when > > device is active... so you can share irqs between devices... i.e. the > > common com1/com3 problem... > > But the code that makes ISA interrupts exclusive > is in a bus dependent function (at least I consider > the old register_intr() function to be ISA specific). > > All new code should only use intr_create(), which > creates an interrupt descriptor, and intr_connect() > and intr_disconnect() which (in)activates the handler > according to the information in that descriptor. > > (BTW: Connecting or disconnecting the handler does > not require a check for conflicts, since the function > that manages the shared interrupt handler chain does > check for conflicts whenever a handler is added.) hmm... I'll look at this code... > 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... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970924124106.61317>