From owner-acpi-jp@jp.freebsd.org  Wed Oct 11 12:40:18 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id MAA09049;
	Wed, 11 Oct 2000 12:40:18 +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 MAA09044
	for <acpi-jp@jp.freebsd.org>; Wed, 11 Oct 2000 12:40:17 +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 e9B3gFh04186
	for <acpi-jp@jp.freebsd.org>; Tue, 10 Oct 2000 20:42:16 -0700 (PDT)
	(envelope-from msmith@mass.osd.bsdi.com)
Message-Id: <200010110342.e9B3gFh04186@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 "Tue, 10 Oct 2000 11:01:59 +0900."
             <200010100201.LAA69689@shidahara1.planet.sci.kobe-u.ac.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 10 Oct 2000 20:42:15 -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 847
Subject: [acpi-jp 847] Re: Latest ACPI megapatch update 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org

> Oh, sorry I wrote direct mail to Mike,so I resent to acpi-jp ML.

My turn for apologies; the bsdi.com DNS has been down and I have been 
unable to send mail for the last ~18 hours. 8(

> > http://people.freebsd.org/~msmith/acpica-bsd-20001008.tar.gz
> >
> >New in this patch:
> >
> > - Fixes for the EC code (error handling)
> 
> > - Host:PCI bridges are now detected and attached using ACPI rather than
> >   by rummaging in PCI configuration space.  (If this fails, we fall back
> >   to the old techniques).
> 
> In my machine, EC is now *NOT* detected. It probablly due to the handling 
> of device enumlation and resource management. Are you sure initialize 
> resources for the device which is directly attached to acpi0?

I may have broken something while trying to get my EC working.  I *might* 
have a workaround now, at least enough to see it probe.  Any ideas what 
might be wrong?

> And I found pci0 is directly attached to acpi0. I think it is *WRONG*.
> acpi driver should *NOT* be act as HOST PCI BRIDGE, but act as rather 
> like ISA(namely CPU ISA).

I'm not sure I understand you here, but let me talk a bit about this.  
I've been working on it for the last couple of days, and it's a 
moderately complicated problem. 8(

I have tried three different approaches.  They all work, and I'm happy 
with using any one of them:

1)  nexus       2)   nexus               3)  nexus
      |                |                       +----------+
    acpi0            acpi0                     |          |
      |                +-----------+         acpi0    nexus_pcib0
   acpi_pci0           |           |           |          |
      |             acpi_pci0     pci0      acpi_pci0    pci0
     pci0

Approach 1) is logically clean, assuming that it is appropriate for a
device to be a child of its enumerator.  It works OK, but it forces
acpi_pci0 to have lots of methods.  It also looks ugly at boot time, which
will upset some people.  It also wastes some code.  A modified version 
would put a "generic" host:pci bridge driver inbetween acpi_pci0 and 
pci0.  I like this a bit more.

Approach 2) works very well, as long as we accept that acpi has to know 
how to be a parent to a host:pci bridge.  I like this technique because 
acpi is in a good position to detect and manage IRQ routing information.
We also get to detect and create the PCI busses before the nexus_pci code 
does, which helps keep the nexus_pci code clean.  You could also put the 
"generic" host:pci bridge inbetween acpi0 and pci0.

Approach 3) is also logically clean, in that it behaves like the ISA case 
where acpi_pci0 is an enumerator for the nexus.  There are problems with 
this technique - the nexus_pcib_identify hook runs before acpi_pci_attach 
runs, and it will create nexus_pcib instances that may duplicate ones 
that are going to be created by acpi_pci_attach.  Because the nexus_pcib 
code runs first, there is no way to detect ACPI correctly.  It might be 
possible for the ACPI code to detect these devices and fix them up, but 
that would also be ugly.  It would still be possible to handle IRQ 
routing information in this architecture, but it will require some more 
work.  That's not all bad though, because we also want to get IRQ routing o
information from other sources.

In summary; Approach 3) is more "right", but the only way to make it work 
"right" is going to be for acpi_pci to be smart enough to find PCI busses 
that have already been created by nexus_pci and "fix" them.  Because this 
approach uses the common nexus_pcib code, that isn't very hard. 

Another item that I have been looking at is the creation of the more 
generic host:pci bridge driver, which could be attached to any parent that
understands it.  I think we can use this for the Alpha as well.  This is 
important for implementing PCI interrupt routing support.  It might be 
possible to merge the current PCI bridge driver with this, but I have not 
studied the code yet.

> Then my *REQUEST*.
> - Rename your acpi_pci.c to acpi_pcib.c and pci0 is attached to the device
> defined in acpi_pcib.c . If you name the driver 'pcib', it will save 
> one line for pci.c (and kldstat -v output). But if you think it confusing
> convention(I think so too), I will not object to you about naming
> it as 'acpi_pcib'.
> 
> - Delete pcib compatible ivar variables and move it to acpi_pcib.

This is like Approach 1.  I'm OK with doing this too, but tell me what 
you think about Approach 3.

> (I want to remove the manipulationto get/set ACPI_HANDLE. 

The ACPI_HANDLE ivar is essential; I don't know of any other way to do 
what it does.  The 'magic' and 'private' ivars are also necessary, 
although I don't like them very much either.

> And I want to add isa compatible ivar variables.)

This would be very bad.  We don't want ISA ivars in the acpi_device 
structure.  If a device looks like an ISA device, it should be connected 
to an ISA bus.  I may be misunderstanding you here though.

> - Fix resource handling to be sure to initialize resource.

I think this is already done correctly.  I haven't checked though.  When 
I was writing the ACPI-PnP resource enumerator I realised that we have to 
change the way that PnP data is connected to ISA devices (we should save 
the raw data and only parse it when the device has a match).  There are 
other complications here as well, of course.  I need to do this soon.

> > - Print the current temperature in detected thermal zones (just cosmetic,
> >   and reveals that some machines are a bit confused already).
> 
> Shall we determine API for templature meter? It is my initial interest for
> ACPI ,indeed, as a author of intpm(4) .

Interestingly, temperature measuring (and thermal control) were my 
initial interest as well.

As I've mentioned before, I like sysctl.

 sysctl acpi._TZ_.0._TMP

for example.  There should be other nodes that give eg. the device(s) in 
the zone, switching points, current status, etc. (_PSV, _CRT, _ACx, ...)

I don't have any strong preference on this though.  If you have some 
ideas you have thought out, and want to write the code, please do!  The 
worst that is going to happen is that your ideas will get improved once 
you start. 8)

Regards,
Mike

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


