From owner-acpi-jp@jp.freebsd.org  Fri Aug  4 14:50:28 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id OAA91593;
	Fri, 4 Aug 2000 14:50:28 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (daemon@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id OAA91588
	for <acpi-jp@jp.freebsd.org>; Fri, 4 Aug 2000 14:50:27 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.10.1+3.3W/3.7W-tasogare/smtpfeed 1.07) with ESMTP id e745oNp19574
	for <acpi-jp@jp.freebsd.org>; Fri, 4 Aug 2000 14:50:24 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org
In-Reply-To: <200008040355.MAA34537@miffy.tom-yam.or.jp>
References: <200008040355.MAA34537@miffy.tom-yam.or.jp>
	<200006242137.OAA00259@mass.osd.bsdi.com>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-Id: <20000804145022A.iwasaki@jp.FreeBSD.org>
Date: Fri, 04 Aug 2000 14:50:22 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 313
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 509
Subject: [acpi-jp 509] Re: Hello.
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: iwasaki@jp.freebsd.org

> $B$O$^$@$H$b$&$7$^$9!#(B

$B$$$o$5$-$H?=$7$^$9(B :-)

>   $B0JA0$+$iGyA3$H6=L#$O$"$C$?$N$G$9$,!"$F$b$H$K(B ACPI $B$N:\$C$F$k%^%7%s$,(B
> $B$J$+$C$?$N$H!"EEOCD"$rFI$b$&$H$9$k$H$$$D$b$9$d$9$d$HL2$C$F$7$^$&$?$a$K(B
> $B6qBNE*$J:n6H$KCe<j$;$:$K$$$^$7$?!#(B
> 
>   $B$,!"(BThinkPad 570 $B$rGc$C$F%&%k%H%i%Y!<%9$NJXMx$5$K!V$3$l$O(B FreeBSD $B$G(B
> $B$bMxMQ$;$:$s$P$"$i$:!W$H$$$&$o$1$G!"$<$R:n6H$K2C$($F$$$?$@$-$?$$$HB8$8(B
> $B$^$9!#(B

$B$r$r(B! $B$=$l$G$O(B 4.x $B0J9_$rF~$l$F(B ($B:#F|$"$?$j$N(B CURRENT $B$,$*>)$a(B)$B!"(B
ACPI $B$N%D%j!<$rF~<j$7$F(B usr.sbin/acpi/acpidump $B$r;H$C$F(B ThinkPad 570 
$B$N(B DSDT/ASL $B$rAw$C$F$/$@$5$$$^$7!#(B
 # acpidump -o TP570.dsdt > TP570.asl
$B$H$+$G$9!#(B

>   $B$R$H$^$:$OEEOCD"$rD/$a$J$*$9$N$H!"$"$H%9%+%&%HMQ$b$+$M$F!VEEOCD"$NJb(B
> $B$-J}!WE*$J$b$N$,I,MW$+$J$"!"$J$s$F9M$($F$$$k$H$3$m$G$9!#(B

$B$I$3$K6=L#$,$"$k$+$K$h$C$F$=$l$>$l0c$&$+$b$7$l$^$;$s$,!"(Btakawata $B$5$s$,(B 
[acpi-jp 8] $B$"$?$j$K$^$H$a$FD:$$$F$$$k$N$,0l$D$N;29M$K$J$k$H;W$$$^$9!#(B
$B$"$H!"8=>u$N%3!<%I$r(B USENIX $B$N;~$K(B Mike $B$d(B Doug $B$K@bL@$9$k$H$-$K:n$C$?(B
$B%a%b$HH`$i$HOC$79g$C$?$3$H$r$^$H$a$?$b$N$b$"$k$s$G$9$,!"$3$3$KN.$7$F(B
$B$$$J$+$C$?5$$,$9$k$N$G!"0zMQ$7$F$*$-$^$9!#(B
$B0lIt%=!<%9$N0z$C1[$7$r$7$?8e$J$N$G?)$$0c$$$,$"$j$^$9$,!"(B
ACPI/sys/i386/acpi/			-> ACPI/sys/dev/acpi/
ACPI/sys/conf/{files|options}.i386	-> ACPI/sys/conf/{files|options}
$B$N$h$&$KFI$_BX$($F$/$@$5$$!#$^$?!"(B/dev/acpi $B$O:G6a(B takawata $B$5$s$,@5<0$K(B
major $B$r<h$C$F$/$@$5$j!"(B152 $B$KJQ99$5$l$F$$$^$9!#(B

>   $B$H$$$&$o$1$G$I$&$>$h$m$7$/$*4j$$$7$^$9!#(B

$B$3$A$i$3$=!"$h$m$7$/$*4j$$$7$^$9(B (_ _)
# $B$J$s$@$+$H$C$F$b4r$7$$(B :-)

From: Mike Smith <msmith@freebsd.org>
Subject: Re: ACPI 
Date: Sat, 24 Jun 2000 14:37:48 -0700
Message-ID: <200006242137.OAA00259@mass.osd.bsdi.com>

> (I've quoted the entire message here for Peter and Doug's benefit).
> 
> Thanks very much for the extensive overview and discussion; I think we're 
> all very impressed with how much you've achieved, and your plans for 
> cleaning up and making a patchset sound great.  We should definitely look 
> at merging your code as soon as possible, so we are all eagerly awaiting 
> your diffs. 8)
> 
> As for poor conversational skills - nonsense. You did a great job of 
> explaining things, and I don't think anyone had any problems at all
> understanding your points.  Again, thanks *very* much for coming along 
> and taking the time to share your work - it's greatly appreciated.
> 
> There are a couple of points that we discussed that I think bear a little 
> more clarification - whether you want to take this up now before you 
> produce your patches, or whether we should do these against -current 
> after you've finalised your current work is your decision.
> 
>  - Moving the sources.  Most of the code is machine-independant, and 
>    while I don't expect ACPI to set the non-Intel world on fire, it's 
>    going to be used by the i386 and IA64 ports.  The bulk of the code
>    should be in sys/dev/acpi - I'm not sure that the AML code shouldn't
>    move out of its subdirectory either, since it's all well-named.
>    I'd put the nexus attachment in sys/i386/i386/i386_acpi.c, as well as 
>    the code to assign bus handle/tag for doing the SystemIO/SystemMemory
>    accesses, etc.
> 
>  - We discussed allocating the various OperationRegion items using
>    the resource manager; I think we should do this.  The ACPI code wants 
>    to "own" these regions.  In some cases, they're going to be already 
>    "owned" by eg. the PIIX4, or possibly other devices, and I'm not yet 
>    sure how we should proceed here.  For example:
> 
>         PM1a_EVT_BLK=0x1000-0x1003
> ...
> OperationRegion(PMS, SystemIO, 0x1001, 0x1)
> Field(PMS, ByteAcc, NoLock, Preserve) {
>     PWRS,       1
> }
> 
>    This is in the PIIX4 device and is probably ultimately owned by
> 
> pci0: <Intel 82371AB Power management controller> at 7.3
> 
>    I don't think that we should (in the end) attempt to subvert the 
>    resource manager, but it may be necessary to ignore this for a while. 
> 
>  - The PnPBIOS probe should only be performed if no trustable ACPI was 
>    found.  If I remember correctly, we can get Microsoft's ACPI blacklist
>    from their website, and the loader should make the decision based on 
>    this and the BIOS datestamp as per the "usual rules".  The loader is 
>    going to have to learn something about ACPI as well - I hope that we 
>    can reuse some of the kernel code, but that may not be worth the extra 
>    complexity.
> 
>  - We can easily replace the PnPBIOS enumerator code with similar code 
>    for ACPI.  My recollection of the interface between this and the bus 
>    code was entirely faulty (it's push-driven, not pull-driven).
> 
> That's all I can recall now; I'm sure I've forgotten something. 8)
> 
> > > > Please call me when you have some free time, I'll explain a bit on
> > > > ACPI tools.
> > > 
> > > If you'll be here tomorrow, I've got the bits compiling now, and I'd love
> > > to see how it all fits in to the kernel, etc.  I'll bring John along as
> > > well, since he's very involved in all this and really interested.
> > 
> > OK, I'll be in terminal room at 3:30 PM as I told already to John last
> > night.  My conversation skill is very poor (sorry :-), so I'll try to
> > explain what I want to say by e-mail first.
> > 
> > Directory tour:
> >  - kernel space side
> > 	ACPI/sys/i386/i386/machdep.c	getmemsize() try to get ACPI related
> > 					memory range from SMAP.
> > 
> > 	ACPI/sys/i386/i386/bios.c	bios32_init() try to find RSD PTR
> > 					signature (probe ACPI BIOS).
> > 
> > 	ACPI/sys/i386/acpi/acpi.c	acpi device driver.
> > 
> > 	ACPI/sys/i386/acpi/aml/		AML interpreter code.
> > 					aml_parse.c was originaly developed
> > 					based on dfr's AML disassembler program.
> > 					These files can be compiled and work in
> > 					both of kernel/userland side.
> > 
> > 	ACPI/sys/i386/include/pc/acpi.h The acpi related structs and function
> > 					declaration.  This needs to be installed
> > 					/usr/include/machine/pc/ to compile
> > 					acpi stuff.
> > 
> > 	ACPI/sys/i386/conf/LINT		sample configration of acpi driver and
> > 					AML interpreter.
> > 
> > 	ACPI/sys/conf/{files|options}.i386	file and option configuration
> > 					for ACPI.
> > 
> >  - userland side
> > 	ACPI/usr.sbin/acpi/acpiconf	enabler/disabler and sleeping state 
> > 					transition ioctl requests generator.
> > 
> > 	ACPI/usr.sbin/acpi/acpidump	ASL and AML dump tool (modified dfr's 
> > 					tool a bit).
> > 	ACPI/usr.sbin/acpi/amldb	The debugger for AML interpreter.
> > 
> >  - device file
> > 	/dev/acpi			major/minor should be 210, 0 for the
> > 					time beeing.
> > ACPI device driver:
> > This driver has
> >  - ACPI memory range management
> >  - The pmap stuff for ACPI
> >  - ACPI tables handlers *
> >  - System sleeping state stuff
> >  - Event handler (power/sleep button for now)
> >  - Interrupt handler (for general purpose events maybe incomplete)
> >  - The new-bus interfaces
> >  - ACPI resisters manipulation stuff
> >  - device file manipulation stuff
> >  - Builtin control method code in C for some machines (going to be removed)
> >  - AML interpreter callers for special control methods; _PTS and _WAK *
> > 
> > *: acpi_handle_dsdt() and acpi_execute_{pts|wak}() invoke AML interpreter.
> > 
> > AML interpreter source files:
> >  - aml_amlmem.c	memory manager instance for AML interpreter
> >  - aml_amlmem.h	memory manager instance for AML interpreter
> >  - aml_common.c		common functins for some component
> >  - aml_common.h		common functin declarations and macros for
> > 			kernel/userland compatibility
> >  - aml_env.h		AML execution environment
> >  - aml_evalobj.c	evaluation of named objects
> >  - aml_evalobj.h	evaluation of named objects
> >  - aml_memman.c		generic memory manager
> >  - aml_memman.h		generic memory manager
> >  - aml_name.c		named object and tree manipulation
> >  - aml_name.h		named object and tree manipulation
> >  - aml_obj.c		ACPI object manipulation
> >  - aml_obj.h		ACPI object manipulation and structure declaration
> >  - aml_parse.c		AML parser
> >  - aml_parse.h		AML parser
> >  - aml_region.c		region I/O routines for system resources *
> >  - aml_region.h		region I/O routines for system resources
> >  - aml_status.h		interpreter and debugger execution statuse declaration
> >  - aml_store.c		Store operation implementation
> >  - aml_store.h		Store operation implementation
> > 
> > *: need to be prepared for kernel and userland versions separately
> > 
> > ACPI userland tools:
> >  - acpiconf
> > 	acpiconf [-e] [-d]	write enable/disable value to SMI command port
> > 				(specified in FACP).
> > 	acpiconf -s [0-5]	set sleeping state (only 1 and 5 are implemented)
> > 
> >  - acpidump
> > 	acpidump		print ASL code from DSDT via /dev/mem.
> > 	acpidump -o dsdt_file	print ASL and dump DSDT data block to the file.
> > 	acpidump -f dsdt_file	print ASL code from given dsdt data file.
> > 
> >  - amldb
> > 	amldb dsdt_files...	interpret and execute AML from given dsdt files.
> > 				This has I/O simulator (tiny virtual machine?)
> > 				in order to execute methods in userland.
> > 				Values from/to the I/O simulator can
> > 				be changed by prompt before actual accessing
> > 				occurred.
> > 				Initial content file for simulator is region.ini.
> > 				If -d option was given, file region.dmp will be
> > 				generated (final status of simulator contents).
> > 
> > 	debugger commands are;
> > 
> > s       Single step
> > n       Step program
> > c       Continue program being debugged
> > q       Quit method execution
> > t       Show local name space tree and variables
> > i       Toggle region input prompt
> > o       Toggle region output prompt
> > m       Show memory management statistics
> > r       Run specified method
> > f       Find named objects from namespace.
> > h       Show this messsage
> > 
> > 	example;
> > % ./amldb 3110CT.dsdt.dat
> > Loading 3110CT.dsdt.dat...done
> > AML>f _PS2
> > \_SB_.PCI0.VGA_._PS2.
> > AML>r \_SB_.PCI0.VGA_._PS2
> > Method: Arg 8 From 0x280f13a6 To 0x280f143f
> > ==== Running \_SB_.PCI0.VGA_._PS2. ====
> > AML>s
> > [\_SB_.PCI0.VGA_._PS2. START]
> > Store(0x1, \_SB_.MEM_.IESI)[write(From0, 0x1, 0x100b6810)]
> > [aml_region_write(0, 0, 0x1, 0x100b0000, 0x34080, 0x20)]
> > amldb: region.ini: No such file or directory
> >         [0:0x00@0x100b6810]->[0:0x01@0x100b6810]
> >         [0:0x00@0x100b6811]->[0:0x00@0x100b6811]
> >         [0:0x00@0x100b6812]->[0:0x00@0x100b6812]
> >         [0:0x00@0x100b6813]->[0:0x00@0x100b6813]
> > [read(From0 , 0x100b6810)]
> > [aml_region_read(0, 0, 0x100b0000, 0x34080, 0x20)]
> >         [0:0x01@0x100b6810]
> >         [0:0x00@0x100b6811]
> >         [0:0x00@0x100b6812]
> >         [0:0x00@0x100b6813]
> > DEBUG[read(0, 0x100b6813)&mask:0x1](default: 0x1 / 1) >>
> > 
> > AML>
> > 
> > 	amldb -d		dump contents of I/O simulator when exiting.
> > 
> > 	amldb -s		print memory statistics when exiting.
> > 				AML interpreter has own memory management in
> > 				order to reduce malloc/free calling overhead and
> > 				memory leak possibilities.  Initial memory blocks
> > 				was pre-allocated for each defined-structures
> > 				during compile-time.  If initial memory block is
> > 				consumed totally, then try to obtain many blocks
> > 				at once by calling malloc().  Also normal malloc/
> > 				free() interfaces are supported (with statistics)
> > 				for flexible size memory allocations which can't
> > 				be determined until the interpreter is executed at
> > 				runtime.
> > 				
> > 	amldb -t		print namespace tree when starting.
> > 
> > Additional files for amldb:
> >  - amldb.c			main funcion
> >  - debug.c			debugger
> >  - region.c			userland version of region I/O routines
> > 				using I/O simulator
> > 
> > Data files and dump tools for testing:
> >  - ACPI/util/dfr/acpitest/	ASL code files
> >  - ACPI/util/takawata/acpi/	DSDT data block files (AML)
> > These tools were replaced by acpidump.
> > 
> > Other tools:
> >  - ASL compiler			http://www.teleport.com/~acpi/samples.htm
> >    example)
> > % wine 'asl.exe Trajan.asl'
> > ACPI Source Language Assembler Version 1.0.11 [Jan 18 1999, 17:50:22]
> > Copyright (c) 1996,1999 Microsoft Corporation
> > Compliant with ACPI 1.0 specification
> > 
> > Trajan.asl:
> > lm75.asl:
> > px4smb.asl:
> > NS338.asl:
> > 338_uar1.asl:
> > 338_uar2.asl:
> > 338_prt.asl:
> > 338_fdc.asl:
> > mb_dev.asl:
> > dock.asl:
> > asl(trajan.aml): Image Size=9204, Image Checksum=0x1a
> > 
> >  - ACPI Spec 2.0		http://www.teleport.com/%7Eacpi/2spec.htm
> >  - ACPICA (ACPI Component Archtecture) source code and document
> > 			http://developer.intel.com/technology/iapc/tech.htm
> > 
> > That's all :-) it's still very simple, but system resource accessing
> > facility (ioport and system memory for now) is going to be implemented
> > and controll method execution is becoming true!
> > # but only for limited environment :-)
> > 
