headers
Greg KH | 1 Jun 2006 01:34
Picon

Re: [PATCH 1/2] - Altix: Add initial ACPI support

On Wed, May 31, 2006 at 04:23:20PM -0500, John Keller wrote:
> Index: acpi-support/arch/ia64/pci/pci.c
> ===================================================================
> --- acpi-support.orig/arch/ia64/pci/pci.c	2006-05-31 12:37:50.539921986 -0500
> +++ acpi-support/arch/ia64/pci/pci.c	2006-05-31 14:10:50.889146925 -0500
>  <at>  <at>  -470,10 +470,11  <at>  <at>  pcibios_fixup_resources(struct pci_dev *
>  	}
>  }
>  
> -static void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
> +void __devinit pcibios_fixup_device_resources(struct pci_dev *dev)
>  {
>  	pcibios_fixup_resources(dev, 0, PCI_BRIDGE_RESOURCES);
>  }
> +EXPORT_SYMBOL(pcibios_fixup_device_resources);

EXPORT_SYMBOL_GPL() perhaps?

> --- acpi-support.orig/include/linux/pci.h	2006-05-31 12:37:50.647911309 -0500
> +++ acpi-support/include/linux/pci.h	2006-05-31 14:10:50.989137400 -0500
>  <at>  <at>  -397,6 +397,7  <at>  <at>  extern struct bus_type pci_bus_type;
>  extern struct list_head pci_root_buses;	/* list of all known PCI buses */
>  extern struct list_head pci_devices;	/* list of all devices */
>  
> +void __devinit pcibios_fixup_device_resources(struct pci_dev *);

Don't put __devinit on a function prototype.  It does nothing.

thanks,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jakub Szefer | 1 Jun 2006 02:18
Picon

Enabling ACPI on Asus P4B266

Hi,

I have a Sony with an ASUS P4B266 motherboard which is on the
blacklist for incompatible BIOSes.  dmesg shows "ASUS P4B266
detected: force use of acpi=ht", if I understand correctly
ACPI gets disabled because of the motherboard type and
force=ht has to do with enabling support for hyperthreading?

I would like to make use of ACPI to control my fan speed (it
has two speeds, but right now keeps running at the highest all
the time).  Can I force ACPI to stay on or would this cause
some badness?

Thanks in advance for any advice you can offer,
~ Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
David | 1 Jun 2006 05:11

resume not working

I have a fairly generic laptop I inherited from a relative.  The suspend 
feature works great (from closing the list or via any other method).  The 
only problem is waking it back up.  It doesn't.  The power button is 
supposed to resume it, and it does in Windows.

In my acpi log, the only messages regarding the power button are:

received event "button/power PWRF 00000080 00000002"

I see nothing that has PWBN (which I would assume would resume?).

I'm wondering if this might have something to do with it, but I'm not 
sure:

Handle 0x001C, DMI type 32, 20 bytes.
System Boot Information
         Status: <OUT OF SPEC>

Handle 0x001D, DMI type 127, 4 bytes.
End Of Table

Wrong DMI structures count: 30 announced, only 29 decoded.

Where can I start working on this?

Thanks,
David

--

-- 
"I find your lack of faith disturbing."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brown, Len | 1 Jun 2006 09:05
Picon
Favicon
Gravatar

ACPI locking

Bob,
I've updated
http://bugzilla.kernel.org/show_bug.cgi?id=6612
(the button state clear on S3 resume bug)
asserting that acpi_set_register() needs to be able
to be called at interrupt-time, and should be using
a spin-lock underneath, not a mutex or semaphore.

I've filed
http://bugzilla.kernel.org/show_bug.cgi?id=6634
to address that specific issue and the bigger problem
that ACPICA is using semaphores when it would be more
efficient to use mutexes on Linux, and perhaps
lower overhead still to use spin-locks.

A quick scan of the locking code looks like:

1. global lock to handle OS vs EC -- a special case.
	okay.

2. acpi_gbl_gpe_lock
	only current user of
	acpi_os_create_lock()/acpi_os_delete_lock()
	acpi_os_acquire_lock()/acpi_os_release_lock()

	On Linux, 
	this translates to spin_lock_irqsave()/spin_lock_irqrestore()

3. NUM_MUTEX
	This array of mutexes is implemented using semaphores
(Continue reading)

Permalink | Reply | 0 comments |
headers
Johan Vromans | 1 Jun 2006 18:29
Picon
Favicon
Gravatar

Re: Was: Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

Berthold Cogel <cogel <at> rrz.uni-koeln.de> writes:

> It would be nice to have this in the kernel.

What steps are needed to get this in the kernel?

-- Johan
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Moore, Robert | 1 Jun 2006 20:43
Picon
Favicon
Gravatar

RE: ACPI locking

It has been a while since we have looked at the ACPICA locking stuff,
and I suppose now is as good a time as any. I am also concerned with the
Linux-only implementation and deployment of the OsWaitEventsComplete
interface, in terms of how the locking interacts with it. (I am also
concerned with why only Linux has requested this interface.)

The historical note on the OSL semaphore interfaces is that we felt that
if a "mutex" object was available in the host OS, it could be used for
the case where the OsCreateSemaphore() call specified a MaxUnits
parameter of one (a binary semaphore) - rather than having an entirely
separate "mutex" OSL interface. The OSL spinlock interfaces were added
later and are currently only used in a limited way. Of course, when the
day comes that the ACPICA code is fully integrated into the host OS, the
OSL interfaces will probably be replaced by native OS calls, so we
always thought of the OSL interface as a somewhat interim oil-slick,
therefore we wanted to minimize the number of different interfaces to
it.

3) The list of global mutexes should be looked at. I suspect that a
couple of them are obsolete and not used or could be merged with
another. As far as spinlock vs. mutex, we certainly may be able to
replace some mutexes with spinlocks, but certainly not all. The best
example of where a mutex is required would be the Interpreter mutex,
another example would be the Namespace mutex where we need to lock the
namespace while possibly extensive allocations take place during a
dynamic table load. Where we could possibly use a spinlock is to replace
the ACPI hardware mutex.

5.1) We may be able to delete the units parameter for OsWaitSemaphore,
it's just there to match Signal.  We use the units parameter with signal
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Drake | 1 Jun 2006 23:04
Picon
Favicon

Most interrupts are edge-triggered, non-APIC system

Hi,

João Oliveirinha reported a bug related to the sky2 network driver on 
the Gentoo bugzilla. Stephen Hemminger (sky2 author) kindly helped 
diagnose the issues, and he believes that one of the reasons why things 
are running sub-optimally is because the interrupt assigned to sky2 is 
edge-triggered (NAPI requires things to be level-triggered).

The system is a bit odd in that even on the latest BIOS, APIC support is 
apparently completely non-functional (or maybe just non-existent?). Even 
when the "lapic" parameter is used, ACPI appears to be used exclusively 
for interrupt routing.

This is a Toshiba M40-298 laptop.

Here is the interrupts map:

            CPU0
   0:      47094          XT-PIC  timer
   1:        541          XT-PIC  i8042
   2:          0          XT-PIC  cascade
   9:         13          XT-PIC  acpi
  10:       5548          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb2, Intel ICH6
  11:         27          XT-PIC  uhci_hcd:usb3, uhci_hcd:usb4, 
uhci_hcd:usb5, yenta, sdhci:slot0, sdhci:slot1, sdhci:slot2, ohci1394, sky2
  12:        618          XT-PIC  i8042
  14:       7384          XT-PIC  libata
  15:       1275          XT-PIC  libata
NMI:          0
LOC:          0
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeremy Fitzhardinge | 1 Jun 2006 23:40
Gravatar

[PATCH REPOST] Support enable/disable of WAN module in ibm_acpi

New Lenovo Thinkpads have an optional WAN module (a Sierra Wireless
MC5720 EV-DO modem), which can be turned on and off much like the
Bluetooth module.  This patch adds a "wan" entry to /proc/acpi/ibm,
which is pretty much a cut'n'paste of the corresponding bluetooth code.

    J

--

Allow a WAN module to enabled/disabled on a Thinkpad X60.

The WAN (Sierra Wireless EV-DO) module is very similar to the
Bluetooth module.  It appears on the USB bus when enabled.  It can be
controlled via hot key, or directly via ACPI.  This change enables
direct control via ACPI.

I have tested it on my Lenovo Thinkpad X60; I guess it will probably
work on other Thinkpad models which come with this module installed.

Signed-off-by: Jeremy Fitzhardinge <jeremy <at> goop.org>

diff -r 401a0868b8be drivers/acpi/ibm_acpi.c
--- a/drivers/acpi/ibm_acpi.c	Mon May 29 06:35:52 2006 +0700
+++ b/drivers/acpi/ibm_acpi.c	Mon May 29 01:36:12 2006 -0700
 <at>  <at>  -567,6 +567,69  <at>  <at>  static int bluetooth_write(char *buf)
 	return 0;
 }

+static int wan_supported;
+
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brown, Len | 1 Jun 2006 23:50
Picon
Favicon
Gravatar

RE: ACPI locking


>It has been a while since we have looked at the ACPICA locking 
>stuff, and I suppose now is as good a time as any. I am also 
>concerned with the Linux-only implementation and deployment of 
>the OsWaitEventsComplete interface, in terms of how the 
>locking interacts with it. (I am also concerned with why only 
>Linux has requested this interface.)

I don't know why other OSs don't need
acpi_os_wait_events_complete().  Maybe they don't do any
deferred processing.  But in any case, that is a different issue
than the (simpler) one at hand.

>The historical note on the OSL semaphore interfaces is that we 
>felt that if a "mutex" object was available in the host OS, it 
>could be used for the case where the OsCreateSemaphore() call 
>specified a MaxUnits parameter of one (a binary semaphore) - 
>rather than having an entirely separate "mutex" OSL interface. 
>The OSL spinlock interfaces were added later and are currently 
>only used in a limited way. Of course, when the day comes that 
>the ACPICA code is fully integrated into the host OS, the OSL 
>interfaces will probably be replaced by native OS calls, so we 
>always thought of the OSL interface as a somewhat interim 
>oil-slick, therefore we wanted to minimize the number of 
>different interfaces to it.

Linux just recently added dedicated
mutex entry points to optimize the case where semaphores
were used a mutexes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Moore, Robert | 2 Jun 2006 00:04
Picon
Favicon
Gravatar

RE: ACPI locking

I would say that we should fix the issues at hand before we even think
about fussing with the ACPI CA interfaces -- as this always seems to
break things as well.

It is ok to change the ACPICA interfaces, but other operating systems
should get a vote in this also. There is also the documentation and
other testing overhead to consider also.

As I've said, the goal has been to minimize the number of OSL/ACPICA
interfaces in order to have the smallest number of interfaces to provide
the required functionality. Just because an OS provides a dozen
different ways to allocate memory doesn't mean that we need that many
OSL interfaces. Indeed, the future plan for all hosts is to remove the
OSL and replace it with native OS calls anyway.

That said, I would say that the locking and multithreading issues can
get complex enough, we should get it working 1000% correct before we
think about optimizing interfaces.

Bob

> -----Original Message-----
> From: Brown, Len
> Sent: Thursday, June 01, 2006 2:51 PM
> To: Moore, Robert
> Cc: 'linux-acpi <at> vger.kernel.org'
> Subject: RE: ACPI locking
> 
> 
> >It has been a while since we have looked at the ACPICA locking
(Continue reading)

Permalink | Reply | 0 comments |

Gmane