Linux/ACPI 2.4 release status

Folks,
2.4.23 shipped -- and I'd like to thank all of you for helping build the best stable ACPI kernel yet!

There is a new 2.4.24 BK tree on bkbits and corresponding patch directory on kernel.org (below). The latest ACPI patch integrated with 2.4.24 will live there. At the same time, I'll also export the latest ACPI patch backported to the 2.4.22 and 2.4.23 BK trees and patch directories.

The latest patch (below) contains two ACPICA updates, as well as a handful of other patches. Please try it out and let me know how it goes.

Yes, this is a good time to remind me about, or update and re-send patches that we were not able to handle in time for 2.4.23.

thanks,
-Len
----

bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.4.24
or ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.4.24-pre1/acpi-20031203-2.4.24-pre1.diff.gz

This will update the following files:

 arch/i386/kernel/mpparse.c         |    8 -
 arch/i386/kernel/smpboot.c         |    2 
 drivers/acpi/Config.in             |    3 
 drivers/acpi/dispatcher/dsinit.c   |    4 
 drivers/acpi/dispatcher/dsmethod.c |    4 
 drivers/acpi/dispatcher/dsmthdat.c |   45 ++++--
 drivers/acpi/dispatcher/dsopcode.c |   22 +-
 drivers/acpi/dispatcher/dswexec.c  |   22 ++
 drivers/acpi/dispatcher/dswload.c  |    8 -
 drivers/acpi/dispatcher/dswscope.c |    8 -
 drivers/acpi/events/evgpe.c        |   59 +++-----
 drivers/acpi/events/evgpeblk.c     |    5 
 drivers/acpi/events/evmisc.c       |    3 
 drivers/acpi/events/evregion.c     |  134 ++++++++++++------
 drivers/acpi/events/evrgnini.c     |   32 +++-
 drivers/acpi/events/evxfregn.c     |   24 ++-
 drivers/acpi/executer/exdump.c     |   50 +++---
 drivers/acpi/executer/exfldio.c    |  184 ++++++++++++-------------
 drivers/acpi/executer/exmisc.c     |    6 
 drivers/acpi/executer/exmutex.c    |   12 -
 drivers/acpi/executer/exoparg1.c   |    3 
 drivers/acpi/executer/exoparg3.c   |    5 
 drivers/acpi/executer/exprep.c     |    4 
 drivers/acpi/executer/exregion.c   |   10 -
 drivers/acpi/executer/exresolv.c   |    6 
 drivers/acpi/executer/exresop.c    |    4 
 drivers/acpi/executer/exstore.c    |    3 
 drivers/acpi/executer/exsystem.c   |   21 ++
 drivers/acpi/hardware/hwacpi.c     |   13 -
 drivers/acpi/hardware/hwregs.c     |   12 -
 drivers/acpi/hardware/hwsleep.c    |   89 ++++++++----
 drivers/acpi/namespace/nsaccess.c  |    8 -
 drivers/acpi/namespace/nsalloc.c   |    7 
 drivers/acpi/namespace/nsdump.c    |   37 ++---
 drivers/acpi/namespace/nsdumpdv.c  |    2 
 drivers/acpi/namespace/nsinit.c    |   63 +++++---
 drivers/acpi/namespace/nsobject.c  |    7 
 drivers/acpi/namespace/nssearch.c  |    4 
 drivers/acpi/namespace/nsutils.c   |    6 
 drivers/acpi/namespace/nsxfname.c  |    2 
 drivers/acpi/parser/psargs.c       |    4 
 drivers/acpi/parser/psparse.c      |    4 
 drivers/acpi/parser/psxface.c      |   34 +++-
 drivers/acpi/processor.c           |   73 ++++++++-
 drivers/acpi/resources/rscalc.c    |    4 
 drivers/acpi/resources/rscreate.c  |    2 
 drivers/acpi/resources/rsdump.c    |   18 --
 drivers/acpi/resources/rsirq.c     |   38 ++---
 drivers/acpi/resources/rslist.c    |    4 
 drivers/acpi/tables.c              |   30 ++--
 drivers/acpi/tables/tbget.c        |   10 -
 drivers/acpi/tables/tbgetall.c     |    3 
 drivers/acpi/tables/tbrsdt.c       |    3 
 drivers/acpi/tables/tbxface.c      |    2 
 drivers/acpi/tables/tbxfroot.c     |    3 
 drivers/acpi/thermal.c             |    1 
 drivers/acpi/utilities/utalloc.c   |   55 -------
 drivers/acpi/utilities/utdebug.c   |    2 
 drivers/acpi/utilities/utdelete.c  |    4 
 drivers/acpi/utilities/uteval.c    |    4 
 drivers/acpi/utilities/utglobal.c  |   99 +++++++++++++
 drivers/acpi/utilities/utobject.c  |   28 ---
 include/acpi/acconfig.h            |    4 
 include/acpi/acevents.h            |   11 +
 include/acpi/acglobal.h            |    3 
 include/acpi/acmacros.h            |   27 +--
 include/acpi/acobject.h            |   35 ++--
 include/acpi/acutils.h             |    8 +
 68 files changed, 884 insertions(+), 570 deletions(-)

through these ChangeSets:

<[email protected]> (03/12/11 1.1063.46.61)
[ACPI] Update Linux to ACPICA 20031203 (Bob Moore)

Changed the initialization of Operation Regions during subsystem init
to
perform two entire walks of the ACPI namespace; The first to
initialize
the regions themselves, the second to execute the _REG methods. This fixed some interdependencies across _REG methods found on some
machines.

Fixed a problem where a Store(Local0, Local1) could simply update the object reference count, and not create a new copy of the object if
the
Local1 is uninitialized.

Implemented support for the _SST reserved method during sleep transitions.

Implemented support to clear the SLP_TYP and SLP_EN bits when waking
up,
this is apparently required by some machines.

When sleeping, clear the wake status only if SleepState is not S5.

Fixed a problem in AcpiRsExtendedIrqResource() where an incorrect pointer arithmetic advanced a string pointer too far.

Fixed a problem in AcpiTbGetTablePtr() where a garbage pointer could
be
returned if the requested table has not been loaded.

Within the support for IRQ resources, restructured the handling of
the
active and edge/level bits.

Fixed a few problems in AcpiPsxExecute() where memory could be leaked under certain error conditions.

Improved error messages for the cases where the ACPI mode could not
be
entered.

<[email protected]> (03/12/11 1.1063.46.60)
[ACPI] update Linux to ACPICA 20031029 (Bob Moore)

Fixed a problem where a level-triggered GPE with an associated _Lxx control method was incorrectly cleared twice.

Fixed a problem with the Field support code where an access can occur beyond the end-of-region if the field is non-aligned but extends to
the
very end of the parent region (resulted in an AE_AML_REGION_LIMIT exception.)

Fixed a problem with ACPI Fixed Events where an RT Clock handler
would
not get invoked on an RTC event. The RTC event bitmasks for the PM1 registers were not being initialized properly.

Implemented support for executing _STA and _INI methods for Processor objects. Although this is currently not part of the ACPI
specification,
there is existing ASL code that depends on the init-time execution of these methods.

Implemented and deployed a GetDescriptorName function to decode the various types of internal descriptors. Guards against null
descriptors
during debug output also.

Implemented and deployed a GetNodeName function to extract the 4-character namespace node name. This function simplifies the debug
and
error output, as well as guarding against null pointers during
output.

Implemented and deployed the ACPI_FORMAT_UINT64 helper macro to
simplify
the debug and error output of 64-bit integers. This macro replaces
the
HIDWORD and LODWORD macros for dumping these integers.

Updated the implementation of the Stall() operator to only call AcpiOsStall(), and also return an error if the operand is larger than
255. This preserves the required behavior of not relinquishing the processor, as would happen if AcpiOsSleep() was called for "long stalls".

Constructs of the form "Store(LocalX,LocalX)" where LocalX is not initialized are now treated as NOOPs.

Cleaned up a handful of warnings during 64-bit generation.

Fixed a reported error where and incorrect GPE number was passed to
the
GPE dispatch handler. This value is only used for error output, however. Used this opportunity to clean up and streamline the GPE dispatch code.

<[email protected]> (03/12/11 1.1063.46.59)
[ACPI] revert two fixes in preparation for ACPICA merge

<[email protected]> (03/12/10 1.1063.46.58)
[ACPI] set APIC ACPI SCI OVR default to level/low

     http://bugzilla.kernel.org/show_bug.cgi?id=1351

<[email protected]> (03/12/10 1.1063.46.57)
[ACPI] change hard-coded IO width to programmable width (Shaohua
David Li)

     http://bugzilla.kernel.org/show_bug.cgi?id=1349

<[email protected]> (03/12/02 1.1063.46.56)
[ACPI] add warning to thermal shutdown (Pavel Machek)

<[email protected]> (03/12/02 1.1063.46.55)
[ACPI] handle sparse APIC-IDs in the face of reduced NR_CPUS

<[email protected]> (03/11/20 1.1063.46.54)
[ACPI] fix xconfig failure (Matt Wilcox)
http://bugzilla.kernel.org/show_bug.cgi?id=1568

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/

Hi Len

yes in my laptop it is very stable too. thanks

have you any plan? to integrated cpufreq that cames in 2.22-ac4 kernels. or does anybody have any implantation of cpufreq for kernel 2.4.23?

Sérgio M B




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Thus wrote Sérgio Monteiro Basto:

Current snapshots of CPUFreq (both for 2.4 and 2.6) can be found here:
http://ftp.linux.org.uk/pub/linux/cpufreq/

Best regards,

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

I don't think it's up to acpi folks to integrate cpufreq. The 2 works are definitely different due to the fact that cpufreq claims at first to be architecture independant (you have to consider arm, sparc, ppc...).

Of course, an ACPI based cpufreq driver for 2.4 will be fine, and perhaps an acpi governor based both on input from thermal stuff, load of the system may be good, who knows.

Note that acpi use cpufreq api in 2.[56].

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Here's one:

This patch against the current 2.4 tree removes a bunch of ill-advised code I added to get _TRA information from PCI root bridges.

This was the wrong approach because for one thing, it only handled one MEM window and one IO window, and root bridges may have several of each.

This patch can be applied for both 2.4 and 2.5. ia64 was the only user of this code, and we no longer need it. The current approach is to walk the _CRS in pcibios_scan_root() using acpi_walk_resources().

diff -u -ur 2.4/drivers/acpi/pci_root.c 2.4-patched/drivers/acpi/pci_root.c
@@ -61,8 +61,6 @@
 	acpi_handle		handle;
 	struct acpi_pci_id	id;
 	struct pci_bus		*bus;
-	u64			mem_tra;
-	u64			io_tra;
 };
 
 static LIST_HEAD(acpi_pci_roots);

@@ -114,97 +112,6 @@
 	}
 }
 
-void
-acpi_pci_get_translations (
-	struct acpi_pci_id	*id,
-	u64			*mem_tra,
-	u64			*io_tra)
-{
-	struct list_head	*node = NULL;
-	struct acpi_pci_root	*entry;
-
-	/* TBD: Locking */
-	list_for_each(node, &acpi_pci_roots) {
-		entry = list_entry(node, struct acpi_pci_root, node);
-		if ((id->segment == entry->id.segment)
-			&& (id->bus == entry->id.bus)) {
-			*mem_tra = entry->mem_tra;
-			*io_tra = entry->io_tra;
-			return;
-		}
-	}
-
-	*mem_tra = 0;
-	*io_tra = 0;
-}
-
-
-static u64
-acpi_pci_root_bus_tra (
-       struct acpi_resource	*resource,
-       int			type)
-{
-	struct acpi_resource_address16 *address16;
-	struct acpi_resource_address32 *address32;
-	struct acpi_resource_address64 *address64;
-
-	while (1) {
-		switch (resource->id) {
-		case ACPI_RSTYPE_END_TAG:
-			return 0;
-
-		case ACPI_RSTYPE_ADDRESS16:
-			address16 = (struct acpi_resource_address16 *) &resource->data;
-			if (type == address16->resource_type) {
-				return address16->address_translation_offset;
-			}
-			break;
-
-		case ACPI_RSTYPE_ADDRESS32:
-			address32 = (struct acpi_resource_address32 *) &resource->data;
-			if (type == address32->resource_type) {
-				return address32->address_translation_offset;
-			}
-			break;
-
-		case ACPI_RSTYPE_ADDRESS64:
-			address64 = (struct acpi_resource_address64 *) &resource->data;
-			if (type == address64->resource_type) {
-				return address64->address_translation_offset;
-			}
-			break;
-		}
-		resource = ACPI_PTR_ADD (struct acpi_resource,
-				resource, resource->length);
-	}
-
-	return 0;
-}
-
-
-static int
-acpi_pci_evaluate_crs (
-	struct acpi_pci_root	*root)
-{
-	acpi_status		status;
-	struct acpi_buffer	buffer = {ACPI_ALLOCATE_BUFFER, NULL};
-
-	ACPI_FUNCTION_TRACE("acpi_pci_evaluate_crs");
-
-	status = acpi_get_current_resources (root->handle, &buffer);
-	if (ACPI_FAILURE(status))
-		return_VALUE(-ENODEV);
-
-	root->io_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
-			buffer.pointer, ACPI_IO_RANGE);
-	root->mem_tra = acpi_pci_root_bus_tra ((struct acpi_resource *)
-			buffer.pointer, ACPI_MEMORY_RANGE);
-
-	acpi_os_free(buffer.pointer);
-	return_VALUE(0);
-}
-
-
 static int
 acpi_pci_root_add (
 	struct acpi_device	*device)

@@ -289,10 +196,8 @@
 	root->id.function = device->pnp.bus_address & 0xFFFF;
 
 	/*
-	 * Evaluate _CRS to get root bridge resources
 	 * TBD: Need PCI interface for enumeration/configuration of roots.
 	 */
- 	acpi_pci_evaluate_crs(root);
 
  	/* TBD: Locking */
  	list_add_tail(&root->node, &acpi_pci_roots);

diff -u -ur 2.4/include/acpi/acpi_drivers.h 2.4-patched/include/acpi/acpi_drivers.h
@@ -162,7 +162,6 @@
 
 int acpi_pci_root_init (void);
 void acpi_pci_root_exit (void);
-void acpi_pci_get_translations (struct acpi_pci_id* id, u64* mem_tra, u64* io_tra);
 
 /* ACPI PCI Interrupt Link (pci_link.c) */
 

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/

Bjorn.

Is it possible that some ia32 or x86_64 platforms might depend on this code and miss it because they lack the _CRS walk that ia64 has in pcibios_scan_root()?

thanks,
-Len

There are no current users of this code in the standard tree, according to grep. And the code is broken in the sense that it only handles a single MEM and a single IO window, and bridges often have several MEM windows.

Bjorn

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/