From: Hans de Goede <hidden> Date: 2014-05-21 14:17:41
Hi All,
I know it has not been that long since the last send of this series, but
it has been very quiet, and I would like to see some discussion on it
(or it being applied at once, that is fine too :)
This patch-set adds backlight device (un)registration notification and
makes acpi-video listen to it, so that video.use_native_backlight=1 still
works if a raw interface gets loaded *after* acpi-video has been initialized.
It also changes nouveau to always register its raw interface, as all the other
kms drivers do, acpi_video_backlight_support() is only intended to avoid the
loading of multiple (possibly conflicting) firmware drivers, not to avoid
loading raw drivers.
In the mean time I've gotten feedback from a user with a laptop which needs
video.use_native_backlight=1 and uses nouveau, and he has confirmed that this
patch-set works as advertised, see:
https://bugzilla.redhat.com/show_bug.cgi?id93171
Regards,
Hans
From: Hans de Goede <hidden> Date: 2014-05-21 13:40:52
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
---
drivers/video/backlight/backlight.c | 40 +++++++++++++++++++++++++++++++++++++
include/linux/backlight.h | 7 +++++++
2 files changed, 47 insertions(+)
From: Hans de Goede <hidden> Date: 2014-05-21 13:40:54
When video.use_native_backlight=1 and non intel gfx are in use, the raw
backlight device of the gfx driver will show up after acpi-video has done its
acpi_video_verify_backlight_support() check.
This causes video.use_native_backlight=1 to not have the desired result.
This patch fixes this by adding a backlight notifier and when a raw
backlight is registered or unregistered re-doing the
acpi_video_verify_backlight_support() check.
Signed-off-by: Hans de Goede <redacted>
---
drivers/acpi/video.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
From: Hans de Goede <hidden> Date: 2014-05-21 14:16:35
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).
This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.
This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.
This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799
Also see: https://bugzilla.redhat.com/show_bug.cgi?id93171
Signed-off-by: Hans de Goede <redacted>
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 ---------
1 file changed, 9 deletions(-)
From: Hans de Goede <hidden> Date: 2014-05-21 14:21:24
Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video
backlight control. Note in order for this to actually fix things on the
ThinkPad W530 the commit titled:
"nouveau: Don't check acpi_video_backlight_support() before registering backlight"
is also needed.
https://bugzilla.redhat.com/show_bug.cgi?id93171
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <redacted>
---
drivers/acpi/video.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Rafael J. Wysocki <hidden> Date: 2014-05-21 23:13:15
On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).
This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.
This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.
This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799
Also see: https://bugzilla.redhat.com/show_bug.cgi?id93171
Signed-off-by: Hans de Goede <redacted>
It would be good to have an ACK from the nouveau people for this one.
From: Rafael J. Wysocki <hidden> Date: 2014-05-21 23:14:14
On Wednesday, May 21, 2014 03:39:54 PM Hans de Goede wrote:
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
From: Hans de Goede <hidden> Date: 2014-05-22 08:42:05
Hi,
On 05/22/2014 01:30 AM, Rafael J. Wysocki wrote:
On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
quoted
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).
This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.
This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.
This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799
Also see: https://bugzilla.redhat.com/show_bug.cgi?id93171
Signed-off-by: Hans de Goede <redacted>
It would be good to have an ACK from the nouveau people for this one.
Right, it could / should even go in through the drm tree I guess.
Regards,
Hans
From: Hans de Goede <hidden> Date: 2014-05-22 08:45:11
Hi,
On 05/22/2014 01:31 AM, Rafael J. Wysocki wrote:
On Wednesday, May 21, 2014 03:39:54 PM Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
Thanks & Regardsm
Hans
From: Lee Jones <hidden> Date: 2014-05-22 09:02:22
quoted
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
From: Ben Skeggs <hidden> Date: 2014-05-23 04:13:48
On Thu, May 22, 2014 at 9:30 AM, Rafael J. Wysocki [off-list ref] wrote:
On Wednesday, May 21, 2014 03:39:53 PM Hans de Goede wrote:
quoted
acpi_video_backlight_support() is supposed to be called by other (vendor
specific) firmware backlight controls, not by native / raw backlight controls
like nv_backlight.
Userspace will normally prefer firmware interfaces over raw interfaces, so
if acpi_video backlight support is present it will use that even if
nv_backlight is registered as well.
Except when video.use_native_backlight is present on the kernel cmdline
(or enabled through a dmi based quirk). As the name indicates the goal here
is to make only the raw interface available to userspace so that it will use
that (it only does this when it sees a win8 compliant bios).
This is done by:
1) Not registering any acpi_video# backlight devices; and
2) Making acpi_video_backlight_support() return true so that other firmware
drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their
own vender specific interfaces.
Currently nouveau breaks this setup, as when acpi_video_backlight_support()
returns true, it does not register itself, resulting in no backlight control
at all.
This is esp. going to be a problem with 3.16 which will default to
video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios
will get no backlight control at all.
This also likely explains why the previous attempt to make
video.use_native_backlight=1 the default was not a success, as without this
patch having a default of video.use_native_backlight=1 will cause regressions.
Note this effectively reverts commit 5bead799
Also see: https://bugzilla.redhat.com/show_bug.cgi?id93171
Signed-off-by: Hans de Goede <redacted>
It would be good to have an ACK from the nouveau people for this one.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Jingoo Han <hidden> Date: 2014-05-26 03:03:43
On Thursday, May 22, 2014 6:02 PM, Lee Jones wrote:
On Thursday, May 22, 2014 5:45 PM, Hans de Goede wrote:
quoted
On Thursday, May 22, 2014 8:31 AM, Rafael J. Wysocki wrote:
quoted
On Wednesday, May 21, 2014 10:40 PM, Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
Acked-by: Jingoo Han <redacted>
Lee Jones,
Would you merge this patch into your backlight git tree?
Thank you.
Best regards,
Jingoo Han
From: Rafael J. Wysocki <hidden> Date: 2014-05-26 10:46:25
On Monday, May 26, 2014 12:03:43 PM Jingoo Han wrote:
On Thursday, May 22, 2014 6:02 PM, Lee Jones wrote:
quoted
On Thursday, May 22, 2014 5:45 PM, Hans de Goede wrote:
quoted
On Thursday, May 22, 2014 8:31 AM, Rafael J. Wysocki wrote:
quoted
On Wednesday, May 21, 2014 10:40 PM, Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
Acked-by: Jingoo Han <redacted>
Lee Jones,
Would you merge this patch into your backlight git tree?
Hans, does this series depend on things that I've applied already? If so,
I'd very much prefer to take this series too as a whole.
Rafael
From: Hans de Goede <hidden> Date: 2014-05-26 11:21:28
Hi,
On 05/26/2014 01:03 PM, Rafael J. Wysocki wrote:
On Monday, May 26, 2014 12:03:43 PM Jingoo Han wrote:
quoted
On Thursday, May 22, 2014 6:02 PM, Lee Jones wrote:
quoted
On Thursday, May 22, 2014 5:45 PM, Hans de Goede wrote:
quoted
On Thursday, May 22, 2014 8:31 AM, Rafael J. Wysocki wrote:
quoted
On Wednesday, May 21, 2014 10:40 PM, Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
Acked-by: Jingoo Han <redacted>
Lee Jones,
Would you merge this patch into your backlight git tree?
Hans, does this series depend on things that I've applied already? If so,
I'd very much prefer to take this series too as a whole.
The 3th patch in this series:
" acpi-video: Unregister the backlight device if a raw one shows up later"
depends on my "acpi-video: Add an acpi_video_unregister_backlight function"
patch, which you've applied to your linux-next branch already.
As well as on the 2nd patch in this series:
"backlight: Add backlight device (un)registration notification"
So I agree that it is a good idea to take the whole series through your tree.
Thanks & Regards,
Hans
From: Lee Jones <hidden> Date: 2014-05-27 09:20:59
On 05/26/2014 01:03 PM, Rafael J. Wysocki wrote:
quoted
On Monday, May 26, 2014 12:03:43 PM Jingoo Han wrote:
quoted
On Thursday, May 22, 2014 6:02 PM, Lee Jones wrote:
quoted
On Thursday, May 22, 2014 5:45 PM, Hans de Goede wrote:
quoted
On Thursday, May 22, 2014 8:31 AM, Rafael J. Wysocki wrote:
quoted
On Wednesday, May 21, 2014 10:40 PM, Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
Acked-by: Jingoo Han <redacted>
Lee Jones,
Would you merge this patch into your backlight git tree?
Hans, does this series depend on things that I've applied already? If so,
I'd very much prefer to take this series too as a whole.
The 3th patch in this series:
" acpi-video: Unregister the backlight device if a raw one shows up later"
depends on my "acpi-video: Add an acpi_video_unregister_backlight function"
patch, which you've applied to your linux-next branch already.
As well as on the 2nd patch in this series:
"backlight: Add backlight device (un)registration notification"
So I agree that it is a good idea to take the whole series through your tree.
I'm fine with that.
Rafael, could you apply the set onto an immutable branch and send me a
signed pull-request please?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
From: Rafael J. Wysocki <hidden> Date: 2014-05-31 22:29:05
On Tuesday, May 27, 2014 10:20:33 AM Lee Jones wrote:
quoted
On 05/26/2014 01:03 PM, Rafael J. Wysocki wrote:
quoted
On Monday, May 26, 2014 12:03:43 PM Jingoo Han wrote:
quoted
On Thursday, May 22, 2014 6:02 PM, Lee Jones wrote:
quoted
On Thursday, May 22, 2014 5:45 PM, Hans de Goede wrote:
quoted
On Thursday, May 22, 2014 8:31 AM, Rafael J. Wysocki wrote:
quoted
On Wednesday, May 21, 2014 10:40 PM, Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
Acked-by: Jingoo Han <redacted>
Lee Jones,
Would you merge this patch into your backlight git tree?
Hans, does this series depend on things that I've applied already? If so,
I'd very much prefer to take this series too as a whole.
The 3th patch in this series:
" acpi-video: Unregister the backlight device if a raw one shows up later"
depends on my "acpi-video: Add an acpi_video_unregister_backlight function"
patch, which you've applied to your linux-next branch already.
As well as on the 2nd patch in this series:
"backlight: Add backlight device (un)registration notification"
So I agree that it is a good idea to take the whole series through your tree.
I'm fine with that.
Rafael, could you apply the set onto an immutable branch and send me a
signed pull-request please?
You can find this patch on the branch at
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-video
The top-most commit is 0dc6b96ac20c (ACPI / video: Add 4 new models to the
use_native_backlight DMI list).
Please feel free to pull from there if necessary, it is not going to be rebased.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
From: Lee Jones <hidden> Date: 2014-06-02 07:33:33
On Sun, 01 Jun 2014, Rafael J. Wysocki wrote:
On Tuesday, May 27, 2014 10:20:33 AM Lee Jones wrote:
quoted
quoted
On 05/26/2014 01:03 PM, Rafael J. Wysocki wrote:
quoted
On Monday, May 26, 2014 12:03:43 PM Jingoo Han wrote:
quoted
On Thursday, May 22, 2014 6:02 PM, Lee Jones wrote:
quoted
On Thursday, May 22, 2014 5:45 PM, Hans de Goede wrote:
quoted
On Thursday, May 22, 2014 8:31 AM, Rafael J. Wysocki wrote:
quoted
On Wednesday, May 21, 2014 10:40 PM, Hans de Goede wrote:
quoted
Some firmware drivers, ie acpi-video want to get themselves out of the
way (in some cases) when their also is a raw backlight device available.
Due to module loading ordering being unknown, acpi-video cannot be certain
that the backlight_device_registered(BACKLIGHT_RAW) it does for this is
the final verdict wrt there being a BACKLIGHT_RAW device.
By adding notification acpi-video can listen for backlight devices showing
up after it has loaded, and unregister its backlight device if desired.
Signed-off-by: Hans de Goede <redacted>
Backlight maintainer's ACK is requisite here.
Agreed, which is why I send this set to all 3 the backlight maintainers
directly on both postings.
What may be helpful for them is to hear from you if you're ok with the
acpi-video bits which are actually going to use this, since those will
be the only user of the new backlight api (for now).
I'm happy to apply any Backlight patches which have either Bryan or
Jingoo's Ack, as they are the reviewers for the BL subsystem.
Acked-by: Jingoo Han <redacted>
Lee Jones,
Would you merge this patch into your backlight git tree?
Hans, does this series depend on things that I've applied already? If so,
I'd very much prefer to take this series too as a whole.
The 3th patch in this series:
" acpi-video: Unregister the backlight device if a raw one shows up later"
depends on my "acpi-video: Add an acpi_video_unregister_backlight function"
patch, which you've applied to your linux-next branch already.
As well as on the 2nd patch in this series:
"backlight: Add backlight device (un)registration notification"
So I agree that it is a good idea to take the whole series through your tree.
I'm fine with that.
Rafael, could you apply the set onto an immutable branch and send me a
signed pull-request please?
You can find this patch on the branch at
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-video
The top-most commit is 0dc6b96ac20c (ACPI / video: Add 4 new models to the
use_native_backlight DMI list).
Please feel free to pull from there if necessary, it is not going to be rebased.
acpi-video contains 14 patches! If we share patches in the future,
the branches really need to contain as few patches as possible. I'm
happy to set-up a special 'mfd-pm' immutable branch for future
releases to save either one of use pulling in more patches into our
respective trees than is necessary.
Rather than pull all those patches in to the MFD tree, I'll simply run
the risk of a merge conflict this time.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog