[PATCH] backlight: initialize struct backlight_properties properly
In all these files, the .power field was never correctly initialized.
Signed-off-by: Corentin Chary
---
drivers/gpu/drm/i915/intel_panel.c |1 +
drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
drivers/platform/x86/toshiba_acpi.c |1 +
drivers/video/backlight/da903x_bl.c |1 +
drivers/video/backlight/pcf50633-backlight.c|1 +
drivers/video/backlight/wm831x_bl.c |1 +
drivers/video/omap2/displays/panel-acx565akm.c |1 +
7 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 48177ec..ec4a1e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
else
return -ENODEV;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = intel_panel_get_max_backlight(dev);
dev_priv->backlight =
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 42db254..a0c8222 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder
*radeon_encoder,
goto error;
}
+ memset(&props, 0, sizeof(props));
props.max_brightness = MAX_RADEON_LEVEL;
props.type = BACKLIGHT_RAW;
bd = backlight_device_register("radeon_bl", &drm_connector->kdev,
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index bde32de..d680bb2 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1095,6 +1095,7 @@ static int __devinit toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
ret = get_tr_backlight_status(dev, &enabled);
dev->tr_backlight_supported = !ret;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 30e1968..573c7ec 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device
*pdev)
da903x_write(data->da903x_dev, DA9034_WLED_CONTROL2,
DA9034_WLED_ISET(pdata->output_current));
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = max_brightness;
bl = backlight_device_register(pdev->name, data->da903x_dev, data,
diff --git a/drivers/video/backlight/pcf50633-backlight.c
b/drivers/video/backlight/pcf50633-backlight.c
index c65853c..c092159 100644
--- a/drivers/video/backlight/pcf50633-backlight.c
+++ b/drivers/video/backlight/pcf50633-backlight.c
@@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct
platform_device *pdev)
if (!pcf_bl)
return -ENOMEM;
+ memset(&bl_props, 0, sizeof(bl_props));
bl_props.type = BACKLIGHT_RAW;
bl_props.max_brightness = 0x3f;
bl_props.power = FB_BLANK_UNBLANK;
diff --git a/drivers/video/backlight/wm831x_bl.c
b/drivers/video/backlight/wm831x_bl.c
index 5d365de..9e5517a 100644
--- a/drivers/video/backlight/wm831x_bl.c
+++ b/drivers/video/backlight/wm831x_bl.c
@@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device
*pdev)
data->current_brightness = 0;
data->isink_reg = isink_reg;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = max_isel;
bl = backlight_device_register("wm831x", &pdev->dev, data,
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index d26f37a..74e7cf0 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
/*--- Backlight control */
+ memset(&props, 0, sizeof(props));
props.fb_blank = FB_BLANK_UNBLANK;
props.power = FB_BLANK_UNBLANK;
props.type = BACKLIGHT_RAW;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/platform/x86: Backlight-Add-backlight-type-v2.patch
On Wed, Oct 27, 2010 at 1:06 PM, Sedat Dilek wrote: > Hi, > > while testing linux-next I wanted to reactivate the backlight type > patches laying in my build-dir. > > Within 2.6.36-rcX cycle I had successfully tested the backlight type > patch [1] with an additional patch for radeon by Michel (posted to > dri-devel ML, see [2]). > > The main patch needs a little refreshing. > > v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next > (next-20101027) > > > Kind Regards, > - Sedat - > > [1] https://patchwork.kernel.org/patch/163971/ > [2] https://patchwork.kernel.org/patch/182352/ > Hi, I think rfkill has the same problem, on some platforms, the platform driver will add a rfkill switch, but the network (wlan/wimax/whatever) driver may also add one. AFAIK, the platform one is more likely to be able to power down the device completly. For the current patch, a common pattern seems to be : video/ -> RAW, platform/ -> PLATFORM. Couldn't we make some guess by checking the parent of the backlight instead of doing this by hand for every drivers ? Thanks, -- Corentin Chary http://xf.iksaif.net ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features
On Fri, Mar 11, 2011 at 11:46 AM, Thomas Renninger wrote: > Why is there need for another tool? > --- > > CPU power consumption vs performance tuning is not about > CPU frequency switching anymore for quite some time. > Deep sleep states, traditional dynamic frequency scaling and > hidden turbo/boost frequencies are tight close together and > depend on each other. The first two exist on different architectures > like PPC, Itanium and ARM the latter only on X86. > On X86 the APU (CPU+GPU) will only run most efficiently if CPU > and GPU has proper power management in place. > > Users and Developers want to have *one* tool to get an overview what their > system supports and to monitor and debug CPU power management in detail. > > The tool should compile and work on as much architectures as > possible. > Hi Thomas, Do you think handling really vendor specific "boosts" like EeePC's SHE is in cpupower scope ? Still, it would not solve the issue of setting SHE mode in a standard way, or associating it with a governor. Thanks, -- Corentin Chary http://xf.iksaif.net ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drivers/platform/x86: Backlight-Add-backlight-type-v2.patch
On Wed, Oct 27, 2010 at 1:06 PM, Sedat Dilek wrote: > Hi, > > while testing linux-next I wanted to reactivate the backlight type > patches laying in my build-dir. > > Within 2.6.36-rcX cycle I had successfully tested the backlight type > patch [1] with an additional patch for radeon by Michel (posted to > dri-devel ML, see [2]). > > The main patch needs a little refreshing. > > v2: drivers/platform/x86/asus-laptop.c: Refreshed to fit linux-next > (next-20101027) > > > Kind Regards, > - Sedat - > > [1] https://patchwork.kernel.org/patch/163971/ > [2] https://patchwork.kernel.org/patch/182352/ > Hi, I think rfkill has the same problem, on some platforms, the platform driver will add a rfkill switch, but the network (wlan/wimax/whatever) driver may also add one. AFAIK, the platform one is more likely to be able to power down the device completly. For the current patch, a common pattern seems to be : video/ -> RAW, platform/ -> PLATFORM. Couldn't we make some guess by checking the parent of the backlight instead of doing this by hand for every drivers ? Thanks, -- Corentin Chary http://xf.iksaif.net
[ANNOUNCE] cpupowerutils - cpufrequtils extended with quite some features
On Fri, Mar 11, 2011 at 11:46 AM, Thomas Renninger wrote: > Why is there need for another tool? > --- > > CPU power consumption vs performance tuning is not about > CPU frequency switching anymore for quite some time. > Deep sleep states, traditional dynamic frequency scaling and > hidden turbo/boost frequencies are tight close together and > depend on each other. The first two exist on different architectures > like PPC, Itanium and ARM the latter only on X86. > On X86 the APU (CPU+GPU) will only run most efficiently if CPU > and GPU has proper power management in place. > > Users and Developers want to have *one* tool to get an overview what their > system supports and to monitor and debug CPU power management in detail. > > The tool should compile and work on as much architectures as > possible. > Hi Thomas, Do you think handling really vendor specific "boosts" like EeePC's SHE is in cpupower scope ? Still, it would not solve the issue of setting SHE mode in a standard way, or associating it with a governor. Thanks, -- Corentin Chary http://xf.iksaif.net
[PATCH] backlight: initialize struct backlight_properties properly
In all these files, the .power field was never correctly initialized.
Signed-off-by: Corentin Chary
---
drivers/gpu/drm/i915/intel_panel.c |1 +
drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 +
drivers/platform/x86/toshiba_acpi.c |1 +
drivers/video/backlight/da903x_bl.c |1 +
drivers/video/backlight/pcf50633-backlight.c|1 +
drivers/video/backlight/wm831x_bl.c |1 +
drivers/video/omap2/displays/panel-acx565akm.c |1 +
7 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 48177ec..ec4a1e0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -342,6 +342,7 @@ int intel_panel_setup_backlight(struct drm_device *dev)
else
return -ENODEV;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = intel_panel_get_max_backlight(dev);
dev_priv->backlight =
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 42db254..a0c8222 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -369,6 +369,7 @@ void radeon_legacy_backlight_init(struct radeon_encoder
*radeon_encoder,
goto error;
}
+ memset(&props, 0, sizeof(props));
props.max_brightness = MAX_RADEON_LEVEL;
props.type = BACKLIGHT_RAW;
bd = backlight_device_register("radeon_bl", &drm_connector->kdev,
diff --git a/drivers/platform/x86/toshiba_acpi.c
b/drivers/platform/x86/toshiba_acpi.c
index bde32de..d680bb2 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -1095,6 +1095,7 @@ static int __devinit toshiba_acpi_setup_backlight(struct
toshiba_acpi_dev *dev)
ret = get_tr_backlight_status(dev, &enabled);
dev->tr_backlight_supported = !ret;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_PLATFORM;
props.max_brightness = HCI_LCD_BRIGHTNESS_LEVELS - 1;
diff --git a/drivers/video/backlight/da903x_bl.c
b/drivers/video/backlight/da903x_bl.c
index 30e1968..573c7ec 100644
--- a/drivers/video/backlight/da903x_bl.c
+++ b/drivers/video/backlight/da903x_bl.c
@@ -136,6 +136,7 @@ static int da903x_backlight_probe(struct platform_device
*pdev)
da903x_write(data->da903x_dev, DA9034_WLED_CONTROL2,
DA9034_WLED_ISET(pdata->output_current));
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = max_brightness;
bl = backlight_device_register(pdev->name, data->da903x_dev, data,
diff --git a/drivers/video/backlight/pcf50633-backlight.c
b/drivers/video/backlight/pcf50633-backlight.c
index c65853c..c092159 100644
--- a/drivers/video/backlight/pcf50633-backlight.c
+++ b/drivers/video/backlight/pcf50633-backlight.c
@@ -111,6 +111,7 @@ static int __devinit pcf50633_bl_probe(struct
platform_device *pdev)
if (!pcf_bl)
return -ENOMEM;
+ memset(&bl_props, 0, sizeof(bl_props));
bl_props.type = BACKLIGHT_RAW;
bl_props.max_brightness = 0x3f;
bl_props.power = FB_BLANK_UNBLANK;
diff --git a/drivers/video/backlight/wm831x_bl.c
b/drivers/video/backlight/wm831x_bl.c
index 5d365de..9e5517a 100644
--- a/drivers/video/backlight/wm831x_bl.c
+++ b/drivers/video/backlight/wm831x_bl.c
@@ -194,6 +194,7 @@ static int wm831x_backlight_probe(struct platform_device
*pdev)
data->current_brightness = 0;
data->isink_reg = isink_reg;
+ memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
props.max_brightness = max_isel;
bl = backlight_device_register("wm831x", &pdev->dev, data,
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index d26f37a..74e7cf0 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -532,6 +532,7 @@ static int acx_panel_probe(struct omap_dss_device *dssdev)
/*--- Backlight control */
+ memset(&props, 0, sizeof(props));
props.fb_blank = FB_BLANK_UNBLANK;
props.power = FB_BLANK_UNBLANK;
props.type = BACKLIGHT_RAW;
--
1.7.9.5
[PATCH 2/3] asus-wmi: Use acpi_video_unregister_backlight instead of acpi_video_unregister
On Mon, Jun 1, 2015 at 10:25 AM, Hans de Goede wrote:
> acpi_video_unregister() not only unregisters the acpi-video backlight
> interface but also unregisters the acpi video bus event listener, causing
> e.g. brightness hotkey presses to no longer generate keypress events.
>
> The unregistering of the acpi video bus event listener usually is
> undesirable, which by itself is a good reason to switch to
> acpi_video_unregister_backlight().
>
> Another problem with using acpi_video_unregister() rather then using
> acpi_video_unregister_backlight() is that on systems with an intel video
> opregion (most systems) and a wmi_backlight_power quirk, whether or not
> the acpi video bus event listener actually gets unregistered depends on
> module load ordering:
>
> Scenario a:
> 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
>is an intel opregion.
> 2) intel.ko gets loaded, calls acpi_video_register() which registers both
>the listener and the acpi backlight interface
> 3) asus-wmi.ko gets loaded, calls acpi_video_unregister() causing both
>the listener and the acpi backlight interface to unregister
>
> Scenario b:
> 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
>is an intel opregion.
> 2) asus-wmi.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
>calls acpi_video_unregister(), which is a nop since acpi_video_register
>has not yet been called
> 2) intel.ko gets loaded, calls acpi_video_register() which registers
>the listener, but does not register the acpi backlight interface due to
>the call to the preciding call to acpi_video_dmi_promote_vendor()
>
> *) acpi/video.ko always loads first as both other modules depend on it.
>
> So we end up with or without an acpi video bus event listener depending
> on module load ordering, not good.
>
> Switching to using acpi_video_unregister_backlight() means that independ
> of ordering we will always have an acpi video bus event listener fixing
> this.
>
> Note that this commit means that systems without an intel video opregion,
> and systems which were hitting scenario a wrt module load ordering, are
> now getting an acpi video bus event listener while before they were not!
>
> On some systems this may cause the brightness hotkeys to start generating
> keypresses while before they were not (good), while on other systems this
> may cause the brightness hotkeys to generate multiple keypress events for
> a single press (not so good). Since on most systems the acpi video bus is
> the canonical source for brightness events I believe that the latter case
> will needs to be handled on a case by case basis by filtering out the
> duplicate keypresses at the other source for them.
>
> Cc: Corentin Chary
> Cc: acpi4asus-user at lists.sourceforge.net
> Signed-off-by: Hans de Goede
> ---
> drivers/platform/x86/asus-wmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
> index 7543a56..945145d 100644
> --- a/drivers/platform/x86/asus-wmi.c
> +++ b/drivers/platform/x86/asus-wmi.c
> @@ -1777,7 +1777,7 @@ static int asus_wmi_add(struct platform_device *pdev)
> acpi_video_dmi_promote_vendor();
> if (!acpi_video_backlight_support()) {
> pr_info("Disabling ACPI video driver\n");
> - acpi_video_unregister();
> + acpi_video_unregister_backlight();
> err = asus_wmi_backlight_init(asus);
> if (err && err != -ENODEV)
> goto fail_backlight;
> --
> 2.4.2
>
Acked-by: Corentin Chary http://xf.iksaif.net
[PATCH 3/3] samsung-laptop: Use acpi_video_unregister_backlight instead of acpi_video_unregister
On Mon, Jun 1, 2015 at 10:25 AM, Hans de Goede wrote:
> acpi_video_unregister() not only unregisters the acpi-video backlight
> interface but also unregisters the acpi video bus event listener, causing
> e.g. brightness hotkey presses to no longer generate keypress events.
>
> The unregistering of the acpi video bus event listener usually is
> undesirable, which by itself is a good reason to switch to
> acpi_video_unregister_backlight().
>
> Another problem with using acpi_video_unregister() rather then using
> acpi_video_unregister_backlight() is that on systems with an intel video
> opregion (most systems) and a broken_acpi_video quirk, whether or not
> the acpi video bus event listener actually gets unregistered depends on
> module load ordering:
>
> Scenario a:
> 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
>is an intel opregion.
> 2) intel.ko gets loaded, calls acpi_video_register() which registers both
>the listener and the acpi backlight interface
> 3) samsung-laptop.ko gets loaded, calls acpi_video_unregister() causing
>both the listener and the acpi backlight interface to unregister
>
> Scenario b:
> 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
>is an intel opregion.
> 2) samsung-laptop.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
>calls acpi_video_unregister(), which is a nop since acpi_video_register
>has not yet been called
> 2) intel.ko gets loaded, calls acpi_video_register() which registers
>the listener, but does not register the acpi backlight interface due to
>the call to the preciding call to acpi_video_dmi_promote_vendor()
>
> *) acpi/video.ko always loads first as both other modules depend on it.
>
> So we end up with or without an acpi video bus event listener depending
> on module load ordering, not good.
>
> Switching to using acpi_video_unregister_backlight() means that independ
> of ordering we will always have an acpi video bus event listener fixing
> this.
>
> Note that this commit means that systems without an intel video opregion,
> and systems which were hitting scenario a wrt module load ordering, are
> now getting an acpi video bus event listener while before they were not!
>
> On some systems this may cause the brightness hotkeys to start generating
> keypresses while before they were not (good), while on other systems this
> may cause the brightness hotkeys to generate multiple keypress events for
> a single press (not so good). Since on most systems the acpi video bus is
> the canonical source for brightness events I believe that the latter case
> will needs to be handled on a case by case basis by filtering out the
> duplicate keypresses at the other source for them.
>
> Cc: Corentin Chary
> Signed-off-by: Hans de Goede
> ---
> drivers/platform/x86/samsung-laptop.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/platform/x86/samsung-laptop.c
> b/drivers/platform/x86/samsung-laptop.c
> index 9e701b2..0df03e2 100644
> --- a/drivers/platform/x86/samsung-laptop.c
> +++ b/drivers/platform/x86/samsung-laptop.c
> @@ -1730,14 +1730,14 @@ static int __init samsung_init(void)
> samsung->handle_backlight = false;
> } else if (samsung->quirks->broken_acpi_video) {
> pr_info("Disabling ACPI video driver\n");
> - acpi_video_unregister();
> + acpi_video_unregister_backlight();
> }
>
> if (samsung->quirks->use_native_backlight) {
> pr_info("Using native backlight driver\n");
> /* Tell acpi-video to not handle the backlight */
> acpi_video_dmi_promote_vendor();
> - acpi_video_unregister();
> + acpi_video_unregister_backlight();
> /* And also do not handle it ourselves */
> samsung->handle_backlight = false;
> }
> --
> 2.4.2
>
Acked-by: Corentin Chary http://xf.iksaif.net
