From owner-acpi-jp@jp.freebsd.org  Fri Oct  6 11:41:31 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id LAA03375;
	Fri, 6 Oct 2000 11:41:31 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id LAA03370
	for <acpi-jp@jp.freebsd.org>; Fri, 6 Oct 2000 11:41:31 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
From: takawata@shidahara1.planet.sci.kobe-u.ac.jp
Received: from libr.scitec.kobe-u.ac.jp (cs22315.ppp.infoweb.ne.jp [202.219.171.79])
	by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id LAA46661
	for <acpi-jp@jp.freebsd.org>; Fri, 6 Oct 2000 11:39:46 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Received: from shidahara1.planet.kobe-u.ac.jp (localhost [127.0.0.1]) by libr.scitec.kobe-u.ac.jp (8.9.1/3.5Wpl7) with ESMTP id LAA03885 for <acpi-jp@jp.freebsd.org>; Fri, 6 Oct 2000 11:32:30 +0900 (JST)
Message-Id: <200010060232.LAA03885@libr.scitec.kobe-u.ac.jp>
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Thu, 05 Oct 2000 15:31:45 MST."
             <200010052231.e95MVjh03260@mass.osd.bsdi.com>
Date: Fri, 06 Oct 2000 11:32:29 +0900
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 801
Subject: [acpi-jp 801] Re: Device Enumlation idea.
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: takawata@shidahara1.planet.sci.kobe-u.ac.jp

In message <200010052231.e95MVjh03260@mass.osd.bsdi.com>, Mike Smith $B$5$s$$$o$/(B
:
>> >I need to look at how ISA handles PnP devices with eg. dependant
>> >functions, etc. to work out how to store configurations, etc.
>> >
>> >There are also some more interesting questions, eg. should we see
>> >'sio0 at acpi0' ???  This is technically correct, but will upset some
>> >people a lot.
>>
>> I don't think 'sio0 at acpi0' is correct. ACPI component should
>> be used as bus enumlator,like isapnp or pnpbios.It is the identify
>>  code I previously proposed that I intended to act it.
>
>I know that I'm going to get flamed for this, but I actually *really*
>like the idea of attaching a device to the namespace that enumerated it.
>
>One of the reasons I like this is because eg. the APIC is really not an
>ISA device, but it's not really a PCI device either.  A lot of onboard
>peripherals are X-bus devices, or PCI devices that just look sort of like
>ISA devices.  Listing them as children of ACPI is no more "wrong" than
>listing them as children of, eg. ISA.

Though pnpbios may attaches APIC as ISA device (or PNPBIOS should not
 actually be treated as ISA enumulator but mother board(nexus) enumlator),
APIC do not appear in ACPI name space, but appears in acpi header 
table(like FACP),as far as I know. But I recognize such problem 
certenly exist, like npx.(NOTE: AT PIC *IS* isa device.)

>> Name space is scaned by this function without depth first search.
>> (Depth search is done by identify of the child.)
>> If we simply port the BusMgr code, we can only get flat device tree
>> structure.
>
>I don't think we want to use the BusMgr code at all.  The current
>acpi_probe_children scans the entire namespace in the same fashion that
>the PCI code scans PCI configuration space.  (Although the PCI code scans
>breadth-first, because bridges just look like devices.)
>
Is this device tree picture shows your idea?

     root_bus
        |
      nexus
        |
  +---+------+---------------+
  |   |      | 	             |
 npx acpi   ...	            pcib
      |	       	             |
    +-----+-------+         pci
    |	  |    	  |          |
 acpi_pci acpi_ec sio..   +---+----+---+
	                  |   |    |   |
	  ^              foo bar  isab ...
	  |                        |
      (this device tree         (non acpi-probed device here)
       	 structure may
        reflect acpi name tree
           structure like the picture of my idea.)

My idea is as following picture

            root_bus
	       |
             nexus
               |
       +------+-------+------+
       |      |	      |	     |
      npx    acpi   ....   (pcib)<- Attaching of this device is
              |                     failed due to resource manager.
       	      |	                       (intentionally)
       +-----------+-------+---------+-------------+
       |     	   |       |  	     |             |
  acpi_fixedb	  acpi    acpi	    acpi_apic    acpi
                   |       |                       |
                  acpi_pr pcib                   +----------+
                           |                     |          |
                          pci                   acpi_tz	  (some thermal
                           |    	                     control dev)
        +-----+---------+----+-----------+
        |     |              |           |
       isab  pcib           foo      acpi_pci<- enumulate name space and attach
        |     |                                 device_t-acpi_device
       	|    pci                                 list by function number
        |     |
        |    +-+--+-+
        |    |      |
        |     	   acpi_pci<- same as previously mention,
        |     	               but if parent pcib do not have
        |	                acpi_device, do nothing.
       isa
        |
+---+----+----+-----+-------+------+-------+
|   |    |    |     |       |      |       |
.. sio npxisa atpic acpi_ec pnp  pnpbios acpi_isa<- Enumulate acpi name space
                    |              ^               and set resources as pnp
        	    |              |	           driver do.
        	    |              +---(should I disable it?)
        	+---------+----------+
  		|         |          |
	       acpi_bat	acpi_ac	    .....

I convince that,with this way, acpi name space is more integrated to
new bus device tree than your way,if my understanding is correct.
What do you think about this?

Takanori Watanabe
<a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html">
Public Key</a>
Key fingerprint =  2C 51 E2 78 2C E1 C5 2D  0F F1 20 A3 11 3A 62 2A 

