From owner-acpi-jp@jp.freebsd.org  Fri Oct  6 16:36:39 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id QAA25458;
	Fri, 6 Oct 2000 16:36:39 +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 QAA25453
	for <acpi-jp@jp.freebsd.org>; Fri, 6 Oct 2000 16:36:38 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1])
	by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id QAA48418
	for <acpi-jp@jp.freebsd.org>; Fri, 6 Oct 2000 16:34:55 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Message-Id: <200010060734.QAA48418@shidahara1.planet.sci.kobe-u.ac.jp>
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Thu, 05 Oct 2000 20:46:13 MST."
             <200010060346.e963kDh04189@mass.osd.bsdi.com>
Date: Fri, 06 Oct 2000 16:34:55 +0900
From: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 803
Subject: [acpi-jp 803] 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 <200010060346.e963kDh04189@mass.osd.bsdi.com>, Mike Smith $B$5$s$$$o$/(B
:

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

Agreed,You mentions multi host-bus bridge architecture.
 I have never mentioned about multi host-bus bridge architecture,
because I am not rich enough to buy such machine:-).
If you say attach all pci bridge (including PCI-PCI bridge)
I think you can't do without duplicating the bridge 
because current pcib code automatically attach pci under the pcib.

In your diagram, 'acpi_pcib' is 'pcib', isn't it.In our archtecture,
different from NetBSD, same sort of device have same name.
Both nexus-pcib driver and pci-pcib driver is named 'pcib'.

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

Yes, it  depend on AML in my idea.If the AML code is,for example,for 
my machine, TP240
(http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/TP240.asl?rev=1.1&cvsroot=freebsd-jp),
the battery is attached directly under _SB_ and in this AML code, 
checks whether EC driver is ready.
But If the code is Matsuda-san's machine NEC VersaProNX,
(http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/VersaProNX.asl?rev=1.1&cvsroot=freebsd-jp),
battery etc is directly under EC(\_SB.PMU5).And in this machine,
AML do not check EC driver existance.I think it is because they 
assume battery related code always accessed after EC,its parent.

I think battery lives under either acpi root name space or EC name space.

..Oh, in this machine ,PMU5 is directly under _SB_, so resource 
management code should also lives in acpi root (or namespace holder) driver.
Acpi root should be act something like ISA.

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

It is true it requires such technique(And actually more complicated 
problem exists: some machine has duplicated _ADR values in same 
namespace.)But I convince it is needed in two reasons:
1.Determine which driver to attach isa name space.
 In ACPI name space structure, we seldom can determine ISA bus by _HID.
2.PCI bus bridge support.
 I  wrote pci-pcib bridge in the diagram.There are some systems that
have PCI-PCI bridge with the acpi name space is registerd.
It is for PCI routing table and child device of the bridge has 
special named object about power management or Ejectable device 
like docking station.We need to add PCI space handler for
the bridge if we want to access objects under the bridge correctly.
Or default PCI bus number is used,and this is wrong.


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

In this code, we should get gpe register number 8 rise event,
and record S1 as maximam depth of sleep to the device send request to
wakeup.
This event need not be catched by OS.

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

 Agree. I have had good chance to arrange my thought.And I recognize
there is not so big gap  between your idea and my idea.

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

I think we should *always* add device regardless of _STA. And disable 
probing if _STA say it is not present.
When _STA may change, device re-enumulation request will come from 
ACPICA to parent namespace if the _STA of device is change so freqently
and bus have the notification handler. If there is no such event,
we can write a code to be able to request re-enumulation from userland.

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 


