Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[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
> 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

- 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