From owner-acpi-jp@jp.freebsd.org  Sun Oct  8 14:02:53 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id OAA62330;
	Sun, 8 Oct 2000 14:02:53 +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 OAA62323
	for <acpi-jp@jp.freebsd.org>; Sun, 8 Oct 2000 14:02:51 +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 e9854ph00803
	for <acpi-jp@jp.freebsd.org>; Sat, 7 Oct 2000 22:04:51 -0700 (PDT)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200010080504.e9854ph00803@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 16:34:55 +0900."
             <200010060734.QAA48418@shidahara1.planet.sci.kobe-u.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 07 Oct 2000 22:04:51 -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 823
Subject: [acpi-jp 823] Re: Device Enumlation idea. 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

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

8)  Actually, they are becoming very cheap; even the low-end RCC-bases 
boards like the ASUS CUR-DLS are dual host-PCI systems.

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

The ACPI specification requires that only host-PCI bridges be enumerated 
in the ACPI namespace with a _HID method.  Other bridges may be listed, 
but they will only have _ADR methods, and we would not treat them as 
host-PCI bridges.

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

The naming is very confusing; the bus should be "pcibus", the bridge 
should be "hostpcibridge" or some other mouthful. 8)

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

This is ACPI compliant.

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

This violates the spec.

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

That should be what happens now; the ACPI root is capable of managing 
(and printing) child resources.  I think I'll add GPE bits as child 
resources as well.

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

There is no requirement that ISA devices be listed as children of the PCI 
bus...

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

Hmm.  Do you have an example for 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).
> 
> 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.

I haven't looked at this again yet.  At the moment, the driver has to be 
smart enough to look at _STA itself and decide whether to attach or not.  
I think a better idea would be to let the driver probe OK, but not 
actually call the attach routine until _STA returns successful.  This 
would be fairly easy to implement, but we can leave it for a while now 
(since we have other problems to solve first 8).

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


