Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 May 1998 23:26:27 -0700
From:      Mike Smith <mike@smith.net.au>
To:        Archie Cobbs <archie@whistle.com>
Cc:        stefan@promo.de (Stefan Bethke), luigi@labinfo.iet.unipi.it, freebsd-hackers@FreeBSD.ORG
Subject:   Re: ISA-PnP w\o BIOS support? 
Message-ID:  <199805060626.XAA01524@antipodes.cdrom.com>
In-Reply-To: Your message of "Tue, 05 May 1998 17:28:35 PDT." <199805060028.RAA18956@bubba.whistle.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> I agree with Stefan's sentiment. It seems like this should be
> the paradigm:

We actually thrashed this out last year; you might be able to dig the 
thread up again.  Mostly it was Luigi, Stefan Esser and myself throwing 
ideas around. 

>   CASE #1: Kernel config file looks like this:
>   --------------------------------------------
> 
>     device   foo0
> 
>   In this case, the kernel automatically configures stuff for driver
>   foo0. If the BIOS has already configured the card, and that's
>   acceptable, the kernel can go along. Otherwise, the kernel should
>   pick resources that are free and configure the card itself.
> 
> 
>   CASE #2: Kernel config file looks like this:
>   --------------------------------------------
> 
>     device   foo0 port 0x220 irq 7 vector foointr
> 
>   Kernel should override whatever is already configured in the
>   card (if anything) with the given values.
> 
> 
> Does this make sense to anyone else besides me? What are the
> technical things that need to be done to make it happen?

This actually falls a little short.  It's easier to look at it from a 
different angle, too.

  For each PnP device/function in the system
    If the device/function is not supported (unknown, no driver present)
      deconfigure device (if required)
      continue
    else
      while resources required
        allocate new resources
        test resources (using PnP test facility if available)
      endwhile
      if resources available
        allocate a new driver instance, assign resources
      else
        continue
    endif
  endfor

  For each explicitly-configured ISA devices
    if resource config does not conflict with PnP-configured device
      allocate resources
      if probe succeeds
        allocate new driver instance
      else
        free resources
      endif
    endif
  endfor

So 

device	foo0

will support any number of 'foo' devices.

device	foo0 at isa? port "IO_FOO0"

will support any number of 'foo' devices, as well as probing for one at 
IO_FOO0 after the PnP probe.

The following things have to happen to make this a reality:

 - The PnP BIOS call interface needs to be finished.  I have done some 
   work based on Jonathan Lemon's code, but he needs to finish working 
   out the APM interaction problems.  This is absolutely critical as it
   allows us to use PnP to locate system devices and thus determine 
   which resources are free.  It also lets us find onboard peripherals.
 - Devices need to start ignoring NFOO and using malloc() to obtain 
   storage for softc structures.  They also need to start passing 
   pointers to these structures around instead of unit numbers.  This 
   has been started with the changed arguments to ISA interrupt 
   handlers (taking void * instead of int).
 - A PnP enumerator needs to be written to traverse the PnP data.  It 
   has to handle all three basic states (No BIOS, BIOS configuring 
   boot-only devices, BIOS configuring everything).  ISA PnP code 
   already exists to handle the "No BIOS" and "boot-only" cases.
 - A mechanism for loading PnP ID:driver mappings would be good.  
   Putting them in the driver works OK but is suboptimal.  Note that 
   there is a table of "generic" PnP device identifiers as well that
   should be used whenever possible.  The "extras" stuff that I did for 
   the splash screen code can be used for this.

-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805060626.XAA01524>