[PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Matthew Garrett]

Right now, if _BQC returns a value we don't understand we immediately
invalidate it. Change this behaviour so we only invalidate it if it
continues to give an invalid answer after we've already set a brightness.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
---
 drivers/acpi/video.c |   28 +++++++++++++++++-----------
 1 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index b765790..ea314a2 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -327,7 +327,7 @@ static int acpi_video_device_lcd_set_level(struct acpi_video_device *device,
 			int level);
 static int acpi_video_device_lcd_get_level_current(
 			struct acpi_video_device *device,
-			unsigned long long *level);
+			unsigned long long *level, int init);
 static int acpi_video_get_next_level(struct acpi_video_device *device,
 				     u32 level_current, u32 event);
 static int acpi_video_switch_brightness(struct acpi_video_device *device,
@@ -345,7 +345,7 @@ static int acpi_video_get_brightness(struct backlight_device *bd)
 	struct acpi_video_device *vd =
 		(struct acpi_video_device *)bl_get_data(bd);
 
-	if (acpi_video_device_lcd_get_level_current(vd, &cur_level))
+	if (acpi_video_device_lcd_get_level_current(vd, &cur_level, 0))
 		return -EINVAL;
 	for (i = 2; i < vd->brightness->count; i++) {
 		if (vd->brightness->levels[i] == cur_level)
@@ -414,7 +414,7 @@ static int video_get_cur_state(struct thermal_cooling_device *cooling_dev, unsig
 	unsigned long long level;
 	int offset;
 
-	if (acpi_video_device_lcd_get_level_current(video, &level))
+	if (acpi_video_device_lcd_get_level_current(video, &level, 0))
 		return -EINVAL;
 	for (offset = 2; offset < video->brightness->count; offset++)
 		if (level == video->brightness->levels[offset]) {
@@ -609,7 +609,7 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
 
 static int
 acpi_video_device_lcd_get_level_current(struct acpi_video_device *device,
-					unsigned long long *level)
+					unsigned long long *level, int init)
 {
 	acpi_status status = AE_OK;
 	int i;
@@ -633,10 +633,16 @@ acpi_video_device_lcd_get_level_current(struct acpi_video_device *device,
 					device->brightness->curr = *level;
 					return 0;
 			}
-			/* BQC returned an invalid level. Stop using it.  */
-			ACPI_WARNING((AE_INFO, "%s returned an invalid level",
-						buf));
-			device->cap._BQC = device->cap._BCQ = 0;
+			if (!init) {
+				/*
+				 * BQC returned an invalid level.
+				 * Stop using it.
+				 */
+				ACPI_WARNING((AE_INFO,
+					      "%s returned an invalid level",
+					      buf));
+				device->cap._BQC = device->cap._BCQ = 0;
+			}
 		} else {
 			/* Fixme:
 			 * should we return an error or ignore this failure?
@@ -892,7 +898,7 @@ acpi_video_init_brightness(struct acpi_video_device *device)
 	if (!device->cap._BQC)
 		goto set_level;
 
-	result = acpi_video_device_lcd_get_level_current(device, &level_old);
+	result = acpi_video_device_lcd_get_level_current(device, &level_old, 1);
 	if (result)
 		goto out_free_levels;
 
@@ -903,7 +909,7 @@ acpi_video_init_brightness(struct acpi_video_device *device)
 	if (result)
 		goto out_free_levels;
 
-	result = acpi_video_device_lcd_get_level_current(device, &level);
+	result = acpi_video_device_lcd_get_level_current(device, &level, 0);
 	if (result)
 		goto out_free_levels;
 
@@ -1996,7 +2002,7 @@ acpi_video_switch_brightness(struct acpi_video_device *device, int event)
 		goto out;
 
 	result = acpi_video_device_lcd_get_level_current(device,
-							 &level_current);
+							 &level_current, 0);
 	if (result)
 		goto out;
 
-- 
1.6.6.1

Re: [PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Len Brown]

Matthew,

Is there a life failure someplace (eg. bugzilla) that works after this 
patch?

thanks,
Len Brown, Intel Open Source Technology Center

On Tue, 16 Feb 2010, Matthew Garrett wrote:

> Right now, if _BQC returns a value we don't understand we immediately
> invalidate it. Change this behaviour so we only invalidate it if it
> continues to give an invalid answer after we've already set a brightness.
> 
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
> ---
>  drivers/acpi/video.c |   28 +++++++++++++++++-----------
>  1 files changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index b765790..ea314a2 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -327,7 +327,7 @@ static int acpi_video_device_lcd_set_level(struct acpi_video_device *device,
>  			int level);
>  static int acpi_video_device_lcd_get_level_current(
>  			struct acpi_video_device *device,
> -			unsigned long long *level);
> +			unsigned long long *level, int init);
>  static int acpi_video_get_next_level(struct acpi_video_device *device,
>  				     u32 level_current, u32 event);
>  static int acpi_video_switch_brightness(struct acpi_video_device *device,
> @@ -345,7 +345,7 @@ static int acpi_video_get_brightness(struct backlight_device *bd)
>  	struct acpi_video_device *vd =
>  		(struct acpi_video_device *)bl_get_data(bd);
>  
> -	if (acpi_video_device_lcd_get_level_current(vd, &cur_level))
> +	if (acpi_video_device_lcd_get_level_current(vd, &cur_level, 0))
>  		return -EINVAL;
>  	for (i = 2; i < vd->brightness->count; i++) {
>  		if (vd->brightness->levels[i] == cur_level)
> @@ -414,7 +414,7 @@ static int video_get_cur_state(struct thermal_cooling_device *cooling_dev, unsig
>  	unsigned long long level;
>  	int offset;
>  
> -	if (acpi_video_device_lcd_get_level_current(video, &level))
> +	if (acpi_video_device_lcd_get_level_current(video, &level, 0))
>  		return -EINVAL;
>  	for (offset = 2; offset < video->brightness->count; offset++)
>  		if (level == video->brightness->levels[offset]) {
> @@ -609,7 +609,7 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
>  
>  static int
>  acpi_video_device_lcd_get_level_current(struct acpi_video_device *device,
> -					unsigned long long *level)
> +					unsigned long long *level, int init)
>  {
>  	acpi_status status = AE_OK;
>  	int i;
> @@ -633,10 +633,16 @@ acpi_video_device_lcd_get_level_current(struct acpi_video_device *device,
>  					device->brightness->curr = *level;
>  					return 0;
>  			}
> -			/* BQC returned an invalid level. Stop using it.  */
> -			ACPI_WARNING((AE_INFO, "%s returned an invalid level",
> -						buf));
> -			device->cap._BQC = device->cap._BCQ = 0;
> +			if (!init) {
> +				/*
> +				 * BQC returned an invalid level.
> +				 * Stop using it.
> +				 */
> +				ACPI_WARNING((AE_INFO,
> +					      "%s returned an invalid level",
> +					      buf));
> +				device->cap._BQC = device->cap._BCQ = 0;
> +			}
>  		} else {
>  			/* Fixme:
>  			 * should we return an error or ignore this failure?
> @@ -892,7 +898,7 @@ acpi_video_init_brightness(struct acpi_video_device *device)
>  	if (!device->cap._BQC)
>  		goto set_level;
>  
> -	result = acpi_video_device_lcd_get_level_current(device, &level_old);
> +	result = acpi_video_device_lcd_get_level_current(device, &level_old, 1);
>  	if (result)
>  		goto out_free_levels;
>  
> @@ -903,7 +909,7 @@ acpi_video_init_brightness(struct acpi_video_device *device)
>  	if (result)
>  		goto out_free_levels;
>  
> -	result = acpi_video_device_lcd_get_level_current(device, &level);
> +	result = acpi_video_device_lcd_get_level_current(device, &level, 0);
>  	if (result)
>  		goto out_free_levels;
>  
> @@ -1996,7 +2002,7 @@ acpi_video_switch_brightness(struct acpi_video_device *device, int event)
>  		goto out;
>  
>  	result = acpi_video_device_lcd_get_level_current(device,
> -							 &level_current);
> +							 &level_current, 0);
>  	if (result)
>  		goto out;
>  
> -- 
> 1.6.6.1
> 
> --
> 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] ACPI video: Be more liberal in validating _BQC behaviour

[Matthew Garrett]

On Fri, Feb 19, 2010 at 01:40:47AM -0500, Len Brown wrote:
> Matthew,
> 
> Is there a life failure someplace (eg. bugzilla) that works after this 
> patch?

My system statically initialises the variable containing the current 
brightness to 100, but doesn't include 100 in the list of valid 
brightnesses. Right now this causes us to stop believing _BQC. However, 
the enxt thing we do is set the brightness to maximum anyway - at this 
point _BQC will now return a correct value. So it makes sense to ignore 
_BQC failures until we've set a valid value. If it continues to give 
invalid results then we can invalidate it and just use our internal 
state.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Zhang Rui]

On Fri, 2010-02-19 at 21:54 +0800, Matthew Garrett wrote:
> On Fri, Feb 19, 2010 at 01:40:47AM -0500, Len Brown wrote:
> > Matthew,
> > 
> > Is there a life failure someplace (eg. bugzilla) that works after this 
> > patch?
> 
> My system statically initialises the variable containing the current 
> brightness to 100, but doesn't include 100 in the list of valid 
> brightnesses.

sorry, I don't understand.
does the video driver set the backlight to 100, which is not a valid
value in the _BCL package?

>  Right now this causes us to stop believing _BQC. However, 
> the enxt thing we do is set the brightness to maximum anyway - at this 
> point _BQC will now return a correct value.

hmmm, could you attach the acpidump please?

thanks,
rui

>  So it makes sense to ignore 
> _BQC failures until we've set a valid value. If it continues to give 
> invalid results then we can invalidate it and just use our internal 
> state.
>  

Re: [PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Matthew Garrett]

On Mon, Feb 22, 2010 at 09:51:19AM +0800, Zhang Rui wrote:
> On Fri, 2010-02-19 at 21:54 +0800, Matthew Garrett wrote:
> > My system statically initialises the variable containing the current 
> > brightness to 100, but doesn't include 100 in the list of valid 
> > brightnesses.
> 
> sorry, I don't understand.
> does the video driver set the backlight to 100, which is not a valid
> value in the _BCL package?

No, the firmware does.

> >  Right now this causes us to stop believing _BQC. However, 
> > the enxt thing we do is set the brightness to maximum anyway - at this 
> > point _BQC will now return a correct value.
> 
> hmmm, could you attach the acpidump please?

The relevant bits are:

                    Name (BRIG, 0x64)
                    Method (_BQC, 0, Serialized)
                    {
                        Store (BRIG, Local0)
                        Return (Local0)
                    }
                    Method (_BCM, 1, Serialized)
                    {
			...
                        Store (Arg0, BRIG)

0x64 is an invalid value as far as _BCL goes. So, _BQC will give an 
invalid response until we set a value - after that, it'll be correct.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Thomas Renninger]

On Tuesday 16 February 2010 22:53:50 Matthew Garrett wrote:
> Right now, if _BQC returns a value we don't understand we immediately
> invalidate it. Change this behaviour so we only invalidate it if it
> continues to give an invalid answer after we've already set a brightness.
> 
> +			if (!init) {
> +				/*
> +				 * BQC returned an invalid level.
> +				 * Stop using it.
> +				 */
> +				ACPI_WARNING((AE_INFO,
> +					      "%s returned an invalid level",
> +					      buf));
Can you use:
printk(KERN_WARNING FW_WARN "%s returned an invalid level", buf);
instead please.
It would be great if major kernel contributors, especially those working
near the BIOS do make use of the FW_* strings more often!

Cleaning up existing messages is one (work intensive) thing, but please
use it to identify new BIOS issues.

Thanks,

   Thomas

Re: [PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Matthew Garrett]

On Mon, Feb 22, 2010 at 06:24:16PM +0100, Thomas Renninger wrote:

> Can you use:
> printk(KERN_WARNING FW_WARN "%s returned an invalid level", buf);
> instead please.
> It would be great if major kernel contributors, especially those working
> near the BIOS do make use of the FW_* strings more often!

I could, but I don't see there being any real benefit in doing so while 
the rest of the file doesn't make use of it. It seems like a reasonable 
thing to do in a followup patch.

> Cleaning up existing messages is one (work intensive) thing, but please
> use it to identify new BIOS issues.

This is just moving an existing warning, rather than adding a new issue.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH] ACPI video: Be more liberal in validating _BQC behaviour

[Zhang Rui]

On Mon, 2010-02-22 at 10:06 +0800, Matthew Garrett wrote:
> On Mon, Feb 22, 2010 at 09:51:19AM +0800, Zhang Rui wrote:
> > On Fri, 2010-02-19 at 21:54 +0800, Matthew Garrett wrote:
> > > My system statically initialises the variable containing the current 
> > > brightness to 100, but doesn't include 100 in the list of valid 
> > > brightnesses.
> > 
> > sorry, I don't understand.
> > does the video driver set the backlight to 100, which is not a valid
> > value in the _BCL package?
> 
> No, the firmware does.
> 
> > >  Right now this causes us to stop believing _BQC. However, 
> > > the enxt thing we do is set the brightness to maximum anyway - at this 
> > > point _BQC will now return a correct value.
> > 
> > hmmm, could you attach the acpidump please?
> 
> The relevant bits are:
> 
>                     Name (BRIG, 0x64)
>                     Method (_BQC, 0, Serialized)
>                     {
>                         Store (BRIG, Local0)
>                         Return (Local0)
>                     }
>                     Method (_BCM, 1, Serialized)
>                     {
> 			...
>                         Store (Arg0, BRIG)
> 
> 0x64 is an invalid value as far as _BCL goes. So, _BQC will give an 
> invalid response until we set a value - after that, it'll be correct.
> 
hmmm, then this seems reasonable.
Acked-by: Zhang Rui <rui.zhang@intel.com>

thanks,
rui