From owner-acpi-jp@jp.freebsd.org  Wed Oct 11 14:09:43 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id OAA17145;
	Wed, 11 Oct 2000 14:09:43 +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 OAA17140
	for <acpi-jp@jp.freebsd.org>; Wed, 11 Oct 2000 14:09:42 +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 OAA76793
	for <acpi-jp@jp.freebsd.org>; Wed, 11 Oct 2000 14:08:10 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Message-Id: <200010110508.OAA76793@shidahara1.planet.sci.kobe-u.ac.jp>
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Tue, 10 Oct 2000 20:42:15 MST."
             <200010110342.e9B3gFh04186@mass.osd.bsdi.com>
Date: Wed, 11 Oct 2000 14:08:10 +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 849
Subject: [acpi-jp 849] Re: Latest ACPI megapatch update 
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 <200010110342.e9B3gFh04186@mass.osd.bsdi.com>, Mike Smith $B$5$s$$$o$/(B
:
>> 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?

I'm trying to find, but I noticed that It fails to get resources,at least.

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

I think this is the BEST approach of all.


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

Yes, I think Approach 1 is the best approach of all.

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

Note that the remarks in the bracket is *MY* plan.
In your approach, this may be not appropriate, I think.
I want to discuss about these issue after I write the code 
that realize my idea.So remarks about them is the description 
of my idea.

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

Yes. Logically it have as same charactaristic as what ivar variables have.
But,from a view point of module dependency,we need not to use IVAR interface
to get ACPI_HANDLE,but we can use direct fuction call. It is because 
what shall the code do next after it get ACPI_HANDLE. The code 
will call function in acpi driver using ACPI_HANDLE. So acpi module dependency
is needed if the driver need to get ACPI_HANDLE.

         ---------
Generally one of the aim of DEVMETHOD or IVAR interface is to resolve module
dependency. If we use direct function call to access parent bus(yes ,
we can achieve OO like approach with this way with less overhead), we cannot
load BI driver that have bus front end the target not yet have. For example,
you can't load if_an.ko if the pccard interface is compiled in.We should 
load if_an.ko and one of if_an_isa.ko ,if_an_pci.ko,if_an_pccard.ko instead if 
we do not use DEVMETHOD or IVAR.With this approach, if_an.ko have no
module dependency other than kernel itself.

DEVMETHOD and IVAR is similer idea,but IVAR is the way to avoid defining
DEVMETHOD for simplest operation.
In C++
 class SampleBusOperation::BusOperation{
	int foo;
	int bar;
	....
   public:
	int getfoo();
	void setfoo(int);
	int getbar();
	void setfoo(int);
	
	really_needed_method(....);
};
IVAR interface is counterpart of get* and set* method in this C++ class.
and DEVMETHOD defined by class specific *.m is counterpart of 
really_needed_method method in this method.

	-------------------

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

IVAR structure that have in ISA driver  and IVAR interface is different thing.
I think we can implement ISA-pnp like IVAR interface without ISA IVAR
structure but with ACPI_HANDLE.We don't need static hint support for 
acpi root bus , I surely think.

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

Ok.It's my turn.I'll find the bug about what prevent the driver to attach,
because the bug is appear in my machine,not yours.

>
>> > - 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 *think* _TMP may also have device interface so that it can use non-acpi
device like the chip LM7X in non-acpi machine. I want to modify the application
like wmhm , consolelm healthd ....(and my lm.c .) etc.Because they use 
dangerous approach to get the infomation from LMXX.*The right* way is
to provide them to safety and integrated interface by kernel driver.

My main request is to use idea Approach 1 and now I relief that you  hear me.

Thanks.

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 

