[PATCH 1/2] ACPI: EC: Do the byte access with a fast path

[PATCH 1/2] ACPI: EC: Do the byte access with a fast path

[Alexey Starikovskiy]

Specification allows only byte access for EC region, so
make it separate from bug-compatible multy-byte access.
Also do not allow return of garbage in supplied *value.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
---

 drivers/acpi/ec.c |   15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 97dc161..1de0905 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -563,7 +563,7 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
 		      void *handler_context, void *region_context)
 {
 	struct acpi_ec *ec = handler_context;
-	int result = 0, i = 0;
+	int result = 0, i;
 	u8 temp = 0;
 
 	if ((address > 0xFF) || !value || !handler_context)
@@ -575,7 +575,16 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
 	if (bits != 8 && acpi_strict)
 		return AE_BAD_PARAMETER;
 
-	while (bits - i > 0) {
+	if (function == ACPI_READ) {
+		result = acpi_ec_read(ec, address, &temp);
+		*value = temp;
+	} else {
+		temp = 0xff & (*value);
+		result = acpi_ec_write(ec, address, temp);
+	}
+
+	for (i = 8; unlikely(bits - i > 0); i += 8) {
+		++address;
 		if (function == ACPI_READ) {
 			result = acpi_ec_read(ec, address, &temp);
 			(*value) |= ((acpi_integer)temp) << i;
@@ -583,8 +592,6 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
 			temp = 0xff & ((*value) >> i);
 			result = acpi_ec_write(ec, address, temp);
 		}
-		i += 8;
-		++address;
 	}
 
 	switch (result) {

[PATCH 2/2] ACPI: EC: Some hardware requires burst mode to operate properly

[Alexey Starikovskiy]

Burst mode temporary (50 ms) locks EC to do only transactions with
driver, without it some hardware returns abstract garbage.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
---

 drivers/acpi/ec.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 1de0905..98a5388 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -575,6 +575,8 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
 	if (bits != 8 && acpi_strict)
 		return AE_BAD_PARAMETER;
 
+	acpi_ec_burst_enable(ec);
+
 	if (function == ACPI_READ) {
 		result = acpi_ec_read(ec, address, &temp);
 		*value = temp;
@@ -594,6 +596,8 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
 		}
 	}
 
+	acpi_ec_burst_disable(ec);
+
 	switch (result) {
 	case -EINVAL:
 		return AE_BAD_PARAMETER;

Re: [PATCH 1/2] ACPI: EC: Do the byte access with a fast path

[Len Brown]

applied to acpi test.

thanks,
-Len

On Thursday 10 January 2008 18:42, Alexey Starikovskiy wrote:
> Specification allows only byte access for EC region, so
> make it separate from bug-compatible multy-byte access.
> Also do not allow return of garbage in supplied *value.
> 
> Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
> ---
> 
>  drivers/acpi/ec.c |   15 +++++++++++----
>  1 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 97dc161..1de0905 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -563,7 +563,7 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
>  		      void *handler_context, void *region_context)
>  {
>  	struct acpi_ec *ec = handler_context;
> -	int result = 0, i = 0;
> +	int result = 0, i;
>  	u8 temp = 0;
>  
>  	if ((address > 0xFF) || !value || !handler_context)
> @@ -575,7 +575,16 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
>  	if (bits != 8 && acpi_strict)
>  		return AE_BAD_PARAMETER;
>  
> -	while (bits - i > 0) {
> +	if (function == ACPI_READ) {
> +		result = acpi_ec_read(ec, address, &temp);
> +		*value = temp;
> +	} else {
> +		temp = 0xff & (*value);
> +		result = acpi_ec_write(ec, address, temp);
> +	}
> +
> +	for (i = 8; unlikely(bits - i > 0); i += 8) {
> +		++address;
>  		if (function == ACPI_READ) {
>  			result = acpi_ec_read(ec, address, &temp);
>  			(*value) |= ((acpi_integer)temp) << i;
> @@ -583,8 +592,6 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
>  			temp = 0xff & ((*value) >> i);
>  			result = acpi_ec_write(ec, address, temp);
>  		}
> -		i += 8;
> -		++address;
>  	}
>  
>  	switch (result) {
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 2/2] ACPI: EC: Some hardware requires burst mode to operate properly

[Len Brown]

applied to acpi test

thanks,
-Len

On Thursday 10 January 2008 18:42, Alexey Starikovskiy wrote:
> Burst mode temporary (50 ms) locks EC to do only transactions with
> driver, without it some hardware returns abstract garbage.
> 
> Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9341
> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
> ---
> 
>  drivers/acpi/ec.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index 1de0905..98a5388 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -575,6 +575,8 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
>  	if (bits != 8 && acpi_strict)
>  		return AE_BAD_PARAMETER;
>  
> +	acpi_ec_burst_enable(ec);
> +
>  	if (function == ACPI_READ) {
>  		result = acpi_ec_read(ec, address, &temp);
>  		*value = temp;
> @@ -594,6 +596,8 @@ acpi_ec_space_handler(u32 function, acpi_physical_address address,
>  		}
>  	}
>  
> +	acpi_ec_burst_disable(ec);
> +
>  	switch (result) {
>  	case -EINVAL:
>  		return AE_BAD_PARAMETER;
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>