From owner-acpi-jp@jp.freebsd.org  Fri Oct  6 12:44:30 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id MAA07764;
	Fri, 6 Oct 2000 12:44:30 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id MAA07759
	for <acpi-jp@jp.freebsd.org>; Fri, 6 Oct 2000 12:44:28 +0900 (JST)
	(envelope-from msmith@mass.osd.bsdi.com)
Received: from mass.osd.bsdi.com (localhost [127.0.0.1])
	by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e963kDh04189
	for <acpi-jp@jp.freebsd.org>; Thu, 5 Oct 2000 20:46:13 -0700 (PDT)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200010060346.e963kDh04189@mass.osd.bsdi.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Fri, 06 Oct 2000 11:32:29 +0900."
             <200010060232.LAA03885@libr.scitec.kobe-u.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Oct 2000 20:46:13 -0700
From: Mike Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 802
Subject: [acpi-jp 802] Re: Device Enumlation idea. 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

> >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.)

Yes.  And the more I think about it, the more I agree with you.  ACPI 
should just be used to enumerate devices; they are still ISA devices.

> >> 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.)

Mostly, although I was going to attach the pcib to acpi as well, as you 
proposed to.

> My idea is as following picture
> 
>             root_bus
> 	       |
>              nexus
>                |
>        +------+-------+------+
>        |      |       |      |
>       npx    acpi   ....   (pcib)<- Attaching of this device is
>               |                     failed due to resource manager.
>               |	                       (intentionally)

Agreed.  We can easily defeat the creation of the default root pcib by 
making it possible to search for a pcib with a given segment/bus number.  
The ACPI code will already have created the default root PCI bus, so this 
will succeed and nexus_pcib_identify will not create it.

>        +-----------+-------+---------+-------------+
>        |           |       |         |             |
>   acpi_fixedb	  acpi    acpi	    acpi_apic      acpi
>                    |       |                       |
>                  acpi_pr pcib                   +----------+
>                            |                    |          |
>                           pci                 acpi_tz  (some thermal
>                            |    	                     control dev)

Not exactly.  I think:

          acpi
            |
    +-------+-------+--------+-------+----------+---- ...
    |       |       |        |       |          |
 acpi_pr acpi_tz acpi_ec acpi_lid acpi_pcib0 acpi_pcib1
                    |                |          |
              acpi_ec_smbus         pci0       pci1
                    |                |          |
                  smbus0
                    |

ACPI should directly connect PCI busses that are enumerated in the ACPI
namespace.  According to the ACPI specification, only devices that cannot
be enumerated through some other mechanism should be given a _HID in
the ACPI namespace, so we must attach to all of these.  We currently do 
this "wrong" by detecting host-PCI bridges in the configuration space for 
bus 0.

Also, acpi_pcib0 and acpi_pcib1 may have different _SEG values.  This is 
probably going to show up in SystemIO machines, and will force us to use 
similar techniques to the Alpha 'hose' stuff.

Note that I don't consider battery devices as children of the EC.  They 
may use methods that access the EC's space, but they are not defined in 
its' scope.

>      +-----+---------+----+-----------+
>      |     |              |           |
>     isab  pcib           foo      acpi_pci<- enumulate name space and attach
>      |     |                                 device_t-acpi_device
>      |    pci                                 list by function number

I don't think that the acpi_pci device is required, because ACPI should 
not enumerate any PCI devices.  Perhaps I am wrong, though, since this 
would let us use a technique like pcibios_identify() does to find and save
the information for later use.  This would disconnect the PCI and ACPI
code very nicely.

The acpi_pcib device should have a method that can be invoked by a child
PCI bus to obtain information on a given bus/device/function number, eg.

	Device(USB_) {
		Name(_ADR, 0x00070002)
		Name(_PRW, Package(0x2) {
			0x8,
			0x1,
		})
	}

A "normal" device driver attaching to bus 0, device 7, function 2 should 
be able to look this up and do something useful with it.  I don't know 
*what* it should do yet; I have not thought about this very much yet.

We also need to add support for the extra PCI/ACPI information in PCI 
configuration space (Dx states).

>      |     |
>      |    +-+--+-+
>      |    |      |
>      |        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_isa - this is like the pnpbios device.  Agreed.

pnpbios - yes, this can detect the acpi_isa status.

>         	+---------+----------+
>   		|         |          |
> 	       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?

I think that we agree very closely on how this should work, and that our 
disagreement is mostly misunderstanding.  Thanks very much for taking the 
time to draw these diagrams out and discuss your ideas.

I have looked at the enumerator code that you sent in your last patch 
kit.  I'm still not entirely sure that I think it's the right way to do 
this, but again I may not understand you correctly.  I am still reading 
and thinking about it.

acpi_probe_children currently probes all scopes.  I agree with you that 
this is not the right way to do it.

You correctly say that we should probe _PR_, _TZ_ and _SB_ scopes only.

I believe that the two-pass scan of these scopes is correct; the first 
pass *only* identifies ACPI handles and attaches placeholder devices.

I do not know how we should sort these devices.  We can control the order 
in which they are attached - should we attach them breadth-first?  (This 
sounds right to me.)

Should we sort them based on their device type?

Should we evaluate their _INI method before attempting to probe their 
children? (The sample OSPM code does this).  

Should we evaluate their _STA method before attaching them?  (I think no -
we should *always* attach regardless of _STA, since it may change at
runtime).

Thank you for your thoughts.  Suggestions?


-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E


