Date: Wed, 24 Sep 1997 15:53:02 +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: <19970924155302.35730@mi.uni-koeln.de> In-Reply-To: <19970923191710.61639@hydrogen.nike.efn.org>; from John-Mark Gurney on Tue, Sep 23, 1997 at 07:17:10PM -0700 References: <199709231929.NAA08312@rocky.mt.sri.com> <19970923230018.00034@mi.uni-koeln.de> <19970923191710.61639@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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 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. 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() ... :) 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. > > 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.) The new ISA code definitely should use that interface, and no longer call register_intr() ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970924155302.35730>