All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Lu <aaron.lu@intel.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Len Brown <lenb@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>
Subject: Re: [PATCH] acpi: video: fix reversed indexed BQC
Date: Fri, 02 Aug 2013 16:06:55 +0800	[thread overview]
Message-ID: <51FB689F.30100@intel.com> (raw)
In-Reply-To: <CAMP44s3+L8ZY9tcUbNhia8sRx+KJ1w44Jn7n=RMdPfeQqvPaqw@mail.gmail.com>

On 08/02/2013 03:59 PM, Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 1:56 AM, Aaron Lu <aaron.lu@intel.com> wrote:
>> On 08/02/2013 02:44 PM, Felipe Contreras wrote:
> 
>>> The initial _BCM commands don't work, so the level remains at 100%.
>>> Since the level is max_level, acpi_video_bqc_quirk() tries with the
>>> first level, which is 0, and 0 happens to be the index of 100.
>>>
>>> So _BQC is returning 100, which is not the index of 0 (what we tested
>>> for), but actually 100.
>>>
>>> I think the current code is correct, but acpi_video_bqc_quirk() should
>>> be testing br->levels[3], or anything other than 0/100 which can be
>>> easily confused.
>>>
>>> If so, the code would find that _BQC doesn't work on this machine (in
>>> win8 mode)... at least initially. My guess is that it only starts to
>>> work after acpi_video_bus_start_devices() is called.
>>>
>>> Forcing br->flags._BQC_use_index = 0 seems to work.
>>
>> Seems ASUS machines tend to have this issue:
>> https://bugzilla.kernel.org/show_bug.cgi?id=52951
>> https://bugzilla.kernel.org/show_bug.cgi?id=56711
> 
> I don't see any real solution for the ACPI driver.
> 
>> I have a patch to enhance the quirk some time ago:
>> https://github.com/aaronlu/linux/commit/0a3d2c5b59caf80ae5bb1ca1fda0f7bf448b38c9
> 
> I think this is unnecessarily complicated; the comment makes it clear

For your system, yes it is unnecessarily complicated. But since this is
a quirk, it better solves as many potential problems as possible, or we
would simply use a DMI entry to do the quirk.

-Aaron

> that the purpose is to find out if _BQC is working, and this does the
> trick:
> 
> From 2bfa401b0a50fcde292ac0eb60cb6f857caf2fc6 Mon Sep 17 00:00:00 2001
> From: Felipe Contreras <felipe.contreras@gmail.com>
> Date: Fri, 2 Aug 2013 02:27:44 -0500
> Subject: [PATCH] acpi: video: improve quirk check
> 
> If the _BCL package is descending, the first level (br->levels[2]) will
> be 0, and if the number of levels matches the number of steps, we might
> confuse a returned level to mean the index.
> 
> For example:
> 
>   current_level = max_level = 100
>   test_level = 0
>   returned level = 100
> 
> In this case 100 means the level, not the index, and _BCM failed. But if
> the _BCL package is descending, the index of level 0 is also 100, so we
> assume _BQC is indexed, when it's not.
> 
> The solution is simple; test anything other than the first level (e.g.
> 1).
> 
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
>  drivers/acpi/video.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 0ec434d..e1284b8 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -689,7 +689,7 @@ static int acpi_video_bqc_quirk(struct
> acpi_video_device *device,
>  	 * Some systems always report current brightness level as maximum
>  	 * through _BQC, we need to test another value for them.
>  	 */
> -	test_level = current_level == max_level ? br->levels[2] : max_level;
> +	test_level = current_level == max_level ? br->levels[3] : max_level;
> 
>  	result = acpi_video_device_lcd_set_level(device, test_level);
>  	if (result)
> 


  reply	other threads:[~2013-08-02  8:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 23:34 [PATCH] acpi: video: fix reversed indexed BQC Felipe Contreras
2013-08-02  2:03 ` Aaron Lu
2013-08-02  4:11   ` Felipe Contreras
2013-08-02  4:30     ` Aaron Lu
2013-08-02  4:50       ` Felipe Contreras
2013-08-02  4:59         ` Aaron Lu
2013-08-02  6:44           ` Felipe Contreras
2013-08-02  6:56             ` Aaron Lu
2013-08-02  7:59               ` Felipe Contreras
2013-08-02  8:06                 ` Aaron Lu [this message]
2013-08-02  8:14                   ` Felipe Contreras
2013-08-02  8:25                     ` Aaron Lu
2013-08-02 11:20                       ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51FB689F.30100@intel.com \
    --to=aaron.lu@intel.com \
    --cc=felipe.contreras@gmail.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.