public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* Re: 2.6.12-rc3-mm2: ACPI problems
       [not found] ` <20050430164303.6538f47c.akpm-3NddpPZAyC0@public.gmane.org>
@ 2005-05-01 12:56   ` Rafael J. Wysocki
       [not found]     ` <200505011456.38744.rjw-KKrjLPT3xs0@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Rafael J. Wysocki @ 2005-05-01 12:56 UTC (permalink / raw)
  To: Andrew Morton
  Cc: ACPI mailing list, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Yu, Luming

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

Hi,

On Sunday, 1 of May 2005 01:43, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc3/2.6.12-rc3-mm2/

I have two ACPI-related problems with this kernel (they have also been present
in the previous -mm, so please treat this report as a "the issue is still there" kind
of thing):

1) The box hangs solid during suspend/resume (in the PIC mode) due to problems
with handling PCI ACPI links (the details are available from bugzilla:
http://bugzilla.kernel.org/show_bug.cgi?id=4416).

2) The ACPI battery module does not seem to work, eg. this is the output of
"time cat /proc/acpi/battery/BAT0/state":

present:                 yes
capacity state:          ok
charging state:          charged
present rate:            unknown
remaining capacity:      unknown
present voltage:         unknown

real    0m44.875s
user    0m0.001s
sys     0m0.020s

To make it work, I needed to apply the attached patch.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

[-- Attachment #2: 2.6.12-rc3-mm2-acpi-ec.patch --]
[-- Type: text/x-diff, Size: 17640 bytes --]

--- 2.6.12-rc3-mm2-old/drivers/acpi/ec.c	2005-05-01 13:13:43.000000000 +0200
+++ linux-2.6.12-rc3-mm2/drivers/acpi/ec.c	2005-05-01 14:08:12.000000000 +0200
@@ -31,7 +31,6 @@
 #include <linux/delay.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
-#include <linux/interrupt.h>
 #include <asm/io.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
@@ -50,19 +49,17 @@ ACPI_MODULE_NAME		("acpi_ec")
 
 #define ACPI_EC_FLAG_OBF	0x01	/* Output buffer full */
 #define ACPI_EC_FLAG_IBF	0x02	/* Input buffer full */
-#define ACPI_EC_FLAG_BURST	0x10	/* burst mode */
 #define ACPI_EC_FLAG_SCI	0x20	/* EC-SCI occurred */
 
 #define ACPI_EC_EVENT_OBF	0x01	/* Output buffer full */
 #define ACPI_EC_EVENT_IBE	0x02	/* Input buffer empty */
 
-#define ACPI_EC_DELAY		50	/* Wait 50ms max. during EC ops */
+#define ACPI_EC_UDELAY		100	/* Poll @ 100us increments */
+#define ACPI_EC_UDELAY_COUNT	1000	/* Wait 10ms max. during EC ops */
 #define ACPI_EC_UDELAY_GLK	1000	/* Wait 1ms max. to get global lock */
 
 #define ACPI_EC_COMMAND_READ	0x80
 #define ACPI_EC_COMMAND_WRITE	0x81
-#define ACPI_EC_BURST_ENABLE	0x82
-#define ACPI_EC_BURST_DISABLE	0x83
 #define ACPI_EC_COMMAND_QUERY	0x84
 
 static int acpi_ec_add (struct acpi_device *device);
@@ -90,11 +87,7 @@ struct acpi_ec {
 	struct acpi_generic_address	command_addr;
 	struct acpi_generic_address	data_addr;
 	unsigned long			global_lock;
-	unsigned int			expect_event;
-	atomic_t			leaving_burst; /* 0 : No, 1 : Yes, 2: abort*/
-	atomic_t			pending_gpe;
-	struct semaphore		sem;
-	wait_queue_head_t		wait;
+	spinlock_t			lock;
 };
 
 /* If we find an EC via the ECDT, we need to keep a ptr to its context */
@@ -107,138 +100,59 @@ static struct acpi_device *first_ec;
                              Transaction Management
    -------------------------------------------------------------------------- */
 
-static inline u32 acpi_ec_read_status(struct acpi_ec *ec)
-{
-	u32	status = 0;
-
-	acpi_hw_low_level_read(8, &status, &ec->status_addr);
-	return status;
-}
-
-static int acpi_ec_wait(struct acpi_ec *ec, unsigned int event)
+static int
+acpi_ec_wait (
+	struct acpi_ec		*ec,
+	u8			event)
 {
-	int	result = 0;
-
-	ACPI_FUNCTION_TRACE("acpi_ec_wait");
+	u32			acpi_ec_status = 0;
+	u32			i = ACPI_EC_UDELAY_COUNT;
 
-	ec->expect_event = event;
-	smp_mb();
-
-	result = wait_event_interruptible_timeout(ec->wait,
-					!ec->expect_event,
-					msecs_to_jiffies(ACPI_EC_DELAY));
-	
-	ec->expect_event = 0;
-	smp_mb();
-
-	if (result < 0){
-		ACPI_DEBUG_PRINT((ACPI_DB_ERROR," result  = %d ", result));
-		return_VALUE(result);
-	}
+	if (!ec)
+		return -EINVAL;
 
-	/*
-	 * Verify that the event in question has actually happened by
-	 * querying EC status. Do the check even if operation timed-out
-	 * to make sure that we did not miss interrupt.
-	 */
+	/* Poll the EC status register waiting for the event to occur. */
 	switch (event) {
 	case ACPI_EC_EVENT_OBF:
-		if (acpi_ec_read_status(ec) & ACPI_EC_FLAG_OBF)
-			return_VALUE(0);
+		do {
+			acpi_hw_low_level_read(8, &acpi_ec_status, &ec->status_addr);
+			if (acpi_ec_status & ACPI_EC_FLAG_OBF)
+				return 0;
+			udelay(ACPI_EC_UDELAY);
+		} while (--i>0);
 		break;
-
 	case ACPI_EC_EVENT_IBE:
-		if (~acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF)
-			return_VALUE(0);
+		do {
+			acpi_hw_low_level_read(8, &acpi_ec_status, &ec->status_addr);
+			if (!(acpi_ec_status & ACPI_EC_FLAG_IBF))
+				return 0;
+			udelay(ACPI_EC_UDELAY);
+		} while (--i>0);
 		break;
+	default:
+		return -EINVAL;
 	}
 
-	return_VALUE(-ETIME);
+	return -ETIME;
 }
 
 
-
-static int
-acpi_ec_enter_burst_mode (
-	struct acpi_ec		*ec)
-{
-	u32			tmp = 0;
-	int			status = 0;
-
-	ACPI_FUNCTION_TRACE("acpi_ec_enter_burst_mode");
-
-	status = acpi_ec_read_status(ec);
-	if (status != -EINVAL &&
-		!(status & ACPI_EC_FLAG_BURST)){
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"entering burst mode \n"));
-		acpi_hw_low_level_write(8, ACPI_EC_BURST_ENABLE, &ec->command_addr);
-		status = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
-		if (status){
-			acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-			ACPI_DEBUG_PRINT((ACPI_DB_ERROR," status = %d\n", status));
-			return_VALUE(-EINVAL);
-		}
-		acpi_hw_low_level_read(8, &tmp, &ec->data_addr);
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-		if(tmp != 0x90 ) {/* Burst ACK byte*/
-			ACPI_DEBUG_PRINT((ACPI_DB_ERROR,"Ack failed \n"));
-			return_VALUE(-EINVAL);
-		}
-	} else
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"already be in burst mode \n"));
-	atomic_set(&ec->leaving_burst , 0);
-	return_VALUE(0);
-}
-
-static int
-acpi_ec_leave_burst_mode (
-	struct acpi_ec		*ec)
-{
-	int			status =0;
-
-	ACPI_FUNCTION_TRACE("acpi_ec_leave_burst_mode");
-
-	atomic_set(&ec->leaving_burst , 1);
-	status = acpi_ec_read_status(ec);
-	if (status != -EINVAL &&
-		(status & ACPI_EC_FLAG_BURST)){
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"leaving burst mode\n"));
-		acpi_hw_low_level_write(8, ACPI_EC_BURST_DISABLE, &ec->command_addr);
-		status = acpi_ec_wait(ec, ACPI_EC_FLAG_IBF);
-		if (status){
-			acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-			ACPI_DEBUG_PRINT((ACPI_DB_ERROR,"------->wait fail\n"));
-			return_VALUE(-EINVAL);
-		}
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-		status = acpi_ec_read_status(ec);
-		if (status != -EINVAL &&
-			(status & ACPI_EC_FLAG_BURST)) {
-			ACPI_DEBUG_PRINT((ACPI_DB_ERROR,"------->status fail\n"));
-			return_VALUE(-EINVAL);
-		}
-	}else
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"already be in Non-burst mode \n"));
-	ACPI_DEBUG_PRINT((ACPI_DB_INFO,"leaving burst mode\n"));
-
-	return_VALUE(0);
-}
-
 static int
 acpi_ec_read (
 	struct acpi_ec		*ec,
 	u8			address,
 	u32			*data)
 {
-	int			status = 0;
-	u32			glk;
+	acpi_status		status = AE_OK;
+	int			result = 0;
+	unsigned long		flags = 0;
+	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_read");
 
 	if (!ec || !data)
 		return_VALUE(-EINVAL);
 
-retry:
 	*data = 0;
 
 	if (ec->global_lock) {
@@ -247,49 +161,30 @@ retry:
 			return_VALUE(-ENODEV);
 	}
 
-	WARN_ON(in_interrupt());
-	down(&ec->sem);
-
-	if(acpi_ec_enter_burst_mode(ec))
-		goto end;
+	spin_lock_irqsave(&ec->lock, flags);
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_READ, &ec->command_addr);
-	status = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
-	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-	if (status) {
+	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
+	if (result)
 		goto end;
-	}
 
 	acpi_hw_low_level_write(8, address, &ec->data_addr);
-	status= acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
-	if (status){
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
+	result = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
+	if (result)
 		goto end;
-	}
 
 	acpi_hw_low_level_read(8, data, &ec->data_addr);
-	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
 
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Read [%02x] from address [%02x]\n",
 		*data, address));
 	
 end:
-	acpi_ec_leave_burst_mode(ec);
-	up(&ec->sem);
+	spin_unlock_irqrestore(&ec->lock, flags);
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
 
-	if(atomic_read(&ec->leaving_burst) == 2){
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"aborted, retry ...\n"));
-		while(atomic_read(&ec->pending_gpe)){
-			msleep(1);	
-		}
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-		goto retry;
-	}
-
-	return_VALUE(status);
+	return_VALUE(result);
 }
 
 
@@ -299,80 +194,49 @@ acpi_ec_write (
 	u8			address,
 	u8			data)
 {
-	int			status = 0;
-	u32			glk;
-	u32			tmp;
+	int			result = 0;
+	acpi_status		status = AE_OK;
+	unsigned long		flags = 0;
+	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_write");
 
 	if (!ec)
 		return_VALUE(-EINVAL);
-retry:
+
 	if (ec->global_lock) {
 		status = acpi_acquire_global_lock(ACPI_EC_UDELAY_GLK, &glk);
 		if (ACPI_FAILURE(status))
 			return_VALUE(-ENODEV);
 	}
 
-	WARN_ON(in_interrupt());
-	down(&ec->sem);
-
-	if(acpi_ec_enter_burst_mode(ec))
-		goto end;
-
-	status = acpi_ec_read_status(ec);
-	if (status != -EINVAL &&
-		!(status & ACPI_EC_FLAG_BURST)){
-		acpi_hw_low_level_write(8, ACPI_EC_BURST_ENABLE, &ec->command_addr);
-		status = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
-		if (status)
-			goto end;
-		acpi_hw_low_level_read(8, &tmp, &ec->data_addr);
-		if(tmp != 0x90 ) /* Burst ACK byte*/
-			goto end;
-	}
-	/*Now we are in burst mode*/
+	spin_lock_irqsave(&ec->lock, flags);
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_WRITE, &ec->command_addr);
-	status = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
-	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-	if (status){
+	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
+	if (result)
 		goto end;
-	}
 
 	acpi_hw_low_level_write(8, address, &ec->data_addr);
-	status = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
-	if (status){
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
+	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
+	if (result)
 		goto end;
-	}
 
 	acpi_hw_low_level_write(8, data, &ec->data_addr);
-	status = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
-	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-	if (status)
+	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);
+	if (result)
 		goto end;
 
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Wrote [%02x] to address [%02x]\n",
 		data, address));
 
 end:
-	acpi_ec_leave_burst_mode(ec);
-	up(&ec->sem);
+	spin_unlock_irqrestore(&ec->lock, flags);
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
 
-	if(atomic_read(&ec->leaving_burst) == 2){
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"aborted, retry ...\n"));
-		while(atomic_read(&ec->pending_gpe)){
-			msleep(1);	
-		}
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-		goto retry;
-	}
-
-	return_VALUE(status);
+	return_VALUE(result);
 }
 
 /*
@@ -424,13 +288,16 @@ acpi_ec_query (
 	struct acpi_ec		*ec,
 	u32			*data)
 {
-	int			status = 0;
-	u32			glk;
+	int			result = 0;
+	acpi_status		status = AE_OK;
+	unsigned long		flags = 0;
+	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_query");
 
 	if (!ec || !data)
 		return_VALUE(-EINVAL);
+
 	*data = 0;
 
 	if (ec->global_lock) {
@@ -439,39 +306,29 @@ acpi_ec_query (
 			return_VALUE(-ENODEV);
 	}
 
-	down(&ec->sem);
-	if(acpi_ec_enter_burst_mode(ec))
-		goto end;
 	/*
 	 * Query the EC to find out which _Qxx method we need to evaluate.
 	 * Note that successful completion of the query causes the ACPI_EC_SCI
 	 * bit to be cleared (and thus clearing the interrupt source).
 	 */
+	spin_lock_irqsave(&ec->lock, flags);
+
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_QUERY, &ec->command_addr);
-	status = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
-	if (status){
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
+	result = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);
+	if (result)
 		goto end;
-	}
 
 	acpi_hw_low_level_read(8, data, &ec->data_addr);
-	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
 	if (!*data)
-		status = -ENODATA;
+		result = -ENODATA;
 
 end:
-	acpi_ec_leave_burst_mode(ec);
-	up(&ec->sem);
+	spin_unlock_irqrestore(&ec->lock, flags);
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);
 
-	if(atomic_read(&ec->leaving_burst) == 2){
-		ACPI_DEBUG_PRINT((ACPI_DB_INFO,"aborted, retry ...\n"));
-		acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
-		status = -ENODATA;
-	}
-	return_VALUE(status);
+	return_VALUE(result);
 }
 
 
@@ -489,18 +346,31 @@ acpi_ec_gpe_query (
 	void			*ec_cxt)
 {
 	struct acpi_ec		*ec = (struct acpi_ec *) ec_cxt;
-	u32			value;
-	int			result = -ENODATA;
+	u32			value = 0;
+	unsigned long		flags = 0;
 	static char		object_name[5] = {'_','Q','0','0','\0'};
 	const char		hex[] = {'0','1','2','3','4','5','6','7',
 				         '8','9','A','B','C','D','E','F'};
 
 	ACPI_FUNCTION_TRACE("acpi_ec_gpe_query");
 
-	if (acpi_ec_read_status(ec) & ACPI_EC_FLAG_SCI)
-		result = acpi_ec_query(ec, &value);
+	if (!ec_cxt)
+		goto end;
+
+	spin_lock_irqsave(&ec->lock, flags);
+	acpi_hw_low_level_read(8, &value, &ec->command_addr);
+	spin_unlock_irqrestore(&ec->lock, flags);
+
+	/* TBD: Implement asynch events!
+	 * NOTE: All we care about are EC-SCI's.  Other EC events are
+	 * handled via polling (yuck!).  This is because some systems
+	 * treat EC-SCIs as level (versus EDGE!) triggered, preventing
+	 *  a purely interrupt-driven approach (grumble, grumble).
+	 */
+	if (!(value & ACPI_EC_FLAG_SCI))
+		goto end;
 
-	if (result)
+	if (acpi_ec_query(ec, &value))
 		goto end;
 
 	object_name[2] = hex[((value >> 4) & 0x0F)];
@@ -509,9 +379,9 @@ acpi_ec_gpe_query (
 	ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Evaluating %s\n", object_name));
 
 	acpi_evaluate_object(ec->handle, object_name, NULL, NULL);
+
 end:	
-	atomic_dec(&ec->pending_gpe);
-	return;
+	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_NOT_ISR);
 }
 
 static u32
@@ -519,7 +389,6 @@ acpi_ec_gpe_handler (
 	void			*data)
 {
 	acpi_status		status = AE_OK;
-	u32			value;
 	struct acpi_ec		*ec = (struct acpi_ec *) data;
 
 	if (!ec)
@@ -527,41 +396,13 @@ acpi_ec_gpe_handler (
 
 	acpi_disable_gpe(NULL, ec->gpe_bit, ACPI_ISR);
 
-	value = acpi_ec_read_status(ec);
+	status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
+		acpi_ec_gpe_query, ec);
 
-	if((value & ACPI_EC_FLAG_IBF) &&
-		!(value & ACPI_EC_FLAG_BURST) &&
-			(atomic_read(&ec->leaving_burst) == 0)) { 
-	/*
-	 * the embedded controller disables 
-	 * burst mode for any reason other 
-	 * than the burst disable command
-	 * to process critical event.
-	 */
-		atomic_set(&ec->leaving_burst , 2); /* block current pending transaction
-					and retry */
-		wake_up(&ec->wait);
-	}else {
-		if ((ec->expect_event == ACPI_EC_EVENT_OBF &&
-				(value & ACPI_EC_FLAG_OBF)) ||
-	    			(ec->expect_event == ACPI_EC_EVENT_IBE &&
-				!(value & ACPI_EC_FLAG_IBF))) {
-			ec->expect_event = 0;
-			wake_up(&ec->wait);
-			return ACPI_INTERRUPT_HANDLED;
-		}
-	}
-
-	if (value & ACPI_EC_FLAG_SCI){
-		atomic_add(1, &ec->pending_gpe) ;
-		status = acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
-						acpi_ec_gpe_query, ec);
-		return status == AE_OK ?
-		ACPI_INTERRUPT_HANDLED : ACPI_INTERRUPT_NOT_HANDLED;
-	} 
-	acpi_enable_gpe(NULL, ec->gpe_bit, ACPI_ISR);
-	return status == AE_OK ?
-		ACPI_INTERRUPT_HANDLED : ACPI_INTERRUPT_NOT_HANDLED;
+	if (status == AE_OK)
+		return ACPI_INTERRUPT_HANDLED;
+	else
+		return ACPI_INTERRUPT_NOT_HANDLED;
 }
 
 /* --------------------------------------------------------------------------
@@ -579,8 +420,10 @@ acpi_ec_space_setup (
 	 * The EC object is in the handler context and is needed
 	 * when calling the acpi_ec_space_handler.
 	 */
-	*return_context  = (function != ACPI_REGION_DEACTIVATE) ?
-						handler_context : NULL;
+	if(function == ACPI_REGION_DEACTIVATE) 
+		*return_context = NULL;
+	else 
+		*return_context = handler_context;
 
 	return AE_OK;
 }
@@ -708,7 +551,7 @@ static int
 acpi_ec_add_fs (
 	struct acpi_device	*device)
 {
-	struct proc_dir_entry	*entry;
+	struct proc_dir_entry	*entry = NULL;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_add_fs");
 
@@ -759,9 +602,9 @@ static int
 acpi_ec_add (
 	struct acpi_device	*device)
 {
-	int			result;
-	acpi_status		status;
-	struct acpi_ec		*ec;
+	int			result = 0;
+	acpi_status		status = AE_OK;
+	struct acpi_ec		*ec = NULL;
 	unsigned long		uid;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_add");
@@ -776,10 +619,7 @@ acpi_ec_add (
 
 	ec->handle = device->handle;
 	ec->uid = -1;
- 	atomic_set(&ec->pending_gpe, 0);
- 	atomic_set(&ec->leaving_burst , 1);
- 	init_MUTEX(&ec->sem);
- 	init_waitqueue_head(&ec->wait);
+	spin_lock_init(&ec->lock);
 	strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
 	strcpy(acpi_device_class(device), ACPI_EC_CLASS);
 	acpi_driver_data(device) = ec;
@@ -793,7 +633,7 @@ acpi_ec_add (
 	if (ec_ecdt && ec_ecdt->uid == uid) {
 		acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
 			ACPI_ADR_SPACE_EC, &acpi_ec_space_handler);
-
+	
 		acpi_remove_gpe_handler(NULL, ec_ecdt->gpe_bit, &acpi_ec_gpe_handler);
 
 		kfree(ec_ecdt);
@@ -833,7 +673,7 @@ acpi_ec_remove (
 	struct acpi_device	*device,
 	int			type)
 {
-	struct acpi_ec		*ec;
+	struct acpi_ec		*ec = NULL;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_remove");
 
@@ -888,8 +728,8 @@ static int
 acpi_ec_start (
 	struct acpi_device	*device)
 {
-	acpi_status		status;
-	struct acpi_ec		*ec;
+	acpi_status		status = AE_OK;
+	struct acpi_ec		*ec = NULL;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_start");
 
@@ -945,8 +785,8 @@ acpi_ec_stop (
 	struct acpi_device	*device,
 	int			type)
 {
-	acpi_status		status;
-	struct acpi_ec		*ec;
+	acpi_status		status = AE_OK;
+	struct acpi_ec		*ec = NULL;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_stop");
 
@@ -988,6 +828,7 @@ acpi_fake_ecdt_callback (
 	status = acpi_evaluate_integer(handle, "_GPE", NULL, &ec_ecdt->gpe_bit);
 	if (ACPI_FAILURE(status))
 		return status;
+	spin_lock_init(&ec_ecdt->lock);
 	ec_ecdt->global_lock = TRUE;
 	ec_ecdt->handle = handle;
 
@@ -1045,7 +886,7 @@ acpi_ec_get_real_ecdt(void)
 	acpi_status		status;
 	struct acpi_table_ecdt 	*ecdt_ptr;
 
-	status = acpi_get_firmware_table("ECDT", 1, ACPI_LOGICAL_ADDRESSING,
+	status = acpi_get_firmware_table("ECDT", 1, ACPI_LOGICAL_ADDRESSING, 
 		(struct acpi_table_header **) &ecdt_ptr);
 	if (ACPI_FAILURE(status))
 		return -ENODEV;
@@ -1060,12 +901,11 @@ acpi_ec_get_real_ecdt(void)
 		return -ENOMEM;
 	memset(ec_ecdt, 0, sizeof(struct acpi_ec));
 
- 	init_MUTEX(&ec_ecdt->sem);
- 	init_waitqueue_head(&ec_ecdt->wait);
 	ec_ecdt->command_addr = ecdt_ptr->ec_control;
 	ec_ecdt->status_addr = ecdt_ptr->ec_control;
 	ec_ecdt->data_addr = ecdt_ptr->ec_data;
 	ec_ecdt->gpe_bit = ecdt_ptr->gpe_bit;
+	spin_lock_init(&ec_ecdt->lock);
 	/* use the GL just to be safe */
 	ec_ecdt->global_lock = TRUE;
 	ec_ecdt->uid = ecdt_ptr->uid;
@@ -1134,7 +974,7 @@ error:
 
 static int __init acpi_ec_init (void)
 {
-	int			result;
+	int			result = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_init");
 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.6.12-rc3-mm2: ACPI problems
       [not found]     ` <200505011456.38744.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2005-05-01 13:41       ` Brice Goglin
       [not found]         ` <4274DC95.6080208-vYW+cPY1g1pg9hUCZPvPmw@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Brice Goglin @ 2005-05-01 13:41 UTC (permalink / raw)
  To: Andrew Morton
  Cc: ACPI mailing list, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	Yu, Luming

Rafael J. Wysocki a écrit :
> Hi,
> 
> On Sunday, 1 of May 2005 01:43, Andrew Morton wrote:
> 
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc3/2.6.12-rc3-mm2/
> 
> 
> I have two ACPI-related problems with this kernel (they have also been present
> in the previous -mm, so please treat this report as a "the issue is still there" kind
> of thing):

I'm also seeing a (small) problem with ACPI for a few -mm kernels
(at least since -rc2-mm2, IIRC).
I don't have a /proc/acpi/button/ anymore.
My computer is a Compaq Evo N600c laptop.
ACPI is generally working great here.

In 2.6.12-rc3, I have:
/proc/acpi/button/lid/C1A4/info
/proc/acpi/button/lid/C1A4/state
/proc/acpi/button/power/PWRF/info
/proc/acpi/button/sleep/C1A3/info
Nothing in rc3-mm1 (even no /proc/acpi/button/ directory).

I didn't find any interesting difference between dmesg from rc3 and
rc3-mm1. Both show these lines:
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1A3]
ACPI: Lid Switch [C1A4]

Any idea ?

Thanks
Brice


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.6.12-rc3-mm2: ACPI problems
       [not found]         ` <4274DC95.6080208-vYW+cPY1g1pg9hUCZPvPmw@public.gmane.org>
@ 2005-05-26  7:08           ` Andrew Morton
       [not found]             ` <20050526000800.66c42b6b.akpm-3NddpPZAyC0@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2005-05-26  7:08 UTC (permalink / raw)
  To: Brice Goglin; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Brice Goglin <Brice.Goglin-vYW+cPY1g1pg9hUCZPvPmw@public.gmane.org> wrote:
>
> Rafael J. Wysocki a écrit :
> > Hi,
> > 
> > On Sunday, 1 of May 2005 01:43, Andrew Morton wrote:
> > 
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc3/2.6.12-rc3-mm2/
> > 
> > 
> > I have two ACPI-related problems with this kernel (they have also been present
> > in the previous -mm, so please treat this report as a "the issue is still there" kind
> > of thing):
> 
> I'm also seeing a (small) problem with ACPI for a few -mm kernels
> (at least since -rc2-mm2, IIRC).
> I don't have a /proc/acpi/button/ anymore.
> My computer is a Compaq Evo N600c laptop.
> ACPI is generally working great here.
> 
> In 2.6.12-rc3, I have:
> /proc/acpi/button/lid/C1A4/info
> /proc/acpi/button/lid/C1A4/state
> /proc/acpi/button/power/PWRF/info
> /proc/acpi/button/sleep/C1A3/info
> Nothing in rc3-mm1 (even no /proc/acpi/button/ directory).
> 
> I didn't find any interesting difference between dmesg from rc3 and
> rc3-mm1. Both show these lines:
> ACPI: Power Button (FF) [PWRF]
> ACPI: Sleep Button (CM) [C1A3]
> ACPI: Lid Switch [C1A4]
> 

Is this one still occurring in 2.6.12-rc5 and/or 2.6.12-rc5-mm1?


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id\x16135&op=click

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.6.12-rc3-mm2: ACPI problems
       [not found]             ` <20050526000800.66c42b6b.akpm-3NddpPZAyC0@public.gmane.org>
@ 2005-05-26  7:22               ` Brice Goglin
  0 siblings, 0 replies; 4+ messages in thread
From: Brice Goglin @ 2005-05-26  7:22 UTC (permalink / raw)
  To: Andrew Morton; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

 (Andrew Morton a écrit :
> Brice Goglin <Brice.Goglin-vYW+cPY1g1pg9hUCZPvPmw@public.gmane.org> wrote:
> 
>>I'm also seeing a (small) problem with ACPI for a few -mm kernels
>>(at least since -rc2-mm2, IIRC).
>>I don't have a /proc/acpi/button/ anymore.
>>My computer is a Compaq Evo N600c laptop.
>>ACPI is generally working great here.
>>
>>In 2.6.12-rc3, I have:
>>/proc/acpi/button/lid/C1A4/info
>>/proc/acpi/button/lid/C1A4/state
>>/proc/acpi/button/power/PWRF/info
>>/proc/acpi/button/sleep/C1A3/info
>>Nothing in rc3-mm1 (even no /proc/acpi/button/ directory).
>>
>>I didn't find any interesting difference between dmesg from rc3 and
>>rc3-mm1. Both show these lines:
>>ACPI: Power Button (FF) [PWRF]
>>ACPI: Sleep Button (CM) [C1A3]
>>ACPI: Lid Switch [C1A4]
>>
> 
> 
> Is this one still occurring in 2.6.12-rc5 and/or 2.6.12-rc5-mm1?

This problem is only is -mm (still in rc5-mm1),
not in any -rc (especially not -rc5).

I didn't get any response about this report. But, looking at
the code, I finally thought that's a feature, not a bug.
The entire code for this /proc/acpi/buttons disappeared
from drivers/acpi/buttons.c
So I guess ACPI guys wanted to drop it ?

Button events are still reported well in /proc/acpi/events.
I don't need anything more.

Thanks,
Brice


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_idt02&alloc_id\x16135&op=click

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-05-26  7:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20050430164303.6538f47c.akpm@osdl.org>
     [not found] ` <20050430164303.6538f47c.akpm-3NddpPZAyC0@public.gmane.org>
2005-05-01 12:56   ` 2.6.12-rc3-mm2: ACPI problems Rafael J. Wysocki
     [not found]     ` <200505011456.38744.rjw-KKrjLPT3xs0@public.gmane.org>
2005-05-01 13:41       ` Brice Goglin
     [not found]         ` <4274DC95.6080208-vYW+cPY1g1pg9hUCZPvPmw@public.gmane.org>
2005-05-26  7:08           ` Andrew Morton
     [not found]             ` <20050526000800.66c42b6b.akpm-3NddpPZAyC0@public.gmane.org>
2005-05-26  7:22               ` Brice Goglin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox