Re: Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Sunday, August 04, 2013 09:33:43 PM Martin Steigerwald wrote:
> Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki:
> > On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote:
> > > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
> > > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  
> wrote:
> > > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and
> > > > > > > efaa14c?
> > > > > > 
> > > > > > Yes, but let's wait a while. Not because I think we'll fix the
> > > > > > problem
> > > > > > (hey, miracles might happen), but because I think it would be useful
> > > > > > to couple the reverts with information about the particular machines
> > > > > > that broke (and the people who reported it). So that when we
> > > > > > inevitably try again, we can perhaps get some testing effort with
> > > > > > those machines/people.
> > > > > > 
> > > > > > It doesn't seem to be a show-stopped for a large number of people,
> > > > > > so
> > > > > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > > > > rc3, but waiting until then to gather info about people who see
> > > > > > breakage.
> > > > > > 
> > > > > > Sound like a plan?
> > > > > 
> > > > > Yes, it does.
> > > > 
> > > > OK, time to revert I guess.
> > > > 
> > > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
> > > > patch fixes the backlight for you.
> > > 
> > > Rafael, do you still need more testing urgently? Otherwise I´d wait till
> > > its in some next 3.11 rc and test then.
> > 
> > Well, it seems to work for everybody else (Steven, Joerg, thanks for your
> > reports!), so I don't think you need to test it urgently.
> 
> Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on 
> this ThinkPad T520.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Martin Steigerwald]

Am Freitag, 26. Juli 2013, 14:40:58 schrieb Rafael J. Wysocki:
> On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote:
> > Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
> > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  
wrote:
> > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and
> > > > > > efaa14c?
> > > > > 
> > > > > Yes, but let's wait a while. Not because I think we'll fix the
> > > > > problem
> > > > > (hey, miracles might happen), but because I think it would be useful
> > > > > to couple the reverts with information about the particular machines
> > > > > that broke (and the people who reported it). So that when we
> > > > > inevitably try again, we can perhaps get some testing effort with
> > > > > those machines/people.
> > > > > 
> > > > > It doesn't seem to be a show-stopped for a large number of people,
> > > > > so
> > > > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > > > rc3, but waiting until then to gather info about people who see
> > > > > breakage.
> > > > > 
> > > > > Sound like a plan?
> > > > 
> > > > Yes, it does.
> > > 
> > > OK, time to revert I guess.
> > > 
> > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
> > > patch fixes the backlight for you.
> > 
> > Rafael, do you still need more testing urgently? Otherwise I´d wait till
> > its in some next 3.11 rc and test then.
> 
> Well, it seems to work for everybody else (Steven, Joerg, thanks for your
> reports!), so I don't think you need to test it urgently.

Just a late confirmation: With 3.11-rc3 back light stuff is working nicely on 
this ThinkPad T520.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Aaron Lu]

On 07/30/2013 03:36 AM, * SAMÍ * wrote:
> Hi Rafael,
> 
> 
> did you commit a full revert?
> Because I am experiencing quite weird things in rc3.
> Do we have a bug opened to discuss about it?

Yes we have:
https://bugzilla.kernel.org/show_bug.cgi?id=52951

I'll look into this issue.

Thanks,
Aaron

> 
> Here is what I can observe:
> 1) During boot, probably when loading the driver, backlight gets off (or 
> to a level low enough to make me feel it is off)
> 2) When I am playing with my Fn+x keys, I am getting a completely full / 
> completely low brightness with no intermediate steps
> 3) When I am playing with my Fn+x keys while gnome brightness settings 
> panel is open, I am recovering intermediate steps but the Fn+x keys 
> behavior is inverted (the key supposed to lower the brightness make it 
> increase and vice-versa. Note that the gnome brightness indicator also 
> gets inverted).
> 4) Playing with the mouse on gnome brightness settings is working, 
> except that on the minimum level, backlight gets off
> 5) Writing to /sys/class/backlight/intel_backlight/brightness works
> 
> 
> Regards
> 
> On 07/25/2013 02:57 PM, Rafael J. Wysocki wrote:
>> On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
>>> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
 On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
>> Well, I wonder what about the appended (untested) patch?
> Rafael, before going there, I've been trying to wrap my (poor, rusty
> after vacation) head around
>
> commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
> Author: Rafael J. Wysocki 
> Date:   Thu Jul 18 02:08:06 2013 +0200
>
>  ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
>
> and I can't see how it could work.
 Well, if it didn't work, people wouldn't see either improvement or breakage
 from it, but they do see that, so it evidently works. :-)
>>> I didn't claim it didn't work, just that *I* didn't see how it could. ;)
>>>
> First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
> it's actually set anywhere.
 Are you sure about that?

 acpi_video_bus_add() is the .add() callback routine for acpi_video_bus 
 which
 in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
 means that acpi_video_bus_add() can only be called *after* acpi_video_bus
 has been registered with the ACPI subsystem (and the driver core).  That
 is done by acpi_bus_register_driver() and, guess what?, this happens in
 __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run 
 before
 __acpi_video_register().
>>> Right. I totally missed the call within the ternary operator. Thanks for
>>> the explanation, and apologies for the noise.
>>>
> Second, with i915 that has opregion support, __acpi_video_register()
> should only ever get called once. Which means the acpi_walk_namespace()
> with video_unregister_backlight() should never get called in register.
>
> Please enlighten me.
 Actually, that's correct, so we don't need the whole
 video_unregister_backlight() thing, calling acpi_video_backlight_quirks() 
 would
 be sufficient.

 Ah, one more reason to do a full revert.  I'm thinking, though, that I'll 
 leave
 acpi_video_backlight_quirks() as is so that it can be used by
 acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
 problems to happen.
>>> I observe that for the regular non-quirk acpi_video_register() call,
>>> acpi_video_backlight_quirks() won't be called during register, but it
>>> will get called later. This might have subtle effects later on, don't
>>> you think?
>> Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK.
>>
>>> As to the original problem, and your patch in this thread, what do you
>>> think about having another value in acpi_backlight kernel parameter for
>>> it? Having an i915 module parameter to tell acpi to use or not use
>>> quirks seems odd, since the i915 is not really taking over
>>> anything. It's just passing the info on to acpi.
>> I agree, I'm going to send a full revert in a while and we'll think what to
>> do about all that later.
>>
>> Thanks,
>> Rafael
>>
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Monday, July 29, 2013 11:53:59 PM * SAMÍ * wrote:
> When I make acpi_video_backlight_quirks() return false:
> - the Fn+x keys are not working anymore (remember that they didn't work 
> in 3.10 nor 3.9)
> - At least the backlight remains on at boot.
> - Gnome brightness settings do not work anymore. Neither do xbacklight.
> - Writing to /sys/class/backlight/intel_backlight/brightness works

Well, you're better off with acpi_video_backlight_quirks() as is, then. :-)

I'm afraid we can't help you by revering anything more at this point.

Please file a bug in the kernel BZ to further track the issues you're
seeing.

Thanks,
Rafael


> On 07/29/2013 10:03 PM, Rafael J. Wysocki wrote:
> > On Monday, July 29, 2013 09:36:31 PM * SAMÍ * wrote:
> >> Hi Rafael,
> >>
> >>
> >> did you commit a full revert?
> > Yes, but I left acpi_video_backlight_quirks() (in 
> > drivers/acpi/video_detect.c)
> > that is used to decide what to do with _DOS.
> >
> > Can you please check if making that function always return 'false' makes any
> > difference?
> >
> > Rafael
> >
> >
> >> Because I am experiencing quite weird things in rc3.
> >> Do we have a bug opened to discuss about it?
> >>
> >> Here is what I can observe:
> >> 1) During boot, probably when loading the driver, backlight gets off (or
> >> to a level low enough to make me feel it is off)
> >> 2) When I am playing with my Fn+x keys, I am getting a completely full /
> >> completely low brightness with no intermediate steps
> >> 3) When I am playing with my Fn+x keys while gnome brightness settings
> >> panel is open, I am recovering intermediate steps but the Fn+x keys
> >> behavior is inverted (the key supposed to lower the brightness make it
> >> increase and vice-versa. Note that the gnome brightness indicator also
> >> gets inverted).
> >> 4) Playing with the mouse on gnome brightness settings is working,
> >> except that on the minimum level, backlight gets off
> >> 5) Writing to /sys/class/backlight/intel_backlight/brightness works
> >>
> >>
> >> Regards
> >>
> >> On 07/25/2013 02:57 PM, Rafael J. Wysocki wrote:
> >>> On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
>  On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> > On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
> >> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> >>> Well, I wonder what about the appended (untested) patch?
> >> Rafael, before going there, I've been trying to wrap my (poor, rusty
> >> after vacation) head around
> >>
> >> commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
> >> Author: Rafael J. Wysocki 
> >> Date:   Thu Jul 18 02:08:06 2013 +0200
> >>
> >>   ACPI / video / i915: No ACPI backlight if firmware expects 
> >> Windows 8
> >>
> >> and I can't see how it could work.
> > Well, if it didn't work, people wouldn't see either improvement or 
> > breakage
> > from it, but they do see that, so it evidently works. :-)
>  I didn't claim it didn't work, just that *I* didn't see how it could. ;)
> 
> >> First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
> >> it's actually set anywhere.
> > Are you sure about that?
> >
> > acpi_video_bus_add() is the .add() callback routine for acpi_video_bus 
> > which
> > in fact is an ACPI driver (the naming sucks, but I didn't invent it).  
> > This
> > means that acpi_video_bus_add() can only be called *after* 
> > acpi_video_bus
> > has been registered with the ACPI subsystem (and the driver core).  That
> > is done by acpi_bus_register_driver() and, guess what?, this happens in
> > __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run 
> > before
> > __acpi_video_register().
>  Right. I totally missed the call within the ternary operator. Thanks for
>  the explanation, and apologies for the noise.
> 
> >> Second, with i915 that has opregion support, __acpi_video_register()
> >> should only ever get called once. Which means the acpi_walk_namespace()
> >> with video_unregister_backlight() should never get called in register.
> >>
> >> Please enlighten me.
> > Actually, that's correct, so we don't need the whole
> > video_unregister_backlight() thing, calling 
> > acpi_video_backlight_quirks() would
> > be sufficient.
> >
> > Ah, one more reason to do a full revert.  I'm thinking, though, that 
> > I'll leave
> > acpi_video_backlight_quirks() as is so that it can be used by
> > acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to 
> > cause
> > problems to happen.
>  I observe that for the regular non-quirk acpi_video_register() call,
>  acpi_video_backlight_quirks() won't be called during register, but it
>  will get called later. This might have subtle effects later on, don't
>  you think?
> >>> Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIG

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[* SAMÍ *]

When I make acpi_video_backlight_quirks() return false:
- the Fn+x keys are not working anymore (remember that they didn't work 
in 3.10 nor 3.9)

- At least the backlight remains on at boot.
- Gnome brightness settings do not work anymore. Neither do xbacklight.
- Writing to /sys/class/backlight/intel_backlight/brightness works

Regards,
Sam

On 07/29/2013 10:03 PM, Rafael J. Wysocki wrote:

On Monday, July 29, 2013 09:36:31 PM * SAMÍ * wrote:

Hi Rafael,


did you commit a full revert?

Yes, but I left acpi_video_backlight_quirks() (in drivers/acpi/video_detect.c)
that is used to decide what to do with _DOS.

Can you please check if making that function always return 'false' makes any
difference?

Rafael



Because I am experiencing quite weird things in rc3.
Do we have a bug opened to discuss about it?

Here is what I can observe:
1) During boot, probably when loading the driver, backlight gets off (or
to a level low enough to make me feel it is off)
2) When I am playing with my Fn+x keys, I am getting a completely full /
completely low brightness with no intermediate steps
3) When I am playing with my Fn+x keys while gnome brightness settings
panel is open, I am recovering intermediate steps but the Fn+x keys
behavior is inverted (the key supposed to lower the brightness make it
increase and vice-versa. Note that the gnome brightness indicator also
gets inverted).
4) Playing with the mouse on gnome brightness settings is working,
except that on the minimum level, backlight gets off
5) Writing to /sys/class/backlight/intel_backlight/brightness works


Regards

On 07/25/2013 02:57 PM, Rafael J. Wysocki wrote:

On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:

On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:

On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:

On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:

Well, I wonder what about the appended (untested) patch?

Rafael, before going there, I've been trying to wrap my (poor, rusty
after vacation) head around

commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
Author: Rafael J. Wysocki 
Date:   Thu Jul 18 02:08:06 2013 +0200

  ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

and I can't see how it could work.

Well, if it didn't work, people wouldn't see either improvement or breakage
from it, but they do see that, so it evidently works. :-)

I didn't claim it didn't work, just that *I* didn't see how it could. ;)


First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
it's actually set anywhere.

Are you sure about that?

acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
means that acpi_video_bus_add() can only be called *after* acpi_video_bus
has been registered with the ACPI subsystem (and the driver core).  That
is done by acpi_bus_register_driver() and, guess what?, this happens in
__acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run before
__acpi_video_register().

Right. I totally missed the call within the ternary operator. Thanks for
the explanation, and apologies for the noise.


Second, with i915 that has opregion support, __acpi_video_register()
should only ever get called once. Which means the acpi_walk_namespace()
with video_unregister_backlight() should never get called in register.

Please enlighten me.

Actually, that's correct, so we don't need the whole
video_unregister_backlight() thing, calling acpi_video_backlight_quirks() would
be sufficient.

Ah, one more reason to do a full revert.  I'm thinking, though, that I'll leave
acpi_video_backlight_quirks() as is so that it can be used by
acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
problems to happen.

I observe that for the regular non-quirk acpi_video_register() call,
acpi_video_backlight_quirks() won't be called during register, but it
will get called later. This might have subtle effects later on, don't
you think?

Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK.


As to the original problem, and your patch in this thread, what do you
think about having another value in acpi_backlight kernel parameter for
it? Having an i915 module parameter to tell acpi to use or not use
quirks seems odd, since the i915 is not really taking over
anything. It's just passing the info on to acpi.

I agree, I'm going to send a full revert in a while and we'll think what to
do about all that later.

Thanks,
Rafael




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Monday, July 29, 2013 09:36:31 PM * SAMÍ * wrote:
> Hi Rafael,
> 
> 
> did you commit a full revert?

Yes, but I left acpi_video_backlight_quirks() (in drivers/acpi/video_detect.c)
that is used to decide what to do with _DOS.

Can you please check if making that function always return 'false' makes any
difference?

Rafael


> Because I am experiencing quite weird things in rc3.
> Do we have a bug opened to discuss about it?
> 
> Here is what I can observe:
> 1) During boot, probably when loading the driver, backlight gets off (or 
> to a level low enough to make me feel it is off)
> 2) When I am playing with my Fn+x keys, I am getting a completely full / 
> completely low brightness with no intermediate steps
> 3) When I am playing with my Fn+x keys while gnome brightness settings 
> panel is open, I am recovering intermediate steps but the Fn+x keys 
> behavior is inverted (the key supposed to lower the brightness make it 
> increase and vice-versa. Note that the gnome brightness indicator also 
> gets inverted).
> 4) Playing with the mouse on gnome brightness settings is working, 
> except that on the minimum level, backlight gets off
> 5) Writing to /sys/class/backlight/intel_backlight/brightness works
> 
> 
> Regards
> 
> On 07/25/2013 02:57 PM, Rafael J. Wysocki wrote:
> > On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
> >> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> >>> On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
>  On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> > Well, I wonder what about the appended (untested) patch?
>  Rafael, before going there, I've been trying to wrap my (poor, rusty
>  after vacation) head around
> 
>  commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
>  Author: Rafael J. Wysocki 
>  Date:   Thu Jul 18 02:08:06 2013 +0200
> 
>   ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
> 
>  and I can't see how it could work.
> >>> Well, if it didn't work, people wouldn't see either improvement or 
> >>> breakage
> >>> from it, but they do see that, so it evidently works. :-)
> >> I didn't claim it didn't work, just that *I* didn't see how it could. ;)
> >>
>  First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
>  it's actually set anywhere.
> >>> Are you sure about that?
> >>>
> >>> acpi_video_bus_add() is the .add() callback routine for acpi_video_bus 
> >>> which
> >>> in fact is an ACPI driver (the naming sucks, but I didn't invent it).  
> >>> This
> >>> means that acpi_video_bus_add() can only be called *after* acpi_video_bus
> >>> has been registered with the ACPI subsystem (and the driver core).  That
> >>> is done by acpi_bus_register_driver() and, guess what?, this happens in
> >>> __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run 
> >>> before
> >>> __acpi_video_register().
> >> Right. I totally missed the call within the ternary operator. Thanks for
> >> the explanation, and apologies for the noise.
> >>
>  Second, with i915 that has opregion support, __acpi_video_register()
>  should only ever get called once. Which means the acpi_walk_namespace()
>  with video_unregister_backlight() should never get called in register.
> 
>  Please enlighten me.
> >>> Actually, that's correct, so we don't need the whole
> >>> video_unregister_backlight() thing, calling acpi_video_backlight_quirks() 
> >>> would
> >>> be sufficient.
> >>>
> >>> Ah, one more reason to do a full revert.  I'm thinking, though, that I'll 
> >>> leave
> >>> acpi_video_backlight_quirks() as is so that it can be used by
> >>> acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to 
> >>> cause
> >>> problems to happen.
> >> I observe that for the regular non-quirk acpi_video_register() call,
> >> acpi_video_backlight_quirks() won't be called during register, but it
> >> will get called later. This might have subtle effects later on, don't
> >> you think?
> > Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK.
> >
> >> As to the original problem, and your patch in this thread, what do you
> >> think about having another value in acpi_backlight kernel parameter for
> >> it? Having an i915 module parameter to tell acpi to use or not use
> >> quirks seems odd, since the i915 is not really taking over
> >> anything. It's just passing the info on to acpi.
> > I agree, I'm going to send a full revert in a while and we'll think what to
> > do about all that later.
> >
> > Thanks,
> > Rafael
> >
> >
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[* SAMÍ *]

Hi Rafael,


did you commit a full revert?
Because I am experiencing quite weird things in rc3.
Do we have a bug opened to discuss about it?

Here is what I can observe:
1) During boot, probably when loading the driver, backlight gets off (or 
to a level low enough to make me feel it is off)
2) When I am playing with my Fn+x keys, I am getting a completely full / 
completely low brightness with no intermediate steps
3) When I am playing with my Fn+x keys while gnome brightness settings 
panel is open, I am recovering intermediate steps but the Fn+x keys 
behavior is inverted (the key supposed to lower the brightness make it 
increase and vice-versa. Note that the gnome brightness indicator also 
gets inverted).
4) Playing with the mouse on gnome brightness settings is working, 
except that on the minimum level, backlight gets off

5) Writing to /sys/class/backlight/intel_backlight/brightness works


Regards

On 07/25/2013 02:57 PM, Rafael J. Wysocki wrote:

On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:

On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:

On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:

On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:

Well, I wonder what about the appended (untested) patch?

Rafael, before going there, I've been trying to wrap my (poor, rusty
after vacation) head around

commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
Author: Rafael J. Wysocki 
Date:   Thu Jul 18 02:08:06 2013 +0200

 ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

and I can't see how it could work.

Well, if it didn't work, people wouldn't see either improvement or breakage
from it, but they do see that, so it evidently works. :-)

I didn't claim it didn't work, just that *I* didn't see how it could. ;)


First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
it's actually set anywhere.

Are you sure about that?

acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
means that acpi_video_bus_add() can only be called *after* acpi_video_bus
has been registered with the ACPI subsystem (and the driver core).  That
is done by acpi_bus_register_driver() and, guess what?, this happens in
__acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run before
__acpi_video_register().

Right. I totally missed the call within the ternary operator. Thanks for
the explanation, and apologies for the noise.


Second, with i915 that has opregion support, __acpi_video_register()
should only ever get called once. Which means the acpi_walk_namespace()
with video_unregister_backlight() should never get called in register.

Please enlighten me.

Actually, that's correct, so we don't need the whole
video_unregister_backlight() thing, calling acpi_video_backlight_quirks() would
be sufficient.

Ah, one more reason to do a full revert.  I'm thinking, though, that I'll leave
acpi_video_backlight_quirks() as is so that it can be used by
acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
problems to happen.

I observe that for the regular non-quirk acpi_video_register() call,
acpi_video_backlight_quirks() won't be called during register, but it
will get called later. This might have subtle effects later on, don't
you think?

Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK.


As to the original problem, and your patch in this thread, what do you
think about having another value in acpi_backlight kernel parameter for
it? Having an i915 module parameter to tell acpi to use or not use
quirks seems odd, since the i915 is not really taking over
anything. It's just passing the info on to acpi.

I agree, I'm going to send a full revert in a while and we'll think what to
do about all that later.

Thanks,
Rafael




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Saturday, July 27, 2013 08:34:13 AM Kalle Valo wrote:
> "Rafael J. Wysocki"  writes:
> 
> > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
> > patch
> > fixes the backlight for you.
> 
> I did three suspend-resume cycles and didn't notice anything wrong so
> this patch fixes the issue for me. I'll continue testing and will report
> if I spot any problems.
> 
> Tested-by: Kalle Valo 

Thanks a lot for the confirmation, this already is in the Linus' tree.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Kalle Valo]

"Rafael J. Wysocki"  writes:

> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
> fixes the backlight for you.

I did three suspend-resume cycles and didn't notice anything wrong so
this patch fixes the issue for me. I'll continue testing and will report
if I spot any problems.

Tested-by: Kalle Valo 

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Friday, July 26, 2013 02:09:08 PM Martin Steigerwald wrote:
> Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
> > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and
> > > > > efaa14c?
> > > > 
> > > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > > (hey, miracles might happen), but because I think it would be useful
> > > > to couple the reverts with information about the particular machines
> > > > that broke (and the people who reported it). So that when we
> > > > inevitably try again, we can perhaps get some testing effort with
> > > > those machines/people.
> > > > 
> > > > It doesn't seem to be a show-stopped for a large number of people, so
> > > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > > rc3, but waiting until then to gather info about people who see
> > > > breakage.
> > > > 
> > > > Sound like a plan?
> > > 
> > > Yes, it does.
> > 
> > OK, time to revert I guess.
> > 
> > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
> > patch fixes the backlight for you.
> 
> Rafael, do you still need more testing urgently? Otherwise I´d wait till its 
> in some next 3.11 rc and test then.

Well, it seems to work for everybody else (Steven, Joerg, thanks for your
reports!), so I don't think you need to test it urgently.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Martin Steigerwald]

Am Donnerstag, 25. Juli 2013, 15:00:26 schrieb Rafael J. Wysocki:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and
> > > > efaa14c?
> > > 
> > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > (hey, miracles might happen), but because I think it would be useful
> > > to couple the reverts with information about the particular machines
> > > that broke (and the people who reported it). So that when we
> > > inevitably try again, we can perhaps get some testing effort with
> > > those machines/people.
> > > 
> > > It doesn't seem to be a show-stopped for a large number of people, so
> > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > rc3, but waiting until then to gather info about people who see
> > > breakage.
> > > 
> > > Sound like a plan?
> > 
> > Yes, it does.
> 
> OK, time to revert I guess.
> 
> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended
> patch fixes the backlight for you.

Rafael, do you still need more testing urgently? Otherwise I´d wait till its 
in some next 3.11 rc and test then.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Igor Gnatenko]

On Thu, 2013-07-25 at 21:47 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote:
> > On 25 July 2013 14:00, Rafael J. Wysocki  wrote:
> > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  
> > >> > wrote:
> > >> > >
> > >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > >> > > efaa14c?
> > >> >
> > >> > Yes, but let's wait a while. Not because I think we'll fix the problem
> > >> > (hey, miracles might happen), but because I think it would be useful
> > >> > to couple the reverts with information about the particular machines
> > >> > that broke (and the people who reported it). So that when we
> > >> > inevitably try again, we can perhaps get some testing effort with
> > >> > those machines/people.
> > >> >
> > >> > It doesn't seem to be a show-stopped for a large number of people, so
> > >> > there's no huge hurry. I'd suggest doing the revert just in time for
> > >> > rc3, but waiting until then to gather info about people who see
> > >> > breakage.
> > >> >
> > >> > Sound like a plan?
> > >>
> > >> Yes, it does.
> > >
> > > OK, time to revert I guess.
> > >
> > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
> > > patch
> > > fixes the backlight for you.
> > 
> > Works for me
> 
> Great!
> 
> James, Kamal, Jörg, thanks for confirmations.  I'll tentatively put the revert
> into linux-next in a while.
> 
> Other people who experienced problems with backlight in 3.11-rc2, please let 
> me
> know whether or not the revert works for you too if you can.
> 
> Rafael
> 
> 

Rafael, feel free to CC me in messages with backlight ;) I want to test
its)
-- 
Igor Gnatenko
Fedora release 19 (Schrödinger’s Cat)
Linux 3.9.9-302.fc19.x86_64

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Steven Newbury]

On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > >
> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > efaa14c?
> > > 
> > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > (hey, miracles might happen), but because I think it would be useful
> > > to couple the reverts with information about the particular machines
> > > that broke (and the people who reported it). So that when we
> > > inevitably try again, we can perhaps get some testing effort with
> > > those machines/people.
> > > 
> > > It doesn't seem to be a show-stopped for a large number of people, so
> > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > rc3, but waiting until then to gather info about people who see
> > > breakage.
> > > 
> > > Sound like a plan?
> > 
> > Yes, it does.
> 
> OK, time to revert I guess.
> 
> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
> fixes the backlight for you.
> 
> Aaron, please double check if acpi_video_backlight_quirks() will still work as
> needed.
> 
> Thanks,
> Rafael
> 
> 
> ---
> From: Rafael J. Wysocki 
> Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects 
> Windows 8"
> 
> We attempted to address a regression introduced by commit a57f7f9
> (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
> ACPI video backlight support doesn't work on a number of systems,
> because the relevant AML methods in the ACPI tables in their BIOSes
> become useless after the BIOS has been told that the OS is compatible
> with Windows 8.  That problem is tracked by the bug entry at:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=51231
> 
> Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
> expects Windows 8) introduced for this purpose essentially prevented
> the ACPI backlight support from being used if the BIOS had been told
> that the OS was compatible with Windows 8 and the i915 driver was
> loaded, in which case the backlight would always be handled by i915.
> Unfortunately, however, that turned out to cause problems with
> backlight to appear on multiple systems with symptoms indicating that
> i915 was unable to control the backlight on those systems as
> expected.
> 
> For this reason, revert commit 8c5bd7a, but leave the function
> acpi_video_backlight_quirks() introduced by it, because another
> commit on top of it uses that function.
> 
Works fine for me.

Tested-by: Steven Newbury 

By the way, I'm willing to test any i915 backlight patches if it helps.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Joerg Platte]

On 25.07.2013 21:47, Rafael J. Wysocki wrote:


Other people who experienced problems with backlight in 3.11-rc2, please let me
know whether or not the revert works for you too if you can.


Before reverting the patch /sys/class/backlight was empty and backlight 
brightness was set to max, now it again contains a link to acpi_video0 
on my Thinkpad 420s with intel video and adjusting the backlight works 
again.


Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote:
> On 25 July 2013 14:00, Rafael J. Wysocki  wrote:
> > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> >> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> >> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> >> > >
> >> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> >> > > efaa14c?
> >> >
> >> > Yes, but let's wait a while. Not because I think we'll fix the problem
> >> > (hey, miracles might happen), but because I think it would be useful
> >> > to couple the reverts with information about the particular machines
> >> > that broke (and the people who reported it). So that when we
> >> > inevitably try again, we can perhaps get some testing effort with
> >> > those machines/people.
> >> >
> >> > It doesn't seem to be a show-stopped for a large number of people, so
> >> > there's no huge hurry. I'd suggest doing the revert just in time for
> >> > rc3, but waiting until then to gather info about people who see
> >> > breakage.
> >> >
> >> > Sound like a plan?
> >>
> >> Yes, it does.
> >
> > OK, time to revert I guess.
> >
> > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
> > patch
> > fixes the backlight for you.
> 
> Works for me

Great!

James, Kamal, Jörg, thanks for confirmations.  I'll tentatively put the revert
into linux-next in a while.

Other people who experienced problems with backlight in 3.11-rc2, please let me
know whether or not the revert works for you too if you can.

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[James Hogan]

On 25 July 2013 14:00, Rafael J. Wysocki  wrote:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
>> > >
>> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
>> > > efaa14c?
>> >
>> > Yes, but let's wait a while. Not because I think we'll fix the problem
>> > (hey, miracles might happen), but because I think it would be useful
>> > to couple the reverts with information about the particular machines
>> > that broke (and the people who reported it). So that when we
>> > inevitably try again, we can perhaps get some testing effort with
>> > those machines/people.
>> >
>> > It doesn't seem to be a show-stopped for a large number of people, so
>> > there's no huge hurry. I'd suggest doing the revert just in time for
>> > rc3, but waiting until then to gather info about people who see
>> > breakage.
>> >
>> > Sound like a plan?
>>
>> Yes, it does.
>
> OK, time to revert I guess.
>
> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
> fixes the backlight for you.

Works for me

Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Jörg Otte]

2013/7/25 Jörg Otte :
> 2013/7/25 Rafael J. Wysocki :
>> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
>>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
>>> > >
>>> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
>>> > > efaa14c?
>>> >
>>> > Yes, but let's wait a while. Not because I think we'll fix the problem
>>> > (hey, miracles might happen), but because I think it would be useful
>>> > to couple the reverts with information about the particular machines
>>> > that broke (and the people who reported it). So that when we
>>> > inevitably try again, we can perhaps get some testing effort with
>>> > those machines/people.
>>> >
>>> > It doesn't seem to be a show-stopped for a large number of people, so
>>> > there's no huge hurry. I'd suggest doing the revert just in time for
>>> > rc3, but waiting until then to gather info about people who see
>>> > breakage.
>>> >
>>> > Sound like a plan?
>>>
>>> Yes, it does.
>>
>> OK, time to revert I guess.
>>
>> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
>> patch
>> fixes the backlight for you.
>>
>
> Problems, problems :-) I tried to apply on top of 3.11-rc2:
>

Ok, with the help of Kamal I got my source tree back to a consistent
state. The patch now applies successfully.

Rafael, I now can confirm the patch fixes the problems for me.

Thanks, Jörg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Kamal Mostafa]

On Thu, 2013-07-25 at 16:46 +0200, Daniel Vetter wrote:
> On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
> > On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  
> > > > > wrote:
> > > > > >
> > > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > > > efaa14c?
> > > > > 
> > > > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > > > (hey, miracles might happen), but because I think it would be useful
> > > > > to couple the reverts with information about the particular machines
> > > > > that broke (and the people who reported it). So that when we
> > > > > inevitably try again, we can perhaps get some testing effort with
> > > > > those machines/people.
> > > > > 
> > > > > It doesn't seem to be a show-stopped for a large number of people, so
> > > > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > > > rc3, but waiting until then to gather info about people who see
> > > > > breakage.
> > > > > 
> > > > > Sound like a plan?
> > > > 
> > > > Yes, it does.
> > > 
> > > OK, time to revert I guess.
> > > 
> > > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
> > > patch
> > > fixes the backlight for you.
> > 
> > Yes, this revert patch does re-enable backlight control for the affected
> > Dell XPS13 models.
> 
> Are these the same models that neeed the special quirk to not write
> PCH_PWM_ENABLE? Or do they need both?

Hi Daniel-

Yes, these are the same models (Dell XPS13) that need the PCH_PWM_ENABLE
quirk, but that's not related to this ACPI problem...

All of the XPS13 models still need the PCH_PWM_ENABLE quirk which is now
present in mainline (e85843b "drm/i915: quirk no PCH_PWM_ENABLE for Dell
XPS13 backlight").

Separately from that, some of the XPS13 models were _also_ adversely
affected (as were some other machines) by the ACPI changes that are
about to be reverted.

 -Kamal



signature.asc
Description: This is a digitally signed message part

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Jörg Otte]

2013/7/25 Rafael J. Wysocki :
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
>> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
>> > >
>> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
>> > > efaa14c?
>> >
>> > Yes, but let's wait a while. Not because I think we'll fix the problem
>> > (hey, miracles might happen), but because I think it would be useful
>> > to couple the reverts with information about the particular machines
>> > that broke (and the people who reported it). So that when we
>> > inevitably try again, we can perhaps get some testing effort with
>> > those machines/people.
>> >
>> > It doesn't seem to be a show-stopped for a large number of people, so
>> > there's no huge hurry. I'd suggest doing the revert just in time for
>> > rc3, but waiting until then to gather info about people who see
>> > breakage.
>> >
>> > Sound like a plan?
>>
>> Yes, it does.
>
> OK, time to revert I guess.
>
> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
> fixes the backlight for you.
>

Problems, problems :-) I tried to apply on top of 3.11-rc2:

jojo@ahorn:/data/kernel/linux$ git log --pretty=oneline | head -5
3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b Linux 3.11-rc2
ea45ea70b6131fa0b006f5b687b9b1398b24f681 Merge tag 'acpi-video-3.11'
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
90db76e829479ef2ba1fed8f2552846015469831 Merge tag 'ext4_for_linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
dda5690defe4af62ee120f055e98e40d97e4c760 ext3: fix a BUG when opening
a file with O_TMPFILE flag
e94bd3490f4ef342801cfc76b33d8baf9ccc9437 ext4: fix a BUG when opening
a file with O_TMPFILE flag

jojo@ahorn:/data/kernel/linux$ git apply --check
/data/kernel/acpi-backlight-revert.patch
error: patch failed: drivers/acpi/video.c:897
error: drivers/acpi/video.c: patch does not apply
error: patch failed: drivers/gpu/drm/i915/i915_dma.c:1648
error: drivers/gpu/drm/i915/i915_dma.c: patch does not apply
error: patch failed: include/acpi/video.h:17
error: include/acpi/video.h: patch does not apply
error: patch failed: drivers/acpi/video_detect.c:235
error: drivers/acpi/video_detect.c: patch does not apply
error: patch failed: include/linux/acpi.h:191
error: include/linux/acpi.h: patch does not apply
error: patch failed: drivers/acpi/internal.h:169
error: drivers/acpi/internal.h: patch does not apply
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Daniel Vetter]

On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
> On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > > >
> > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > > efaa14c?
> > > > 
> > > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > > (hey, miracles might happen), but because I think it would be useful
> > > > to couple the reverts with information about the particular machines
> > > > that broke (and the people who reported it). So that when we
> > > > inevitably try again, we can perhaps get some testing effort with
> > > > those machines/people.
> > > > 
> > > > It doesn't seem to be a show-stopped for a large number of people, so
> > > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > > rc3, but waiting until then to gather info about people who see
> > > > breakage.
> > > > 
> > > > Sound like a plan?
> > > 
> > > Yes, it does.
> > 
> > OK, time to revert I guess.
> > 
> > James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended 
> > patch
> > fixes the backlight for you.
> 
> Yes, this revert patch does re-enable backlight control for the affected
> Dell XPS13 models.

Are these the same models that neeed the special quirk to not write
PCH_PWM_ENABLE? Or do they need both?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Kamal Mostafa]

On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > >
> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > efaa14c?
> > > 
> > > Yes, but let's wait a while. Not because I think we'll fix the problem
> > > (hey, miracles might happen), but because I think it would be useful
> > > to couple the reverts with information about the particular machines
> > > that broke (and the people who reported it). So that when we
> > > inevitably try again, we can perhaps get some testing effort with
> > > those machines/people.
> > > 
> > > It doesn't seem to be a show-stopped for a large number of people, so
> > > there's no huge hurry. I'd suggest doing the revert just in time for
> > > rc3, but waiting until then to gather info about people who see
> > > breakage.
> > > 
> > > Sound like a plan?
> > 
> > Yes, it does.
> 
> OK, time to revert I guess.
> 
> James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
> fixes the backlight for you.

Yes, this revert patch does re-enable backlight control for the affected
Dell XPS13 models.

 -Kamal


> Aaron, please double check if acpi_video_backlight_quirks() will still work as
> needed.
> 
> Thanks,
> Rafael
> 
> 
> ---
> From: Rafael J. Wysocki 
> Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects 
> Windows 8"
> 
> We attempted to address a regression introduced by commit a57f7f9
> (ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
> ACPI video backlight support doesn't work on a number of systems,
> because the relevant AML methods in the ACPI tables in their BIOSes
> become useless after the BIOS has been told that the OS is compatible
> with Windows 8.  That problem is tracked by the bug entry at:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=51231
> 
> Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
> expects Windows 8) introduced for this purpose essentially prevented
> the ACPI backlight support from being used if the BIOS had been told
> that the OS was compatible with Windows 8 and the i915 driver was
> loaded, in which case the backlight would always be handled by i915.
> Unfortunately, however, that turned out to cause problems with
> backlight to appear on multiple systems with symptoms indicating that
> i915 was unable to control the backlight on those systems as
> expected.
> 
> For this reason, revert commit 8c5bd7a, but leave the function
> acpi_video_backlight_quirks() introduced by it, because another
> commit on top of it uses that function.
> 
> References: https://lkml.org/lkml/2013/7/21/119
> References: https://lkml.org/lkml/2013/7/22/261
> References: https://lkml.org/lkml/2013/7/23/429
> References: https://lkml.org/lkml/2013/7/23/459
> References: https://lkml.org/lkml/2013/7/23/81
> References: https://lkml.org/lkml/2013/7/24/27
> Reported-by: James Hogan 
> Reported-by: Steven Newbury 
> Reported-by: Kamal Mostafa 
> Reported-by: Martin Steigerwald 
> Reported-by: Jörg Otte 
> Reported-by: Kalle Valo 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/acpi/internal.h |2 -
>  drivers/acpi/video.c|   67 
> 
>  drivers/acpi/video_detect.c |   15 
>  drivers/gpu/drm/i915/i915_dma.c |2 -
>  include/acpi/video.h|   11 --
>  include/linux/acpi.h|1 
>  6 files changed, 11 insertions(+), 87 deletions(-)
> 
> Index: linux-pm/drivers/acpi/video.c
> ===
> --- linux-pm.orig/drivers/acpi/video.c
> +++ linux-pm/drivers/acpi/video.c
> @@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s
>   if (acpi_video_init_brightness(device))
>   return;
>  
> - if (acpi_video_verify_backlight_support()) {
> + if (acpi_video_backlight_support()) {
>   struct backlight_properties props;
>   struct pci_dev *pdev;
>   acpi_handle acpi_parent;
> @@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi
>   unsigned long long level_current, level_next;
>   int result = -EINVAL;
>  
> - /* no warning message if acpi_backlight=vendor or a quirk is used */
> - if (!acpi_video_verify_backlight_support())
> + /* no warning message if acpi_backlight=vendor is used */
> + if (!acpi_video_backlight_support())
>   return 0;
>  
>   if (!device->brightness)
> @@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct
>   return 0;
>  }
>  
> -static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
> -   void *context, void **rv)
> -{
> - struct acpi_device *acpi_dev;
> - struct acpi_video_bus *video;
> - s

Re: Linux 3.11-rc2 (acpi backlight, revert)

[Rafael J. Wysocki]

On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > >
> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > efaa14c?
> > 
> > Yes, but let's wait a while. Not because I think we'll fix the problem
> > (hey, miracles might happen), but because I think it would be useful
> > to couple the reverts with information about the particular machines
> > that broke (and the people who reported it). So that when we
> > inevitably try again, we can perhaps get some testing effort with
> > those machines/people.
> > 
> > It doesn't seem to be a show-stopped for a large number of people, so
> > there's no huge hurry. I'd suggest doing the revert just in time for
> > rc3, but waiting until then to gather info about people who see
> > breakage.
> > 
> > Sound like a plan?
> 
> Yes, it does.

OK, time to revert I guess.

James, Kamal, Steven, Jörg, Martin, Kalle, please check if the apppended patch
fixes the backlight for you.

Aaron, please double check if acpi_video_backlight_quirks() will still work as
needed.

Thanks,
Rafael


---
From: Rafael J. Wysocki 
Subject: Revert "ACPI / video / i915: No ACPI backlight if firmware expects 
Windows 8"

We attempted to address a regression introduced by commit a57f7f9
(ACPICA: Add Windows8/Server2012 string for _OSI method.) after which
ACPI video backlight support doesn't work on a number of systems,
because the relevant AML methods in the ACPI tables in their BIOSes
become useless after the BIOS has been told that the OS is compatible
with Windows 8.  That problem is tracked by the bug entry at:

https://bugzilla.kernel.org/show_bug.cgi?id=51231

Commit 8c5bd7a (ACPI / video / i915: No ACPI backlight if firmware
expects Windows 8) introduced for this purpose essentially prevented
the ACPI backlight support from being used if the BIOS had been told
that the OS was compatible with Windows 8 and the i915 driver was
loaded, in which case the backlight would always be handled by i915.
Unfortunately, however, that turned out to cause problems with
backlight to appear on multiple systems with symptoms indicating that
i915 was unable to control the backlight on those systems as
expected.

For this reason, revert commit 8c5bd7a, but leave the function
acpi_video_backlight_quirks() introduced by it, because another
commit on top of it uses that function.

References: https://lkml.org/lkml/2013/7/21/119
References: https://lkml.org/lkml/2013/7/22/261
References: https://lkml.org/lkml/2013/7/23/429
References: https://lkml.org/lkml/2013/7/23/459
References: https://lkml.org/lkml/2013/7/23/81
References: https://lkml.org/lkml/2013/7/24/27
Reported-by: James Hogan 
Reported-by: Steven Newbury 
Reported-by: Kamal Mostafa 
Reported-by: Martin Steigerwald 
Reported-by: Jörg Otte 
Reported-by: Kalle Valo 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/internal.h |2 -
 drivers/acpi/video.c|   67 
 drivers/acpi/video_detect.c |   15 
 drivers/gpu/drm/i915/i915_dma.c |2 -
 include/acpi/video.h|   11 --
 include/linux/acpi.h|1 
 6 files changed, 11 insertions(+), 87 deletions(-)

Index: linux-pm/drivers/acpi/video.c
===
--- linux-pm.orig/drivers/acpi/video.c
+++ linux-pm/drivers/acpi/video.c
@@ -897,7 +897,7 @@ static void acpi_video_device_find_cap(s
if (acpi_video_init_brightness(device))
return;
 
-   if (acpi_video_verify_backlight_support()) {
+   if (acpi_video_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
@@ -1344,8 +1344,8 @@ acpi_video_switch_brightness(struct acpi
unsigned long long level_current, level_next;
int result = -EINVAL;
 
-   /* no warning message if acpi_backlight=vendor or a quirk is used */
-   if (!acpi_video_verify_backlight_support())
+   /* no warning message if acpi_backlight=vendor is used */
+   if (!acpi_video_backlight_support())
return 0;
 
if (!device->brightness)
@@ -1843,46 +1843,6 @@ static int acpi_video_bus_remove(struct
return 0;
 }
 
-static acpi_status video_unregister_backlight(acpi_handle handle, u32 lvl,
- void *context, void **rv)
-{
-   struct acpi_device *acpi_dev;
-   struct acpi_video_bus *video;
-   struct acpi_video_device *dev, *next;
-
-   if (acpi_bus_get_device(handle, &acpi_dev))
-   return AE_OK;
-
-   if (acpi_match_device_ids(acpi_dev, video_device_ids))
-   return AE_OK;
-
-   video = acpi_driver_data(acpi_dev);
-   if (!video)
-   return AE_OK;
-
-   acpi_video_bus_stop_devices(video);
-   

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> > On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
> >> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> >> > Well, I wonder what about the appended (untested) patch?
> >> 
> >> Rafael, before going there, I've been trying to wrap my (poor, rusty
> >> after vacation) head around
> >> 
> >> commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
> >> Author: Rafael J. Wysocki 
> >> Date:   Thu Jul 18 02:08:06 2013 +0200
> >> 
> >> ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
> >> 
> >> and I can't see how it could work.
> >
> > Well, if it didn't work, people wouldn't see either improvement or breakage
> > from it, but they do see that, so it evidently works. :-)
> 
> I didn't claim it didn't work, just that *I* didn't see how it could. ;)
> 
> >> First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
> >> it's actually set anywhere.
> >
> > Are you sure about that?
> >
> > acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
> > in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
> > means that acpi_video_bus_add() can only be called *after* acpi_video_bus
> > has been registered with the ACPI subsystem (and the driver core).  That
> > is done by acpi_bus_register_driver() and, guess what?, this happens in
> > __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run 
> > before
> > __acpi_video_register().
> 
> Right. I totally missed the call within the ternary operator. Thanks for
> the explanation, and apologies for the noise.
> 
> >> Second, with i915 that has opregion support, __acpi_video_register()
> >> should only ever get called once. Which means the acpi_walk_namespace()
> >> with video_unregister_backlight() should never get called in register.
> >> 
> >> Please enlighten me.
> >
> > Actually, that's correct, so we don't need the whole
> > video_unregister_backlight() thing, calling acpi_video_backlight_quirks() 
> > would
> > be sufficient.
> >
> > Ah, one more reason to do a full revert.  I'm thinking, though, that I'll 
> > leave
> > acpi_video_backlight_quirks() as is so that it can be used by
> > acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
> > problems to happen.
> 
> I observe that for the regular non-quirk acpi_video_register() call,
> acpi_video_backlight_quirks() won't be called during register, but it
> will get called later. This might have subtle effects later on, don't
> you think?

Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK.

> As to the original problem, and your patch in this thread, what do you
> think about having another value in acpi_backlight kernel parameter for
> it? Having an i915 module parameter to tell acpi to use or not use
> quirks seems odd, since the i915 is not really taking over
> anything. It's just passing the info on to acpi.

I agree, I'm going to send a full revert in a while and we'll think what to
do about all that later.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Jani Nikula]

On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
>> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
>> > Well, I wonder what about the appended (untested) patch?
>> 
>> Rafael, before going there, I've been trying to wrap my (poor, rusty
>> after vacation) head around
>> 
>> commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
>> Author: Rafael J. Wysocki 
>> Date:   Thu Jul 18 02:08:06 2013 +0200
>> 
>> ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
>> 
>> and I can't see how it could work.
>
> Well, if it didn't work, people wouldn't see either improvement or breakage
> from it, but they do see that, so it evidently works. :-)

I didn't claim it didn't work, just that *I* didn't see how it could. ;)

>> First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
>> it's actually set anywhere.
>
> Are you sure about that?
>
> acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
> in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
> means that acpi_video_bus_add() can only be called *after* acpi_video_bus
> has been registered with the ACPI subsystem (and the driver core).  That
> is done by acpi_bus_register_driver() and, guess what?, this happens in
> __acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run before
> __acpi_video_register().

Right. I totally missed the call within the ternary operator. Thanks for
the explanation, and apologies for the noise.

>> Second, with i915 that has opregion support, __acpi_video_register()
>> should only ever get called once. Which means the acpi_walk_namespace()
>> with video_unregister_backlight() should never get called in register.
>> 
>> Please enlighten me.
>
> Actually, that's correct, so we don't need the whole
> video_unregister_backlight() thing, calling acpi_video_backlight_quirks() 
> would
> be sufficient.
>
> Ah, one more reason to do a full revert.  I'm thinking, though, that I'll 
> leave
> acpi_video_backlight_quirks() as is so that it can be used by
> acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
> problems to happen.

I observe that for the regular non-quirk acpi_video_register() call,
acpi_video_backlight_quirks() won't be called during register, but it
will get called later. This might have subtle effects later on, don't
you think?

As to the original problem, and your patch in this thread, what do you
think about having another value in acpi_backlight kernel parameter for
it? Having an i915 module parameter to tell acpi to use or not use
quirks seems odd, since the i915 is not really taking over
anything. It's just passing the info on to acpi.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
> On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> > On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
> >> On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter  
> >> wrote:
> >> >
> >> > I think a i915 module option should be doable, otoh people seem to have a
> >> > viable workaround by setting a different acpi os version already.
> >> 
> >> At least the original claim was that if you set a non-windows8 acpi os
> >> version, you hit other bugs..
> >> 
> >> But yeah, if we just do a plain revert, that may be the only option
> >> for the people for whom the current (to-be-reverted) patches made
> >> things work.
> >
> > Well, I wonder what about the appended (untested) patch?
> 
> Rafael, before going there, I've been trying to wrap my (poor, rusty
> after vacation) head around
> 
> commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
> Author: Rafael J. Wysocki 
> Date:   Thu Jul 18 02:08:06 2013 +0200
> 
> ACPI / video / i915: No ACPI backlight if firmware expects Windows 8
> 
> and I can't see how it could work.

Well, if it didn't work, people wouldn't see either improvement or breakage
from it, but they do see that, so it evidently works. :-)

> First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
> it's actually set anywhere.

Are you sure about that?

acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which
in fact is an ACPI driver (the naming sucks, but I didn't invent it).  This
means that acpi_video_bus_add() can only be called *after* acpi_video_bus
has been registered with the ACPI subsystem (and the driver core).  That
is done by acpi_bus_register_driver() and, guess what?, this happens in
__acpi_video_register().  So clearly, acpi_video_bus_add() *cannot* run before
__acpi_video_register().

> Buried deep in the calls from
> acpi_video_bus_add(), acpi_video_verify_backlight_support() is used
> before acpi_video_backlight_quirks() gets called. (Perhaps if i915 is
> reloaded, this goes right as the flags are already set.)

Please see above.

> Second, with i915 that has opregion support, __acpi_video_register()
> should only ever get called once. Which means the acpi_walk_namespace()
> with video_unregister_backlight() should never get called in register.
> 
> Please enlighten me.

Actually, that's correct, so we don't need the whole
video_unregister_backlight() thing, calling acpi_video_backlight_quirks() would
be sufficient.

Ah, one more reason to do a full revert.  I'm thinking, though, that I'll leave
acpi_video_backlight_quirks() as is so that it can be used by
acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause
problems to happen.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Jani Nikula]

On Thu, 25 Jul 2013, "Rafael J. Wysocki"  wrote:
> On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
>> On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter  
>> wrote:
>> >
>> > I think a i915 module option should be doable, otoh people seem to have a
>> > viable workaround by setting a different acpi os version already.
>> 
>> At least the original claim was that if you set a non-windows8 acpi os
>> version, you hit other bugs..
>> 
>> But yeah, if we just do a plain revert, that may be the only option
>> for the people for whom the current (to-be-reverted) patches made
>> things work.
>
> Well, I wonder what about the appended (untested) patch?

Rafael, before going there, I've been trying to wrap my (poor, rusty
after vacation) head around

commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255
Author: Rafael J. Wysocki 
Date:   Thu Jul 18 02:08:06 2013 +0200

ACPI / video / i915: No ACPI backlight if firmware expects Windows 8

and I can't see how it could work.

First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before
it's actually set anywhere. Buried deep in the calls from
acpi_video_bus_add(), acpi_video_verify_backlight_support() is used
before acpi_video_backlight_quirks() gets called. (Perhaps if i915 is
reloaded, this goes right as the flags are already set.)

Second, with i915 that has opregion support, __acpi_video_register()
should only ever get called once. Which means the acpi_walk_namespace()
with video_unregister_backlight() should never get called in register.

Please enlighten me.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
> On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter  wrote:
> >
> > I think a i915 module option should be doable, otoh people seem to have a
> > viable workaround by setting a different acpi os version already.
> 
> At least the original claim was that if you set a non-windows8 acpi os
> version, you hit other bugs..
> 
> But yeah, if we just do a plain revert, that may be the only option
> for the people for whom the current (to-be-reverted) patches made
> things work.

Well, I wonder what about the appended (untested) patch?

It should restore the previous behavior while leaving an option to use the
new stuff if need be.

Rafael


---
 drivers/gpu/drm/i915/i915_dma.c |2 +-
 drivers/gpu/drm/i915/i915_drv.c |5 +
 drivers/gpu/drm/i915/i915_drv.h |1 +
 include/acpi/video.h|   16 ++--
 4 files changed, 13 insertions(+), 11 deletions(-)

Index: linux-pm/drivers/gpu/drm/i915/i915_dma.c
===
--- linux-pm.orig/drivers/gpu/drm/i915/i915_dma.c
+++ linux-pm/drivers/gpu/drm/i915/i915_dma.c
@@ -1648,7 +1648,7 @@ int i915_driver_load(struct drm_device *
if (INTEL_INFO(dev)->num_pipes) {
/* Must be done after probing outputs */
intel_opregion_init(dev);
-   acpi_video_register_with_quirks();
+   __acpi_video_register(i915_take_over_backlight);
}
 
if (IS_GEN5(dev))
Index: linux-pm/drivers/gpu/drm/i915/i915_drv.c
===
--- linux-pm.orig/drivers/gpu/drm/i915/i915_drv.c
+++ linux-pm/drivers/gpu/drm/i915/i915_drv.c
@@ -132,6 +132,11 @@ int i915_enable_ips __read_mostly = 1;
 module_param_named(enable_ips, i915_enable_ips, int, 0600);
 MODULE_PARM_DESC(enable_ips, "Enable IPS (default: true)");
 
+bool i915_take_over_backlight __read_mostly = false;
+module_param_named(take_over_backlight, i915_take_over_backlight, bool, 0644);
+MODULE_PARM_DESC(take_over_backlight,
+"Prevent ACPI backlight from being used (default: false)");
+
 static struct drm_driver driver;
 extern int intel_agp_enabled;
 
Index: linux-pm/drivers/gpu/drm/i915/i915_drv.h
===
--- linux-pm.orig/drivers/gpu/drm/i915/i915_drv.h
+++ linux-pm/drivers/gpu/drm/i915/i915_drv.h
@@ -1542,6 +1542,7 @@ extern int i915_enable_ppgtt __read_most
 extern unsigned int i915_preliminary_hw_support __read_mostly;
 extern int i915_disable_power_well __read_mostly;
 extern int i915_enable_ips __read_mostly;
+extern bool i915_take_over_backlight __read_mostly;
 
 extern int i915_suspend(struct drm_device *dev, pm_message_t state);
 extern int i915_resume(struct drm_device *dev);
Index: linux-pm/include/acpi/video.h
===
--- linux-pm.orig/include/acpi/video.h
+++ linux-pm/include/acpi/video.h
@@ -18,20 +18,11 @@ struct acpi_device;
 
 #if (defined CONFIG_ACPI_VIDEO || defined CONFIG_ACPI_VIDEO_MODULE)
 extern int __acpi_video_register(bool backlight_quirks);
-static inline int acpi_video_register(void)
-{
-   return __acpi_video_register(false);
-}
-static inline int acpi_video_register_with_quirks(void)
-{
-   return __acpi_video_register(true);
-}
 extern void acpi_video_unregister(void);
 extern int acpi_video_get_edid(struct acpi_device *device, int type,
   int device_id, void **edid);
 #else
-static inline int acpi_video_register(void) { return 0; }
-static inline int acpi_video_register_with_quirks(void) { return 0; }
+static inline int __acpi_video_register(bool backlight_quirks) { return 0; }
 static inline void acpi_video_unregister(void) { return; }
 static inline int acpi_video_get_edid(struct acpi_device *device, int type,
  int device_id, void **edid)
@@ -40,4 +31,9 @@ static inline int acpi_video_get_edid(st
 }
 #endif
 
+static inline int acpi_video_register(void)
+{
+   return __acpi_video_register(false);
+}
+
 #endif

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Linus Torvalds]

On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter  wrote:
>
> I think a i915 module option should be doable, otoh people seem to have a
> viable workaround by setting a different acpi os version already.

At least the original claim was that if you set a non-windows8 acpi os
version, you hit other bugs..

But yeah, if we just do a plain revert, that may be the only option
for the people for whom the current (to-be-reverted) patches made
things work.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Daniel Vetter]

On Wed, Jul 24, 2013 at 10:39 PM, Linus Torvalds 
 wrote:
> On Wed, Jul 24, 2013 at 12:39 PM, Rafael J. Wysocki  wrote:
>>
>> Well, there seems to be a number of people who'll be equally unhappy if I 
>> don't
>> do that.  Unfortunately for you, things work for them without that patch.
>
> So I think we have to revert the behavior back, but I wonder if we
> could keep the logic and have a i915 kernel command line option to
> enable it.
>
> We did that for a long time with "drm.modeset" and the
> "i915.enable_rc6" mess. We still have the "i915.invert_brightness"
> thing, although I don't know who actually uses it. But that option is
> itself an indication that the i915 driver still has some backlight
> issues.

invert_brighntess seems to be real, at least we have a pile of quirk
entries for Acer and Packard Bell machines. Generally I'm not too happy
with module options since they tend to get stuck eternally in a limbo
state where everyone in the know sets them to their liking and no one
bothers to fix the underlying.

Otoh this is the backlight and I've essentially given up and opted for
quirk entries :(

> But if that kind of "revert behavior" isn't easy, we need to just
> revert the patches entirely.

I think a i915 module option should be doable, otoh people seem to have a
viable workaround by setting a different acpi os version already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Linus Torvalds]

On Wed, Jul 24, 2013 at 12:39 PM, Rafael J. Wysocki  wrote:
>
> Well, there seems to be a number of people who'll be equally unhappy if I 
> don't
> do that.  Unfortunately for you, things work for them without that patch.

So I think we have to revert the behavior back, but I wonder if we
could keep the logic and have a i915 kernel command line option to
enable it.

We did that for a long time with "drm.modeset" and the
"i915.enable_rc6" mess. We still have the "i915.invert_brightness"
thing, although I don't know who actually uses it. But that option is
itself an indication that the i915 driver still has some backlight
issues.

But if that kind of "revert behavior" isn't easy, we need to just
revert the patches entirely.

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Wednesday, July 24, 2013 08:43:00 PM * SAMÍ * wrote:
> Hi,
> 
> it seems a lot of people are complaining about the backlight pull 
> request of RC2.
> 
> This is to tell you how it saved my life:
> - Changing brightness from Fn keys does work
> - Writing to /sys/class/backlight/intel_backlight/brightness does work
> - Changing brightness from gnome brightness settings does work
> --> It seems everything is now working (it wasn't before).
> --> I appreciate your patch and I am going to be sad if you revert it :-)

Well, there seems to be a number of people who'll be equally unhappy if I don't
do that.  Unfortunately for you, things work for them without that patch.

The source of the problem seems to be that the i915's backlight support doesn't
work for all those people, although it should work anyway in principle.  So to
me the way to go seems to be to revert the patch for now, fix the i915
backlight interface for them and try to apply it again when we're more
confident about the i915 backlight.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[Rafael J. Wysocki]

On Wednesday, July 24, 2013 10:55:32 PM Igor Gnatenko wrote:
> Rafael, I think we shall create bug report with this problems. Doesn't
> works sysfs Intel backlight.

Yes, it looks like that is the source of the problems that people have after
the change in question.

Thanks,
Rafael


> On Jul 24, 2013 10:49 PM, "* SAMÍ *"  wrote:
> 
> > Hi,
> >
> > it seems a lot of people are complaining about the backlight pull request
> > of RC2.
> >
> > This is to tell you how it saved my life:
> > - Changing brightness from Fn keys does work
> > - Writing to /sys/class/backlight/intel_**backlight/brightness does work
> > - Changing brightness from gnome brightness settings does work
> > --> It seems everything is now working (it wasn't before).
> > --> I appreciate your patch and I am going to be sad if you revert it :-)
> >
> >
> > My laptop : Asus N56VZ
> > My /proc/cpuinfo: https://bugs.launchpad.net/**ubuntu/+source/linux/+bug/*
> > *1030556/+attachment/3241093/+**files/ProcCpuinfo.txt
> > My dmidecode is below.
> >
> > Changing brightness from Fn keys didn't work on 3.9 and 3.10 kernels.
> > I a not sure for previous versions though a patch was made for 3.2 in
> > ubuntu. See details here:
> > https://bugs.launchpad.net/**ubuntu/+source/linux/+bug/**1030556
> >
> > There are a lot of bugs opened for this:
> > https://bugs.launchpad.net/**ubuntu/+source/linux/+bug/**1173107
> > http://askubuntu.com/**questions/156708/how-to-get-**
> > multimedia-keys-working-at-my-**asus-n56vz-ubuntu-12-04-**notebook
> > https://bugs.archlinux.org/**task/35320
> >
> > Regards
> > Sam
> >
> >
> > # dmidecode 2.11
> > # SMBIOS entry point at 0x000f04c0
> > SMBIOS 2.7 present.
> > 23 structures occupying 1708 bytes.
> > Table at 0x000EBA70.
> >
> > Handle 0x, DMI type 0, 24 bytes
> > BIOS Information
> > Vendor: American Megatrends Inc.
> > Version: N56VZ.215
> > Release Date: 11/02/2012
> > Address: 0xF
> > Runtime Size: 64 kB
> > ROM Size: 6144 kB
> > Characteristics:
> > PCI is supported
> > BIOS is upgradeable
> > BIOS shadowing is allowed
> > Boot from CD is supported
> > Selectable boot is supported
> > BIOS ROM is socketed
> > EDD is supported
> > 5.25"/1.2 MB floppy services are supported (int 13h)
> > 3.5"/720 kB floppy services are supported (int 13h)
> > 3.5"/2.88 MB floppy services are supported (int 13h)
> > Print screen service is supported (int 5h)
> > 8042 keyboard services are supported (int 9h)
> > Serial services are supported (int 14h)
> > Printer services are supported (int 17h)
> > ACPI is supported
> > USB legacy is supported
> > Smart battery is supported
> > BIOS boot specification is supported
> > Targeted content distribution is supported
> > UEFI is supported
> > BIOS Revision: 4.6
> >
> > Handle 0x0001, DMI type 1, 27 bytes
> > System Information
> > Manufacturer: ASUSTeK COMPUTER INC.
> > Product Name: N56VZ
> > Version: 1.0
> > Serial Number: C6N0AS306834244
> > UUID: 10017880-B5B7-81E1-3FDF-**3085A9061B75
> > Wake-up Type: Power Switch
> > SKU Number: ASUS-NotebookSKU
> > Family: N
> >
> > Handle 0x0002, DMI type 2, 15 bytes
> > Base Board Information
> > Manufacturer: ASUSTeK COMPUTER INC.
> > Product Name: N56VZ
> > Version: 1.0
> > Serial Number: BSN12345678901234567
> > Asset Tag: ATN12345678901234567
> > Features:
> > Board is a hosting board
> > Board is replaceable
> > Location In Chassis: MIDDLE
> > Chassis Handle: 0x0003
> > Type: Motherboard
> > Contained Object Handles: 0
> >
> > Handle 0x0003, DMI type 3, 22 bytes
> > Chassis Information
> > Manufacturer: ASUSTeK COMPUTER INC.
> > Type: Notebook
> > Lock: Not Present
> > Version: 1.0
> > Serial Number: C6N0AS306834244
> > Asset Tag: No Asset Tag
> > Boot-up State: Safe
> > Power Supply State: Safe
> > Thermal State: Safe
> > Security Status: None
> > OEM Information: 0x
> > Height: Unspecified
> > Number Of Power Cords: 1
> > Contained Elements: 0
> > SKU Number: To be filled by O.E.M.
> >
> > Handle 0x0004, DMI type 10, 26 bytes
> > On Board Device 1 Information
> > Type: Video
> > Status: Enabled
> > Description:  VGA
> > On Board Device 2 Information
> > Type: Ethernet
> > Status: Enabled
> > Description:  GLAN
> > On Board Device 3 Information
> > Type: Ethernet
> > Status: Enabled

Re: Linux 3.11-rc2 [backlight] [ASUS N56VZ]

[* SAMÍ *]

Hi,

it seems a lot of people are complaining about the backlight pull 
request of RC2.


This is to tell you how it saved my life:
- Changing brightness from Fn keys does work
- Writing to /sys/class/backlight/intel_backlight/brightness does work
- Changing brightness from gnome brightness settings does work
--> It seems everything is now working (it wasn't before).
--> I appreciate your patch and I am going to be sad if you revert it :-)


My laptop : Asus N56VZ
My /proc/cpuinfo: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1030556/+attachment/3241093/+files/ProcCpuinfo.txt

My dmidecode is below.

Changing brightness from Fn keys didn't work on 3.9 and 3.10 kernels.
I a not sure for previous versions though a patch was made for 3.2 in 
ubuntu. See details here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1030556

There are a lot of bugs opened for this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173107
http://askubuntu.com/questions/156708/how-to-get-multimedia-keys-working-at-my-asus-n56vz-ubuntu-12-04-notebook 


https://bugs.archlinux.org/task/35320

Regards
Sam


# dmidecode 2.11
# SMBIOS entry point at 0x000f04c0
SMBIOS 2.7 present.
23 structures occupying 1708 bytes.
Table at 0x000EBA70.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: N56VZ.215
Release Date: 11/02/2012
Address: 0xF
Runtime Size: 64 kB
ROM Size: 6144 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: N56VZ
Version: 1.0
Serial Number: C6N0AS306834244
UUID: 10017880-B5B7-81E1-3FDF-3085A9061B75
Wake-up Type: Power Switch
SKU Number: ASUS-NotebookSKU
Family: N

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: N56VZ
Version: 1.0
Serial Number: BSN12345678901234567
Asset Tag: ATN12345678901234567
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: MIDDLE
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: ASUSTeK COMPUTER INC.
Type: Notebook
Lock: Not Present
Version: 1.0
Serial Number: C6N0AS306834244
Asset Tag: No Asset Tag
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: To be filled by O.E.M.

Handle 0x0004, DMI type 10, 26 bytes
On Board Device 1 Information
Type: Video
Status: Enabled
Description:  VGA
On Board Device 2 Information
Type: Ethernet
Status: Enabled
Description:  GLAN
On Board Device 3 Information
Type: Ethernet
Status: Enabled
Description:  WLAN
On Board Device 4 Information
Type: Sound
Status: Enabled
Description:  Audio CODEC
On Board Device 5 Information
Type: SATA Controller
Status: Enabled
Description:  SATA Controller
On Board Device 6 Information
Type: Other
Status: Enabled
Description:  USB 2.0 Controller
On Board Device 7 Information
Type: Other
Status: Enabled
Description:  USB 3.0 Controller
On Board Device 8 Information
Type: Other
Status: Enabled
Description:  SMBus Controller
On Board Device 9 Information
Type: Other
Status: Enabled
Description:  Card Reader
On Board Device 10 Information
Type: Other
Status: Enabled
Description:  Cmos Camera
On Board Device 11 Information
Type: Other
Status: Enabled
Description:  Bluetooth

Handle 0x0005, DMI type 11, 5 bytes
OEM Strings
String 1: 6kfb9jsNVeN50
String 2: I76yifUckyZ2n
String 3: W0-kvTpaXZUpn
String 4: 90N9IC442L1875VL355Y
String 5:
String 6:
String 7:
String 8:
String 9:
String 10:

Handle 0x0006, DMI type 12, 5 bytes
System Configuration Options
Option 1: DSN:W54S4QJE
Option 2: DSN:57B1609A5803
Option 3:

Re: Linux 3.11-rc2 (acpi backlight)

[Rafael J. Wysocki]

On Wednesday, July 24, 2013 11:19:10 AM Igor Gnatenko wrote:
> On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote:
> > On 24 July 2013 01:05, Rafael J. Wysocki  wrote:
> > > I'd like to collect some information on the systems having problems with 
> > > those
> > > two commits (to see if they are similar somehow).
> > >
> > > It seems that one common symptom is that brightness cannot be controlled
> > > through function keys.  Is that correct for all of you?  If so, did you 
> > > try
> > > any other way to control brightness, like a GUI-based?
> > 
> > For me both the Fn keys and the gui slider (kde) now control
> > /sys/class/backlight/intel_backlight/brightness (which has no effect).
> > Previously they both controlled the acpi one (that on -rc2 doesn't
> > exist).
> I think this problem in i915 drivers.
> Rafael, Mathew, Aaron, fix me please

Yes, it is my impression too.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Jörg Otte]

2013/7/24 Rafael J. Wysocki :
> On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote:
>> On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote:
>> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
>> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
>> > > >
>> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
>> > > > efaa14c?
>> > >
>> > > Yes, but [...] I'd suggest doing the revert just in time for
>> > > rc3, but waiting until then to gather info about people who see
>> > > breakage.
>> > >
>> > > Sound like a plan?
>> >
>> > Yes, it does.
>> >
>> > Rafael
>>
>>
>> Hi Rafael-
>>
>> For your reference...
>>
>> As James Hogan reported, those ACPI changes break backlight control on
>> the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not
>> affected).
>>
>> I confirm that reverting 8c5bd7a and efaa14c fixes it again.
>
> Thanks!
>
> I'd like to collect some information on the systems having problems with those
> two commits (to see if they are similar somehow).
>
> It seems that one common symptom is that brightness cannot be controlled
> through function keys.  Is that correct for all of you?
Yes

>  If so, did you try
> any other way to control brightness, like a GUI-based?
Yes, it has no visible effect.

> Also, can you all please send me (a) the output of dmidecode and (b) the
> contents of /proc/cpuinfo from your systems?


# dmidecode 2.11
# SMBIOS entry point at 0xdae8b000
SMBIOS 2.7 present.
36 structures occupying 1727 bytes.
Table at 0x000E0B70.

Handle 0x, DMI type 4, 42 bytes
Processor Information
Socket Designation: CPU Socket - U3E1
Type: Central Processor
Family: Core i7
Manufacturer: Intel(R) Corporation
ID: A9 06 03 00 FF FB EB BF
Signature: Type 0, Family 6, Model 58, Stepping 9
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
Voltage: 0.9 V
External Clock: 100 MHz
Max Speed: 2500 MHz
Current Speed: 2500 MHz
Status: Populated, Enabled
Upgrade: Socket rPGA988B
L1 Cache Handle: 0x0002
L2 Cache Handle: 0x0003
L3 Cache Handle: 0x0004
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 2
Core Enabled: 2
Thread Count: 4
Characteristics:
64-bit capable

Handle 0x0001, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1-Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Through
Location: Internal
Installed Size: 32 kB
Maximum Size: 32 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Parity
System Type: Data
Associativity: 8-way Set-associative

Handle 0x0002, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1-Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Through
Location: Internal
Installed Size: 32 kB
Maximum Size: 32 kB
Supported SRAM Types:
Unknown
Installed SRAM Type: Unknown
Speed: Unknown
Error Correction Type: Parity
System Type: Instruction
Associativity: 8-way Set-associative

Handle 0x0003, DMI type 7, 19 bytes
Cache Information
Socket Designation: L2-Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Through
Location: Internal
Installed Size: 

Re: Linux 3.11-rc2 (acpi backlight)

[Igor Gnatenko]

On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote:
> On 24 July 2013 01:05, Rafael J. Wysocki  wrote:
> > I'd like to collect some information on the systems having problems with 
> > those
> > two commits (to see if they are similar somehow).
> >
> > It seems that one common symptom is that brightness cannot be controlled
> > through function keys.  Is that correct for all of you?  If so, did you try
> > any other way to control brightness, like a GUI-based?
> 
> For me both the Fn keys and the gui slider (kde) now control
> /sys/class/backlight/intel_backlight/brightness (which has no effect).
> Previously they both controlled the acpi one (that on -rc2 doesn't
> exist).
I think this problem in i915 drivers.
Rafael, Mathew, Aaron, fix me please
> 
> >
> > Also, can you all please send me (a) the output of dmidecode and (b) the
> > contents of /proc/cpuinfo from your systems?
> 
> attached


-- 
Igor Gnatenko
Fedora release 19 (Schrödinger’s Cat)
Linux 3.9.9-302.fc19.x86_64

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Mike Galbraith]

On Wed, 2013-07-24 at 07:49 +0100, James Hogan wrote: 
> On 24 July 2013 01:05, Rafael J. Wysocki  wrote:
> > I'd like to collect some information on the systems having problems with 
> > those
> > two commits (to see if they are similar somehow).
> >
> > It seems that one common symptom is that brightness cannot be controlled
> > through function keys.  Is that correct for all of you?  If so, did you try
> > any other way to control brightness, like a GUI-based?
> 
> For me both the Fn keys and the gui slider (kde) now control
> /sys/class/backlight/intel_backlight/brightness (which has no effect).
> Previously they both controlled the acpi one (that on -rc2 doesn't
> exist).

Hm, poking Fn keys make kde slider widget appear on my Toshiba Satellite
but do nada, never did, and I never looked into it, assumed there was no
canned functionality for my lappy, so use a setpci script instead.

Lappy has acpi_video0, which gui is twiddling, and does nothing, as does
toshiba, while intel_backlight works.

Suppose I should put latest/greatest kernel on the thing, maybe my Fn
keys will magically start turning the _right_ knob.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[James Hogan]

On 24 July 2013 01:05, Rafael J. Wysocki  wrote:
> I'd like to collect some information on the systems having problems with those
> two commits (to see if they are similar somehow).
>
> It seems that one common symptom is that brightness cannot be controlled
> through function keys.  Is that correct for all of you?  If so, did you try
> any other way to control brightness, like a GUI-based?

For me both the Fn keys and the gui slider (kde) now control
/sys/class/backlight/intel_backlight/brightness (which has no effect).
Previously they both controlled the acpi one (that on -rc2 doesn't
exist).

>
> Also, can you all please send me (a) the output of dmidecode and (b) the
> contents of /proc/cpuinfo from your systems?

attached
-- 
James Hogan
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
stepping: 9
microcode   : 0x17
cpu MHz : 2300.000
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx 
f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 4988.23
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
stepping: 9
microcode   : 0x17
cpu MHz : 1500.000
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx 
f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 4988.23
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
stepping: 9
microcode   : 0x17
cpu MHz : 2375.000
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx 
f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 4988.23
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
stepping: 9
microcode   : 0x17
cpu MHz : 2375.000
cache size  : 4096 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx 
f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase sme

Re: Linux 3.11-rc2

[Kalle Valo]

"Rafael J. Wysocki"  writes:

> Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and see
> if that helps.

On 3.11-rc2-wl (from wireless-testing.git) my Thinkpad X230 display went
really dark every time during resume and I had to blindly write to sysfs
to be able to see anything. With 3.10-wl I didn't see this. Reverting
the commits above fixed the issue for me.

I'm using Ubuntu 12.04 64 bit. More info about my laptop:

  thinkpad_acpi: ThinkPad ACPI Extras v0.24
  thinkpad_acpi: http://ibm-acpi.sf.net/
  thinkpad_acpi: ThinkPad BIOS G2ET82WW (2.02 ), EC unknown
  thinkpad_acpi: Lenovo ThinkPad X230, model 2324JB2
  thinkpad_acpi: detected a 8-level brightness capable ThinkPad
  thinkpad_acpi: radio switch found; radios are enabled
  thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness
  control, supported by the ACPI video driver
  thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
  thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
  thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked
  thinkpad_acpi: Standard ACPI backlight interface available, not
  loading native one
  thinkpad_acpi: Console audio control enabled, mode: monitor (read
  only)
  input: ThinkPad Extra Buttons as
  /devices/platform/thinkpad_acpi/input/input5

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Steven Newbury]

On Wed, 2013-07-24 at 02:05 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote:
> > On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > > >
> > > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > > efaa14c?
> > > > 
> > > > Yes, but [...] I'd suggest doing the revert just in time for
> > > > rc3, but waiting until then to gather info about people who see
> > > > breakage.
> > > > 
> > > > Sound like a plan?
> > > 
> > > Yes, it does.
> > > 
> > > Rafael
> > 
> > 
> > Hi Rafael-
> > 
> > For your reference...
> > 
> > As James Hogan reported, those ACPI changes break backlight control on
> > the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not
> > affected).
> > 
> > I confirm that reverting 8c5bd7a and efaa14c fixes it again.
> 
> Thanks!
> 
> I'd like to collect some information on the systems having problems with those
> two commits (to see if they are similar somehow).
> 
> It seems that one common symptom is that brightness cannot be controlled
> through function keys.  Is that correct for all of you?  If so, did you try
> any other way to control brightness, like a GUI-based?
> 
> Also, can you all please send me (a) the output of dmidecode and (b) the
> contents of /proc/cpuinfo from your systems?
> 
> Rafael
> 
> 

Attached.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2212.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 1960.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MHz : 2716.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 2
cpu cores   : 4
apicid  : 4
initial apicid  : 4
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave 
avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi 
flexpriority ept vpid fsgsbase smep erms
bogomips: 5587.12
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz
stepping: 9
microcode   : 0x15
cpu MH

Re: Linux 3.11-rc2

[Dave Chinner]

On Mon, Jul 22, 2013 at 05:06:01AM +0100, Al Viro wrote:
> On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote:
> 
> > I'll just point out that it can make the whole thing worse, too.
> > For example, for ext3/4, the tmpfile being created has to be added
> > to the orphan inode list which is protected by a filesystem global
> > mutex. Hence scalability of O_TMPFILE is massively limited on
> > ext3/ext4 due to architectural issues within ext3/4. Other
> > filesystems will be more efficient, but because they have more
> > scalable/complex orphan inode handling it's going to take longer to
> > implement O_TMPFILE support for them
> 
> Um...  You do realize that the same architectural issues there will
> create exactly the same serialization when you are unlinking the
> sucker?  I.e. with the "pick the name, create and open, unlink" sequence
> ext[34] will insert that inode into the same orphan list, creating
> the same contention...

Yup.

But that is assuming that the unlink of the tmpfile happens
immediately after the open() and that's not necessarily the case for
all users of tmp files that might get converted to use O_TMPFILE,
and so a saying it is more efficient than traditional tmpfiles is
not necessarily correct.

Let's set expectations appropriately at the start, rather than have
people complain a year down the track that O_TMPFILE causes them
performance problems because they don't understand the limitations
of the implementations underlying it..

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Rafael J. Wysocki]

On Tuesday, July 23, 2013 11:46:29 AM Kamal Mostafa wrote:
> On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > > >
> > > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > > efaa14c?
> > > 
> > > Yes, but [...] I'd suggest doing the revert just in time for
> > > rc3, but waiting until then to gather info about people who see
> > > breakage.
> > > 
> > > Sound like a plan?
> > 
> > Yes, it does.
> > 
> > Rafael
> 
> 
> Hi Rafael-
> 
> For your reference...
> 
> As James Hogan reported, those ACPI changes break backlight control on
> the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not
> affected).
> 
> I confirm that reverting 8c5bd7a and efaa14c fixes it again.

Thanks!

I'd like to collect some information on the systems having problems with those
two commits (to see if they are similar somehow).

It seems that one common symptom is that brightness cannot be controlled
through function keys.  Is that correct for all of you?  If so, did you try
any other way to control brightness, like a GUI-based?

Also, can you all please send me (a) the output of dmidecode and (b) the
contents of /proc/cpuinfo from your systems?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Tue, 2013-07-23 at 23:24 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 23, 2013 06:47:55 PM Steven Newbury wrote:
> > On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
> > > On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
> > > > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
> > > > 
> > > > > In the meantime I received a report from Steven Newbury that these 
> > > > > changes
> > > > > broke things for him too, so we need to revert commits 8c5bd7a and 
> > > > > efaa14c.
> > > > > The other two commits in the series should be benign.
> > > > 
> > > > Could you let me know the details of this problem?
> > > 
> > > Steven, can you please describe the problem you're seeing to Matthew and
> > > the other people on the list?
> > > 
> > > Rafael
> > > 
> > 
> > Before the changes backlight was working fine using the ACPI method: 
> > /sys/class/backlight/acpi_video0/ is present and the keyboard function keys
> > control brightness with notifications working in GNOME.
> > 
> > In the code as was present in the linux-pm/bleeding-edge tree I would
> > encounter a hard lockup on keyboard brightness trigger.  This also occurred 
> > with
> > the code as it initially hit mainline, but a later commit fixed the crash*, 
> > but
> > resulted in no backlight controls being available at all.
> > /sys/class/backlight  is empty.
> > 
> > *not actually sure if /sys/class/backlight contained anything before this
> 
> Hmm.  Which commit fixed the crash for you?
> 
> Rafael
> 

I'll see if I can build a broken kernel tomorrow, after backing up! ;-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Tuesday, July 23, 2013 06:47:55 PM Steven Newbury wrote:
> On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
> > On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
> > > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
> > > 
> > > > In the meantime I received a report from Steven Newbury that these 
> > > > changes
> > > > broke things for him too, so we need to revert commits 8c5bd7a and 
> > > > efaa14c.
> > > > The other two commits in the series should be benign.
> > > 
> > > Could you let me know the details of this problem?
> > 
> > Steven, can you please describe the problem you're seeing to Matthew and
> > the other people on the list?
> > 
> > Rafael
> > 
> 
> Before the changes backlight was working fine using the ACPI method: 
> /sys/class/backlight/acpi_video0/ is present and the keyboard function keys
> control brightness with notifications working in GNOME.
> 
> In the code as was present in the linux-pm/bleeding-edge tree I would
> encounter a hard lockup on keyboard brightness trigger.  This also occurred 
> with
> the code as it initially hit mainline, but a later commit fixed the crash*, 
> but
> resulted in no backlight controls being available at all.
> /sys/class/backlight  is empty.
> 
> *not actually sure if /sys/class/backlight contained anything before this

Hmm.  Which commit fixed the crash for you?

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Steven Newbury]

On Tue, 2013-07-23 at 19:51 +, Matthew Garrett wrote:
> On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote:
> 
> > In the code as was present in the linux-pm/bleeding-edge tree I would
> > encounter a hard lockup on keyboard brightness trigger.  This also occurred 
> > with
> > the code as it initially hit mainline, but a later commit fixed the crash*, 
> > but
> > resulted in no backlight controls being available at all.
> > /sys/class/backlight  is empty.
> 
> This is an Intel system using the i915 driver?
> 

Yes, IVB i7-3840QM.  CLEVO W270EUQ.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Myklebust, Trond]

On Tue, 2013-07-23 at 13:42 -0700, Linus Torvalds wrote:
> On Tue, Jul 23, 2013 at 12:08 PM,   wrote:
> > Hi Trond,
> >
> >> OK. With Andre's help, I think we've root caused the problem. Can you
> >> please confirm that the attached patch also solves the issue for you?
> >
> > Seems to work fine,
> >
> >Reported-and-tested-by: Henrik Rydberg 
> 
> Trond, do you have anything else pending and are planning a git pull,
> or should I just take this patch directly?

Nothing else queued for now, so if you could take it directly, then that
would save the trouble of setting up an extra pull.

Thanks!
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.com

Re: Linux 3.11-rc2

[Linus Torvalds]

On Tue, Jul 23, 2013 at 12:08 PM,   wrote:
> Hi Trond,
>
>> OK. With Andre's help, I think we've root caused the problem. Can you
>> please confirm that the attached patch also solves the issue for you?
>
> Seems to work fine,
>
>Reported-and-tested-by: Henrik Rydberg 

Trond, do you have anything else pending and are planning a git pull,
or should I just take this patch directly?

   Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Matthew Garrett]

On Tue, 2013-07-23 at 18:47 +0100, Steven Newbury wrote:

> In the code as was present in the linux-pm/bleeding-edge tree I would
> encounter a hard lockup on keyboard brightness trigger.  This also occurred 
> with
> the code as it initially hit mainline, but a later commit fixed the crash*, 
> but
> resulted in no backlight controls being available at all.
> /sys/class/backlight  is empty.

This is an Intel system using the i915 driver?

-- 
Matthew Garrett | mj...@srcf.ucam.org
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: Linux 3.11-rc2

[rydberg]

Hi Trond,

> OK. With Andre's help, I think we've root caused the problem. Can you
> please confirm that the attached patch also solves the issue for you?

Seems to work fine,

   Reported-and-tested-by: Henrik Rydberg 

Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2 (acpi backlight)

[Kamal Mostafa]

On Mon, 2013-07-22 at 21:54 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> > On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> > >
> > > Linus, do you want me to send a pull request reverting 8c5bd7a and 
> > > efaa14c?
> > 
> > Yes, but [...] I'd suggest doing the revert just in time for
> > rc3, but waiting until then to gather info about people who see
> > breakage.
> > 
> > Sound like a plan?
> 
> Yes, it does.
> 
> Rafael


Hi Rafael-

For your reference...

As James Hogan reported, those ACPI changes break backlight control on
the "Dell XPS13" Ivy Bridge models (the Sandy Bridge XPS13 model is not
affected).

I confirm that reverting 8c5bd7a and efaa14c fixes it again.


Also FYI...

On Mon, 2013-07-22 at 00:08 +0100, James Hogan wrote:
> Note that acpi_video0 only worked because I was applying "[PATCH]
> drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
> strictly speaking mainline already didn't work.
>  [1] http://lkml.org/lkml/2013/7/19/748

That patch is now queued up in drm-intel/drm-intel-fixes, so should be
making its way to mainline soon.

 -Kamal



signature.asc
Description: This is a digitally signed message part

Re: Linux 3.11-rc2

[Myklebust, Trond]

On Mon, 2013-07-22 at 21:17 -0400, Trond Myklebust wrote:
> On Tue, 2013-07-23 at 03:04 +0200, rydb...@euromail.se wrote:
> > Hi Trond, Linus,
> > 
> > On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote:
> > > So it's been another week, and -rc2 is out there.
> > 
> > This one happens to break nfs in a rather blunt-instrument fashion -
> > creating files on a nfs4 partition [1] no longer works. Bisection
> > yields this commit as the culprit:
> > 
> > commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd
> > Author: Trond Myklebust 
> > Date:   Wed Jul 17 16:43:16 2013 -0400
> > 
> > NFSv4: Fix a regression against the FreeBSD server
> > 
> > Technically, the Linux client is allowed by the NFSv4 spec to send
> > 3 word bitmaps as part of an OPEN request. However, this causes the
> > current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors.
> > 
> > Fix the regression by making the Linux client use a 2 word bitmap unless
> > doing NFSv4.2 with labeled NFS.
> > 
> > Signed-off-by: Trond Myklebust 
> > 
> > Reverting the patch returns things to normal.
> 
> - Can you please provide me with a binary tcpdump or wireshark dump that
> demonstrates the problem?
> 
> - What server is this?

OK. With Andre's help, I think we've root caused the problem. Can you
please confirm that the attached patch also solves the issue for you?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.com
From 1f84e4f9ef9fc4ff502c112df049dfa6f656f4e0 Mon Sep 17 00:00:00 2001
From: Trond Myklebust 
Date: Tue, 23 Jul 2013 12:53:39 -0400
Subject: [PATCH] NFSv4: Fix brainfart in attribute length calculation

The calculation of the attribute length was 4 bytes off.

Signed-off-by: Trond Myklebust 
Tested-by: Andre Heider 
---
 fs/nfs/nfs4xdr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
index c74d616..3850b01 100644
--- a/fs/nfs/nfs4xdr.c
+++ b/fs/nfs/nfs4xdr.c
@@ -1118,11 +1118,11 @@ static void encode_attrs(struct xdr_stream *xdr, const struct iattr *iap,
 len, ((char *)p - (char *)q) + 4);
 		BUG();
 	}
-	len = (char *)p - (char *)q - (bmval_len << 2);
 	*q++ = htonl(bmval0);
 	*q++ = htonl(bmval1);
 	if (bmval_len == 3)
 		*q++ = htonl(bmval2);
+	len = (char *)p - (char *)(q + 1);
 	*q = htonl(len);
 
 /* out: */
-- 
1.8.3.1

Re: Linux 3.11-rc2

[Steven Newbury]

On Mon, 2013-07-22 at 21:56 +0200, Rafael J. Wysocki wrote:
> On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
> > On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
> > 
> > > In the meantime I received a report from Steven Newbury that these changes
> > > broke things for him too, so we need to revert commits 8c5bd7a and 
> > > efaa14c.
> > > The other two commits in the series should be benign.
> > 
> > Could you let me know the details of this problem?
> 
> Steven, can you please describe the problem you're seeing to Matthew and
> the other people on the list?
> 
> Rafael
> 

Before the changes backlight was working fine using the ACPI method: 
/sys/class/backlight/acpi_video0/ is present and the keyboard function keys
control brightness with notifications working in GNOME.

In the code as was present in the linux-pm/bleeding-edge tree I would
encounter a hard lockup on keyboard brightness trigger.  This also occurred with
the code as it initially hit mainline, but a later commit fixed the crash*, but
resulted in no backlight controls being available at all.
/sys/class/backlight  is empty.

*not actually sure if /sys/class/backlight contained anything before this


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Myklebust, Trond]

On Tue, 2013-07-23 at 03:04 +0200, rydb...@euromail.se wrote:
> Hi Trond, Linus,
> 
> On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote:
> > So it's been another week, and -rc2 is out there.
> 
> This one happens to break nfs in a rather blunt-instrument fashion -
> creating files on a nfs4 partition [1] no longer works. Bisection
> yields this commit as the culprit:
> 
> commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd
> Author: Trond Myklebust 
> Date:   Wed Jul 17 16:43:16 2013 -0400
> 
> NFSv4: Fix a regression against the FreeBSD server
> 
> Technically, the Linux client is allowed by the NFSv4 spec to send
> 3 word bitmaps as part of an OPEN request. However, this causes the
> current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors.
> 
> Fix the regression by making the Linux client use a 2 word bitmap unless
> doing NFSv4.2 with labeled NFS.
> 
> Signed-off-by: Trond Myklebust 
> 
> Reverting the patch returns things to normal.

- Can you please provide me with a binary tcpdump or wireshark dump that
demonstrates the problem?

- What server is this?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.com
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: Linux 3.11-rc2

[rydberg]

Hi Trond, Linus,

On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote:
> So it's been another week, and -rc2 is out there.

This one happens to break nfs in a rather blunt-instrument fashion -
creating files on a nfs4 partition [1] no longer works. Bisection
yields this commit as the culprit:

commit b4a2cf76ab7c08628c62b2062dacefa496b59dfd
Author: Trond Myklebust 
Date:   Wed Jul 17 16:43:16 2013 -0400

NFSv4: Fix a regression against the FreeBSD server

Technically, the Linux client is allowed by the NFSv4 spec to send
3 word bitmaps as part of an OPEN request. However, this causes the
current FreeBSD server to return NFS4ERR_ATTRNOTSUPP errors.

Fix the regression by making the Linux client use a 2 word bitmap unless
doing NFSv4.2 with labeled NFS.

Signed-off-by: Trond Myklebust 

Reverting the patch returns things to normal.

Thanks,
Henrik

[1] type nfs4 
(rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.10,local_lock=none,addr=192.168.0.142)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Monday, July 22, 2013 08:46:47 PM Martin Steigerwald wrote:
> Am Montag, 22. Juli 2013, 15:37:42 schrieb Rafael J. Wysocki:
> > On Monday, July 22, 2013 03:15:38 PM Martin Steigerwald wrote:
> > > Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki:
> > > > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
> > > > > On 21 July 2013 20:53, Linus Torvalds 
> > > 
> > > wrote:
> > > > > >  (b) we had a late change to how ACPI backlight handling is done on
> > > > > > 
> > > > > > certain machines, and while this kind of thing really shouldn't be
> > > > > > done outside the merge window, I ended up pulling it anyway. But I'd
> > > > > > *really* like to have people test this thing particularly on laptops
> > > > > > with intel-based graphics. It should only matter (and hopefully
> > > > > > improve things) for the newer ones with BIOSes designed for Windows
> > > > > > 8,
> > > > > > but hey, the more testing, the better. Backlight handling has beenin
> > > > > > painful before, so I'm mentioning this explicitly.
> > > > > 
> > > > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
> > > > > Windows 8" breaks backlight control for me because
> > > > > /sys/class/backlight/acpi_video0 disappears, and
> > > > > /sys/class/backlight/intel_backlight doesn't seem to have any effect.
> > > > > 
> > > > > Note that acpi_video0 only worked because I was applying "[PATCH]
> > > > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
> > > > > strictly speaking mainline already didn't work.
> > > > 
> > > > James, sorry for breaking things for you.  The patch you're mentioning
> > > > is
> > > > going to hit the mainline at one point anyway I suppose.
> > > 
> > > Dunno whether thats related, but after locking screen today and screen
> > > blanker kicking in (just a blank screen), I was not able to reactivate
> > > the display again by typing a key or so unless I closed the laptop
> > > display lid, let the machine suspend (to ram) and opened it again.
> > 
> > > Plain 3.11-rc2 on ThinkPad T520:
> > Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and
> > see if that helps.
> 
> Okay. Done that. It does help.

OK, thanks!

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
> On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
> >
> > Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c?
> 
> Yes, but let's wait a while. Not because I think we'll fix the problem
> (hey, miracles might happen), but because I think it would be useful
> to couple the reverts with information about the particular machines
> that broke (and the people who reported it). So that when we
> inevitably try again, we can perhaps get some testing effort with
> those machines/people.
> 
> It doesn't seem to be a show-stopped for a large number of people, so
> there's no huge hurry. I'd suggest doing the revert just in time for
> rc3, but waiting until then to gather info about people who see
> breakage.
> 
> Sound like a plan?

Yes, it does.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Monday, July 22, 2013 06:16:20 PM Matthew Garrett wrote:
> On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:
> 
> > In the meantime I received a report from Steven Newbury that these changes
> > broke things for him too, so we need to revert commits 8c5bd7a and efaa14c.
> > The other two commits in the series should be benign.
> 
> Could you let me know the details of this problem?

Steven, can you please describe the problem you're seeing to Matthew and
the other people on the list?

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Martin Steigerwald]

Am Montag, 22. Juli 2013, 15:37:42 schrieb Rafael J. Wysocki:
> On Monday, July 22, 2013 03:15:38 PM Martin Steigerwald wrote:
> > Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki:
> > > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
> > > > On 21 July 2013 20:53, Linus Torvalds 
> > 
> > wrote:
> > > > >  (b) we had a late change to how ACPI backlight handling is done on
> > > > > 
> > > > > certain machines, and while this kind of thing really shouldn't be
> > > > > done outside the merge window, I ended up pulling it anyway. But I'd
> > > > > *really* like to have people test this thing particularly on laptops
> > > > > with intel-based graphics. It should only matter (and hopefully
> > > > > improve things) for the newer ones with BIOSes designed for Windows
> > > > > 8,
> > > > > but hey, the more testing, the better. Backlight handling has beenin
> > > > > painful before, so I'm mentioning this explicitly.
> > > > 
> > > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
> > > > Windows 8" breaks backlight control for me because
> > > > /sys/class/backlight/acpi_video0 disappears, and
> > > > /sys/class/backlight/intel_backlight doesn't seem to have any effect.
> > > > 
> > > > Note that acpi_video0 only worked because I was applying "[PATCH]
> > > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
> > > > strictly speaking mainline already didn't work.
> > > 
> > > James, sorry for breaking things for you.  The patch you're mentioning
> > > is
> > > going to hit the mainline at one point anyway I suppose.
> > 
> > Dunno whether thats related, but after locking screen today and screen
> > blanker kicking in (just a blank screen), I was not able to reactivate
> > the display again by typing a key or so unless I closed the laptop
> > display lid, let the machine suspend (to ram) and opened it again.
> 
> > Plain 3.11-rc2 on ThinkPad T520:
> Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and
> see if that helps.

Okay. Done that. It does help.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Matthew Garrett]

On Mon, 2013-07-22 at 15:02 +0200, Rafael J. Wysocki wrote:

> In the meantime I received a report from Steven Newbury that these changes
> broke things for him too, so we need to revert commits 8c5bd7a and efaa14c.
> The other two commits in the series should be benign.

Could you let me know the details of this problem?
-- 
Matthew Garrett | mj...@srcf.ucam.org
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: Linux 3.11-rc2

[Linus Torvalds]

On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki  wrote:
>
> Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c?

Yes, but let's wait a while. Not because I think we'll fix the problem
(hey, miracles might happen), but because I think it would be useful
to couple the reverts with information about the particular machines
that broke (and the people who reported it). So that when we
inevitably try again, we can perhaps get some testing effort with
those machines/people.

It doesn't seem to be a show-stopped for a large number of people, so
there's no huge hurry. I'd suggest doing the revert just in time for
rc3, but waiting until then to gather info about people who see
breakage.

Sound like a plan?

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Tobias Klausmann]

On 22.07.2013 15:08, Rafael J. Wysocki wrote:

On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote:

On 21.07.2013 21:53, Linus Torvalds wrote:

So it's been another week, and -rc2 is out there.

...

   (b) we had a late change to how ACPI backlight handling is done on
certain machines, and while this kind of thing really shouldn't be
done outside the merge window, I ended up pulling it anyway. But I'd
*really* like to have people test this thing particularly on laptops
with intel-based graphics. It should only matter (and hopefully
improve things) for the newer ones with BIOSes designed for Windows 8,
but hey, the more testing, the better. Backlight handling has been
painful before, so I'm mentioning this explicitly.


This pach finally fixes my backlight control!

Yes, it fixes that for a number of people, which is the reason why I send
the pull request in the first place, but it also turns out to break things
for some people and therefore it'll have to be reverted.

We're still going to work on that, though.

Thanks,
Rafael


If you have new patches ready for this and you want them to be tested, 
let me know!


Thanks,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Monday, July 22, 2013 03:15:38 PM Martin Steigerwald wrote:
> Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki:
> > On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
> > > On 21 July 2013 20:53, Linus Torvalds  
> wrote:
> > > >  (b) we had a late change to how ACPI backlight handling is done on
> > > > 
> > > > certain machines, and while this kind of thing really shouldn't be
> > > > done outside the merge window, I ended up pulling it anyway. But I'd
> > > > *really* like to have people test this thing particularly on laptops
> > > > with intel-based graphics. It should only matter (and hopefully
> > > > improve things) for the newer ones with BIOSes designed for Windows 8,
> > > > but hey, the more testing, the better. Backlight handling has beenin
> > > > painful before, so I'm mentioning this explicitly.
> > > 
> > > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
> > > Windows 8" breaks backlight control for me because
> > > /sys/class/backlight/acpi_video0 disappears, and
> > > /sys/class/backlight/intel_backlight doesn't seem to have any effect.
> > > 
> > > Note that acpi_video0 only worked because I was applying "[PATCH]
> > > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
> > > strictly speaking mainline already didn't work.
> > 
> > James, sorry for breaking things for you.  The patch you're mentioning is
> > going to hit the mainline at one point anyway I suppose.
> 
> Dunno whether thats related, but after locking screen today and screen 
> blanker 
> kicking in (just a blank screen), I was not able to reactivate the display 
> again by typing a key or so unless I closed the laptop display lid, let the 
> machine suspend (to ram) and opened it again.
> 
> Plain 3.11-rc2 on ThinkPad T520:

Well, please try to revert commits efaa14c and 8c5bd7a (in this order) and see
if that helps.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[James Hogan]

On 22 July 2013 14:02, Rafael J. Wysocki  wrote:
> On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
>> On 21 July 2013 20:53, Linus Torvalds  wrote:
>> >  (b) we had a late change to how ACPI backlight handling is done on
>> > certain machines, and while this kind of thing really shouldn't be
>> > done outside the merge window, I ended up pulling it anyway. But I'd
>> > *really* like to have people test this thing particularly on laptops
>> > with intel-based graphics. It should only matter (and hopefully
>> > improve things) for the newer ones with BIOSes designed for Windows 8,
>> > but hey, the more testing, the better. Backlight handling has beenin
>> > painful before, so I'm mentioning this explicitly.
>>
>> 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
>> Windows 8" breaks backlight control for me because
>> /sys/class/backlight/acpi_video0 disappears, and
>> /sys/class/backlight/intel_backlight doesn't seem to have any effect.
>>
>> Note that acpi_video0 only worked because I was applying "[PATCH]
>> drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
>> strictly speaking mainline already didn't work.
>
> James, sorry for breaking things for you.  The patch you're mentioning is 
> going
> to hit the mainline at one point anyway I suppose.
>
> In the meantime I received a report from Steven Newbury that these changes
> broke things for him too, so we need to revert commits 8c5bd7a and efaa14c.
> The other two commits in the series should be benign.

Feel free to Cc me on updated versions of the patches if you'd like me to test.

Cheers
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Martin Steigerwald]

Am Montag, 22. Juli 2013, 15:02:22 schrieb Rafael J. Wysocki:
> On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
> > On 21 July 2013 20:53, Linus Torvalds  
wrote:
> > >  (b) we had a late change to how ACPI backlight handling is done on
> > > 
> > > certain machines, and while this kind of thing really shouldn't be
> > > done outside the merge window, I ended up pulling it anyway. But I'd
> > > *really* like to have people test this thing particularly on laptops
> > > with intel-based graphics. It should only matter (and hopefully
> > > improve things) for the newer ones with BIOSes designed for Windows 8,
> > > but hey, the more testing, the better. Backlight handling has beenin
> > > painful before, so I'm mentioning this explicitly.
> > 
> > 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
> > Windows 8" breaks backlight control for me because
> > /sys/class/backlight/acpi_video0 disappears, and
> > /sys/class/backlight/intel_backlight doesn't seem to have any effect.
> > 
> > Note that acpi_video0 only worked because I was applying "[PATCH]
> > drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
> > strictly speaking mainline already didn't work.
> 
> James, sorry for breaking things for you.  The patch you're mentioning is
> going to hit the mainline at one point anyway I suppose.

Dunno whether thats related, but after locking screen today and screen blanker 
kicking in (just a blank screen), I was not able to reactivate the display 
again by typing a key or so unless I closed the laptop display lid, let the 
machine suspend (to ram) and opened it again.

Plain 3.11-rc2 on ThinkPad T520:

martin@merkaba:~> phoronix-test-suite system-info

Phoronix Test Suite v4.6.0
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 8192MB, Disk: 
300GB INTEL SSDSA2CW30 + 30GB INTEL SSDMCEAC03, Graphics: Intel 2nd Generation 
Core Family IGP, Audio: Conexant CX20590, Network: Intel 82579LM Gigabit 
Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 3.11.0-rc2-tp520 (x86_64), Desktop: KDE 4.10.5, 
Display Server: X Server 1.12.4, Display Driver: intel 2.20.14, OpenGL: 3.0 
Mesa 9.1.4, Compiler: GCC 4.8, File-System: btrfs, Screen Resolution: 
1920x1080

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Sunday, July 21, 2013 11:07:03 PM Tobias Klausmann wrote:
> On 21.07.2013 21:53, Linus Torvalds wrote:
> > So it's been another week, and -rc2 is out there.
> ...
> >
> >   (b) we had a late change to how ACPI backlight handling is done on
> > certain machines, and while this kind of thing really shouldn't be
> > done outside the merge window, I ended up pulling it anyway. But I'd
> > *really* like to have people test this thing particularly on laptops
> > with intel-based graphics. It should only matter (and hopefully
> > improve things) for the newer ones with BIOSes designed for Windows 8,
> > but hey, the more testing, the better. Backlight handling has been
> > painful before, so I'm mentioning this explicitly.
> >
> 
> This pach finally fixes my backlight control!

Yes, it fixes that for a number of people, which is the reason why I send
the pull request in the first place, but it also turns out to break things
for some people and therefore it'll have to be reverted.

We're still going to work on that, though.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Rafael J. Wysocki]

On Monday, July 22, 2013 12:08:40 AM James Hogan wrote:
> On 21 July 2013 20:53, Linus Torvalds  wrote:
> >  (b) we had a late change to how ACPI backlight handling is done on
> > certain machines, and while this kind of thing really shouldn't be
> > done outside the merge window, I ended up pulling it anyway. But I'd
> > *really* like to have people test this thing particularly on laptops
> > with intel-based graphics. It should only matter (and hopefully
> > improve things) for the newer ones with BIOSes designed for Windows 8,
> > but hey, the more testing, the better. Backlight handling has beenin
> > painful before, so I'm mentioning this explicitly.
> 
> 8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
> Windows 8" breaks backlight control for me because
> /sys/class/backlight/acpi_video0 disappears, and
> /sys/class/backlight/intel_backlight doesn't seem to have any effect.
> 
> Note that acpi_video0 only worked because I was applying "[PATCH]
> drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
> strictly speaking mainline already didn't work.

James, sorry for breaking things for you.  The patch you're mentioning is going
to hit the mainline at one point anyway I suppose.

In the meantime I received a report from Steven Newbury that these changes
broke things for him too, so we need to revert commits 8c5bd7a and efaa14c.
The other two commits in the series should be benign.

Linus, do you want me to send a pull request reverting 8c5bd7a and efaa14c?

Rafael (who's having a particularly bad day today)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Al Viro]

On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote:

> I'll just point out that it can make the whole thing worse, too.
> For example, for ext3/4, the tmpfile being created has to be added
> to the orphan inode list which is protected by a filesystem global
> mutex. Hence scalability of O_TMPFILE is massively limited on
> ext3/ext4 due to architectural issues within ext3/4. Other
> filesystems will be more efficient, but because they have more
> scalable/complex orphan inode handling it's going to take longer to
> implement O_TMPFILE support for them

Um...  You do realize that the same architectural issues there will
create exactly the same serialization when you are unlinking the
sucker?  I.e. with the "pick the name, create and open, unlink" sequence
ext[34] will insert that inode into the same orphan list, creating
the same contention...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Dave Chinner]

On Sun, Jul 21, 2013 at 12:53:10PM -0700, Linus Torvalds wrote:
> So it's been another week, and -rc2 is out there.
> 
> The patch looks a bit odd, because by bulk 95% of the patch is just
> the removal of the CSR staging driver that wasn't getting any
> traction, so the diffstat (and the dirstat in particular) is not very
> interesting or readable, since that driver removal basically
> overshadows everything else. But I do admit to love seeing code
> removal patches.
> 
> And of the rest of the patch, a noticeable part is all those
> one-liners all over that just remove the __cpuinit markers that people
> agreed were just more pain than gain to maintain. We had already made
> the markers be no-ops earlier, so they didn't matter for code
> generation, and here in rc2 they get actually removed.
> 
> End result: we have two separate events that generate a lot of noise
> in the patch, but aren't really interesting per se. They do make the
> patch harder to read, though.
> 
> Ignoring those noisy parts of the patch, there's a couple of things
> worth noting about rc2. I think most of the patches here are nice
> fixes, but I wanted to give two heads-ups:
> 
>  (a) the O_TMPFILE flag that is new to 3.11 has been going through a
> few ABI/API cleanups (and a few fixes to the implementation too), but
> I think we're done now. So if you're interested in the concept of
> unnamed temporary files, go ahead and test it out. The lack of name
> not only gets rid of races/complications with filename generation, it
> can make the whole thing more efficient since you don't have the
> directory operations that can cause serializing IO etc.

I'll just point out that it can make the whole thing worse, too.
For example, for ext3/4, the tmpfile being created has to be added
to the orphan inode list which is protected by a filesystem global
mutex. Hence scalability of O_TMPFILE is massively limited on
ext3/ext4 due to architectural issues within ext3/4. Other
filesystems will be more efficient, but because they have more
scalable/complex orphan inode handling it's going to take longer to
implement O_TMPFILE support for them

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[James Hogan]

On 21 July 2013 20:53, Linus Torvalds  wrote:
>  (b) we had a late change to how ACPI backlight handling is done on
> certain machines, and while this kind of thing really shouldn't be
> done outside the merge window, I ended up pulling it anyway. But I'd
> *really* like to have people test this thing particularly on laptops
> with intel-based graphics. It should only matter (and hopefully
> improve things) for the newer ones with BIOSes designed for Windows 8,
> but hey, the more testing, the better. Backlight handling has beenin
> painful before, so I'm mentioning this explicitly.

8c5bd7a "ACPI / video / i915: No ACPI backlight if firmware expects
Windows 8" breaks backlight control for me because
/sys/class/backlight/acpi_video0 disappears, and
/sys/class/backlight/intel_backlight doesn't seem to have any effect.

Note that acpi_video0 only worked because I was applying "[PATCH]
drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight" [1], so
strictly speaking mainline already didn't work.

Cheers
James

[1] http://lkml.org/lkml/2013/7/19/748
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.11-rc2

[Tobias Klausmann]

On 21.07.2013 21:53, Linus Torvalds wrote:

So it's been another week, and -rc2 is out there.

...


  (b) we had a late change to how ACPI backlight handling is done on
certain machines, and while this kind of thing really shouldn't be
done outside the merge window, I ended up pulling it anyway. But I'd
*really* like to have people test this thing particularly on laptops
with intel-based graphics. It should only matter (and hopefully
improve things) for the newer ones with BIOSes designed for Windows 8,
but hey, the more testing, the better. Backlight handling has been
painful before, so I'm mentioning this explicitly.



This pach finally fixes my backlight control!

Thanks!
Tobias Klausmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 3.11-rc2

[Linus Torvalds]

m/i915: reinit status page registers after gpu reset
  drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a

Dave Jones (1):
  linked-list: Remove __list_for_each

David Jeffery (1):
  lockd: protect nlm_blocked access in nlmsvc_retry_blocked

David S. Miller (1):
  net: Fix sysfs_format_mac() code duplication.

Dragos Foianu (2):
  ethtool: fixed trailing statements in ethtool
  net/irda: fixed style issues in irlan_eth

Eric Dumazet (3):
  ipv4: set transport header earlier
  vlan: mask vlan prio bits
  vlan: fix a race in egress prio management

Fabio Estevam (2):
  ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL
  ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK

Faidon Liambotis (1):
  MIPS: Octeon: Fix DT pruning bug with pip ports

Florian Fainelli (1):
  MIPS: BMIPS: Fix thinko to release slave TP from reset

Ganesan Ramalingam (1):
  MIPS: Netlogic: Fix USB block's coherent DMA mask

Girish K S (1):
  spi: s3c64xx: add missing check for polling mode

Greg Kroah-Hartman (7):
  sysfs.h: add __ATTR_RW() macro
  sysfs.h: add ATTRIBUTE_GROUPS() macro
  sysfs.h: add BIN_ATTR macro
  driver core: device.h: add RW and RO attribute macros
  sysfs: add support for binary attributes in groups
  driver core: add default groups to struct class
  staging: csr: remove driver

Guenter Roeck (2):
  Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
  driver core: Introduce device_create_groups

H. Peter Anvin (1):
  x86, suspend: Handle CPUs which fail to #GP on RDMSR

Haiyang Zhang (1):
  hyperv: Fix the NETIF_F_SG flag setting in netvsc

Hauke Mehrtens (1):
  bgmac: add dependency to phylib

Heiko Carstens (4):
  s390/bpf,jit: call module_free() from any context
  s390/bpf,jit: use generic jit dumper
  s390/bpf,jit: address randomize and write protect jit code
  s390/bpf,jit: add pkt_type support

Imre Deak (1):
  drm/i915: fix lane bandwidth capping for DP 1.2 sinks

Ingo Tuchscherer (1):
  s390/zcrypt: Alias for new zcrypt device driver base module

J. Bruce Fields (1):
  nfsd4: fix minorversion support interface

Jacek Anaszewski (1):
  iio: lps331ap: Fix wrong in_pressure_scale output value

James Hogan (1):
  MIPS: KVM: Mark KVM_GUEST (T&E KVM) as BROKEN_ON_SMP

Jan Beulich (1):
  xen-netfront: pull on receive skb may need to happen earlier

Jan Kara (2):
  ext4: silence warning in ext4_writepages()
  ext4: fix warning in ext4_evict_inode()

Jason Wang (4):
  macvtap: fix the missing ret value of TUNSETQUEUE
  macvtap: do not assume 802.1Q when send vlan packets
  tuntap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS
  macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS

Jayachandran C (1):
  MIPS: Netlogic: Add XLP PIC irqdomain

Jerome Glisse (1):
  drm/radeon: use radeon device for request firmware

Jonathan Cameron (1):
  iio:trigger: device_unregister->device_del to avoid double free

Josef Bacik (3):
  Btrfs: update drop progress before stopping snapshot dropping
  Btrfs: fix lock leak when resuming snapshot deletion
  Btrfs: re-add root to dead root list if we stop dropping it

Kees Cook (1):
  x86: Make sure IDT is page aligned

Kuninori Morimoto (1):
  ASoC: wm8978: enable symmetric rates

Lan Tianyu (1):
  ACPI / video: ignore BIOS initial backlight value for Fujitsu E753

Laurent Pinchart (2):
  drm/shmobile: Use the GEM PRIME helpers
  drm/rcar-du: Use the GEM PRIME helpers

Linus Torvalds (1):
  Linux 3.11-rc2

Liu ShuoX (2):
  PM / Sleep: avoid 'autosleep' in shutdown progress
  PNP / ACPI: avoid garbage in resource name

Maarten Lankhorst (1):
  drm/radeon: add missing ttm_eu_backoff_reservation to
radeon_bo_list_validate

Marc Zyngier (1):
  arm64: use common reboot infrastructure

Marek Vasut (2):
  iio: mxs-lradc: Fix misuse of iio->trig
  iio: mxs-lradc: Remove useless check in read_raw

Mark Brown (1):
  ASoC: wm8994: Remove overly noisy debug logging

Markos Chandras (1):
  MIPS: kvm: Kconfig: Drop HAVE_KVM dependency from VIRTUALIZATION

Matt Fleming (2):
  efivars: check for EFI_RUNTIME_SERVICES
  Revert "UEFI: Don't pass boot services regions to SetVirtualAddressMap()"

Matthew Garrett (1):
  ACPI / video: Always call acpi_video_init_brightness() on init

Michael Holzheu (2):
  s390/kdump: Disable mmap for s390
  s390/kdump: Allow copy_oldmem_page() copy to virtual memory

Michael Mueller (1):
  s390/ptrace: PTRACE_TE_ABORT_RAND

Michal Simek (1):
  spi/xilinx: Revert master->setup function removal

Neil Horman (1):
  atl1e: unmap partially mapped skb on dma error and free skb

NeilBrown (3):
  md/raid10: fix two problems with RAID10 resync.
  md: Remove recent change which allows devic