[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ISA bus notes
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
> 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
- 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
- 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@xxxxxxxxxxx> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-new-bus" in the body of the message