Date: Sat, 31 Aug 2002 01:10:36 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: new-bus@FreeBSD.org Subject: RE: ISA bus notes Message-ID: <XFMail.20020831011036.jhb@FreeBSD.org> In-Reply-To: <20020830.220723.10970697.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31-Aug-2002 M. Warner Losh wrote: > > If the system has ACPI: > attach acpi_isabus > else if the system has pnpbios > attach pnpbios_isabus > else > attach isabus > > Then call the attached isa bus' attach routine. If appropriate, > enumerate devices from the enumeration source. For acpi and pnpbios, > lists of devices come from those enumeration sources. Since this > information contains other information (such as IRQ, IOPORT, MEMORY, > etc), these resources can be set on the children that are added. Then > call the generic attach routine. The common code will then call any > of the children's drivers identify routines, as it does now. The PnP > ISA devices would then be added. Hints would then be added to the > mix. If a given 'hint ball' matches to a device (with the above set > resources), that device would be hard wired to that unit. Otherwise a > new child is added. After all this enumeration happens, then the pnp > isa devices are disabled. The children are then probed in the proper > order (sensitive devices, then normal devices). PnP ISA devices are > then re-enabled and the probe routines for them are called. > > I don't where winter's stuff fits into this... I've not done the > research here to know for sure. > > Other than that, I think that we're going to be in good shape without > hints on all but the most primitive machines (and lucky me, I have two > of these beasties still in service or hot-standby). > > This is a bit of a re-hash of John's post, but I wanted to make sure > that it was all summarized to make sure that we're not missing some > step or anything. > > Look good? Well, I think you are looking at it not quite from an OOP perspective. :) Try using the same model of overriding bus drivers that I use with ACPI and the PCI bus. Thus, instead of having the system try and know which kind of ISA bus to attach, you have three drivers for "isa": - acpi_isa (called "isa" though) whose probe routine only succeeds if it can read it's handle via ivars on itself. In all ACPI systems that I know of, we can handle this case fairly easily by providing an ACPI PCI-ISA bridge driver that adds ivar support for the child bus device like the ACPI PCI bus driver does; probe routine returns 0 on success - pnp_isa (again, "isa") whose probe routine only succeeds if PNPBIOS is detected. This probe routine can return -100 or some such. - isa (again, "isa") whose probe routine pretty much always succeeds and returns -1000 or some such This way, ISA busses become the right "flavor" of an ISA bus via normal probe/attach methods (i.e. we let the probe routines choose what type of ISA bus to use). I think we should leave the hint-device merging stuff until later as it requires to fix all the broken ISA drivers to get it right. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020831011036.jhb>