similar to: [PATCH] Add in-kernel backlight control support

fixes d9c0aadc5aa241df26ce8301d34a8418919fb5ae Suggested-by: Ben Skeggs <skeggsb at redhat.com> Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_backlight.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c index 380f3402..55172655 100644 ---

On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau <pierre.morrow at free.fr> wrote: > Currently, every backlight interface created by Nouveau uses the same name, > nv_backlight. This leads to a sysfs warning as it tries to create an already > existing folder. This patch adds a incremented number to the name, but keeps > the initial name as nv_backlight, to avoid possibly breaking

Currently, every backlight interface created by Nouveau uses the same name, nv_backlight. This leads to a sysfs warning as it tries to create an already existing folder. This patch adds a incremented number to the name, but keeps the initial name as nv_backlight, to avoid possibly breaking userspace; the second interface will be named nv_backlight1, and so on. Bugzilla:

Currently, every backlight interface created by Nouveau uses the same name, nv_backlight. This leads to a sysfs warning as it tries to create an already existing folder. This patch adds a incremented number to the name, but keeps the initial name as nv_backlight, to avoid possibly breaking userspace; the second interface will be named nv_backlight1, and so on. Bugzilla:

On Sun, Nov 13, 2016 at 08:57:06PM +0100, Pierre Moreau wrote: > From: Pierre Moreau <pierre.morrow at free.fr> > > Currently, every backlight interface created by Nouveau uses the same name, > nv_backlight. This leads to a sysfs warning as it tries to create an already > existing folder. This patch adds a incremented number to the name, but keeps > the initial name as

On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote: > On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau <pierre.morrow at free.fr> wrote: > > Currently, every backlight interface created by Nouveau uses the same name, > > nv_backlight. This leads to a sysfs warning as it tries to create an already > > existing folder. This patch adds a incremented number to the name, but keeps

From: Pierre Moreau <pierre.morrow at free.fr> Currently, every backlight interface created by Nouveau uses the same name, nv_backlight. This leads to a sysfs warning as it tries to create an already existing folder. This patch adds a incremented number to the name, but keeps the initial name as nv_backlight, to avoid possibly breaking userspace; the second interface will be named

This adds basic support for driving sensor chips off the nvidia i2c buses, along with basic support for reading the internal GPU sensor on supported chipsets. It's heavily cribbed off nvclock. Having scanned a large number of bioses, I'm pretty convinced that the appropriate i2c bus is always number 2 in the list on <g80 - I'm not sure about later cards yet. There's still a lot

Currently, every backlight interface created by Nouveau uses the same name, nv_backlight. This leads to a sysfs warning as it tries to create an already existing folder. This patch adds a incremented number to the name, but keeps the initial name as nv_backlight, to avoid possibly breaking userspace; the second interface will be named nv_backlight1, and so on. Fixes: fdo#86539 Signed-off-by:

Next version of https://patchwork.freedesktop.org/series/48596/ . Made some important changes to the refactoring patch, but everything else is the same. Lyude Paul (5): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Move backlight device into nouveau_connector drm/nouveau: s/nouveau_backlight_exit/nouveau_backlight_fini/ drm/nouveau: Cleanup indenting in

Next version of https://patchwork.freedesktop.org/series/48596/ . Added NV_INFO_ONCE and made "Move backlight device into nouveau_connector" use that instead so we don't print the GMUX warning more then once. Lyude Paul (5): drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

Forgot to send 6 patches instead of five since there's one new one now, whoops! No actual changes, next version of https://patchwork.freedesktop.org/series/48596/ Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

Refactor for Ben, hopefully this time this should apply to his tree. Next version of https://patchwork.freedesktop.org/series/48596/ No changes otherwise. Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

This series fixes some issues with nouveau's backlight support that were causing kernel panics on module reloads, specifically on systems with nouveau handling the backlight of one of the displays. While we're at it, let's cleanup nouveau_backlight.c as well Lyude Paul (5): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Move backlight device into

Known issues before merge: - Currently requires acpi_backlight=vendor kernel param - 0x5e always valid? Signed-off-by: Roy Spliet <r.spliet at student.tudelft.nl> Tested-by: Rick Hendricksen --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 20 +++++++++++++++++--- drivers/gpu/drm/nouveau/nouveau_display.c | 4 ++++ drivers/gpu/drm/nouveau/nouveau_display.h | 7 +++++++ 3 files

On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: > Backlights controlled by i915.ko and only associated with its connectors > and also only associated with the intel_drmfb fbcon, controlled by > i915.ko. In this situation, we already handle adjusting the backlight > when the fbcon is blanked/unblanked and do not require backlight trying > to do the same. > >

On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote: > On Tue, 12 Jul 2016, Daniel Vetter <daniel at ffwll.ch> wrote: > > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: > >> Backlights controlled by i915.ko and only associated with its connectors > >> and also only associated with the intel_drmfb fbcon, controlled by > >> i915.ko. In

On Tue, 12 Jul 2016, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote: >> Backlights controlled by i915.ko and only associated with its connectors >> and also only associated with the intel_drmfb fbcon, controlled by >> i915.ko. In this situation, we already handle adjusting the backlight >> when the fbcon is

Backlights controlled by i915.ko and only associated with its connectors and also only associated with the intel_drmfb fbcon, controlled by i915.ko. In this situation, we already handle adjusting the backlight when the fbcon is blanked/unblanked and do not require backlight trying to do the same. Attempting to register with the fbdev as a client causes lockdep to warn about a dependency cycle: [

Forward declare struct backlight_device and remove the include statement. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Reviewed-by: Jani Nikula <jani.nikula at intel.com> --- include/linux/fb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index 2ce2f5c2fca9a..7380d959c5d53 100644 --- a/include/linux/fb.h +++