[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume
https://bugs.freedesktop.org/show_bug.cgi?id=86267 --- Comment #14 from stefanscheffler at gmx.net --- Created attachment 111395 --> https://bugs.freedesktop.org/attachment.cgi?id=111395&action=edit dmesg with radeon-suspend-gart-table.diff On 3.18.1 the patch applied with some offsets and didn't help. I'm getting those NULL pointer warnings now though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/52d28098/attachment.html>
[Bug 87769] (regression)(bisected)(radeonsi) mpv vdpau/opengl segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=87769 Bug ID: 87769 Summary: (regression)(bisected)(radeonsi) mpv vdpau/opengl segfaults Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: smoki00790 at gmail.com Created attachment 111400 --> https://bugs.freedesktop.org/attachment.cgi?id=111400&action=edit gdb_output Hardware is Athlon 5350 APU, Debian Sid current, etc. So this regression happens when mpv opengl video output is used together with vdpau decoder like this: mpv --hwdec=vdpau --vo=opengl On following commit playback just segfaults: auxiliary/vl: rework the build of the VL code http://cgit.freedesktop.org/mesa/mesa/commit/?id=c642e87d9f423c78bf631410e858f675292ba0c4 Works fine commit before that and issue present in current mesa git. GDB output attached. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/1994f98f/attachment.html>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Kertesz Laszlo writes: > Ok, rebuilt the xserver package with debugging symbols (seems that > checkinstall strips stuff by default). I got a bigger gdb.txt. See if it > helps. I found a bug -- glamor_xv_put_image was mis-computing the number of lines of changed video when the client drew only a subset of the image. I think the client is drawing at src_y=1, src_h=239 for some weird reason (I suspect a bug in the client). Try this patch: -- next part -- A non-text attachment was scrubbed... Name: 0001-glamor-Fix-nlines-in-glamor_xv_put_image-when-src_y-.patch Type: text/x-diff Size: 874 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/50336d2e/attachment-0001.patch> -- next part -- -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 810 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/50336d2e/attachment-0001.sig>
[Bug 87769] (regression)(bisected)(radeonsi) mpv vdpau/opengl segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=87769 smoki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from smoki --- *** This bug has been marked as a duplicate of bug 86837 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/345457c9/attachment.html>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Keith Packard writes:
> Kertesz Laszlo writes:
>
>> Ok, rebuilt the xserver package with debugging symbols (seems that
>> checkinstall strips stuff by default). I got a bigger gdb.txt. See if it
>> helps.
>
> I found a bug -- glamor_xv_put_image was mis-computing the number of
> lines of changed video when the client drew only a subset of the
> image. I think the client is drawing at src_y=1, src_h=239 for some
> weird reason (I suspect a bug in the client).
>
> Try this patch:
>
> From eaa4225413b31314070f9a52d9290649e79a3b0f Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Sat, 27 Dec 2014 09:11:33 -0800
> Subject: [PATCH] glamor: Fix nlines in glamor_xv_put_image when src_y is odd
>
> The number of lines of video to update in the texture needs to be
> computed from the height of the updated source, not the full height of
> the source.
>
> Signed-off-by: Keith Packard
> ---
> glamor/glamor_xv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
> index 1c877da..83e24ad 100644
> --- a/glamor/glamor_xv.c
> +++ b/glamor/glamor_xv.c
> @@ -435,7 +435,7 @@ glamor_xv_put_image(glamor_port_private *port_priv,
> }
>
> top = (src_y) & ~1;
> -nlines = (src_y + height) - top;
> +nlines = (src_y + src_h) - top;
>
> switch (id) {
> case FOURCC_YV12:
If the point is to upload only from the src_[xywh] recctangle, shouldn't
the glamor_upload_sub_pixmap_to_texture() calls be using src_w instead
of width, too?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/b661e7db/attachment.sig>
[Intel-gfx] 3.19-rc1 errors when opening LID
On Sat, 2014-12-27 at 21:22 +0100, Rafael J. Wysocki wrote:
[]
> +++ linux-pm/include/acpi/acpi_bus.h
> @@ -589,7 +589,8 @@ static inline u32 acpi_target_system_sta
>
> static inline bool acpi_device_power_manageable(struct acpi_device *adev)
> {
> - return adev->flags.power_manageable;
> + return adev->flags.power_manageable
> + && (adev->status.present || adev->status.functional);
Most code in the kernel has these logical
continuations at the end of the previous line.
> +++ linux-pm/drivers/acpi/device_pm.c
[]
> @@ -361,7 +362,7 @@ bool acpi_bus_power_manageable(acpi_hand
> int result;
>
> result = acpi_bus_get_device(handle, &device);
> - return result ? false : device->flags.power_manageable;
> + return result ? false : acpi_device_power_manageable(device);
This might read better as:
if (acpi_bus_get_device(handle, &device))
return false;
return acpi_device_power_manageable(device);
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
On Sat, 2014-12-27 at 09:18 -0800, Keith Packard wrote: > Kertesz Laszlo writes: > > > Ok, rebuilt the xserver package with debugging symbols (seems that > > checkinstall strips stuff by default). I got a bigger gdb.txt. See if it > > helps. > > I found a bug -- glamor_xv_put_image was mis-computing the number of > lines of changed video when the client drew only a subset of the > image. I think the client is drawing at src_y=1, src_h=239 for some > weird reason (I suspect a bug in the client). > > Try this patch: > Tried it and it works. I had a ~10 min Skype call and had no issues.
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Eric Anholt writes:
>> --- a/glamor/glamor_xv.c
>> +++ b/glamor/glamor_xv.c
>> @@ -435,7 +435,7 @@ glamor_xv_put_image(glamor_port_private *port_priv,
>> }
>>
>> top = (src_y) & ~1;
>> -nlines = (src_y + height) - top;
>> +nlines = (src_y + src_h) - top;
>>
>> switch (id) {
>> case FOURCC_YV12:
>
> If the point is to upload only from the src_[xywh] recctangle, shouldn't
> the glamor_upload_sub_pixmap_to_texture() calls be using src_w instead
> of width, too?
It doesn't need to, but it could as an optimization. Skipping lines at
the top and bottom is also just an optimization as the source rectangle
defines a subset of the provided buffer, after all. I just fixed that
optimization.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/8a1e8b40/attachment.sig>
Skype bi-directional video call crashes X server (xserver, mesa, drm, kernel from git, r600g+glamor)
Kertesz Laszlo writes: > Tried it and it works. I had a ~10 min Skype call and had no issues. Thanks for testing. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 810 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/14c97c4d/attachment.sig>
[Intel-gfx] 3.19-rc1 errors when opening LID
09:08 LNXCPU:01 -> ../../../devices/LNXSYSTM:00/LNXCPU:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXCPU:02 -> ../../../devices/LNXSYSTM:00/LNXCPU:02/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXCPU:03 -> ../../../devices/LNXSYSTM:00/LNXCPU:03/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXCPU:04 -> ../../../devices/LNXSYSTM:00/LNXCPU:04/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXCPU:05 -> ../../../devices/LNXSYSTM:00/LNXCPU:05/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXCPU:06 -> ../../../devices/LNXSYSTM:00/LNXCPU:06/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXCPU:07 -> ../../../devices/LNXSYSTM:00/LNXCPU:07/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXIOBAY:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:44/LNXIOBAY:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXPWRBN:00 -> ../../../devices/LNXSYSTM:00/LNXPWRBN:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXSYBUS:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXSYBUS:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXSYSTM:00 -> ../../../devices/LNXSYSTM:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXTHERM:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:01/LNXTHERM:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXVIDEO:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4f/LNXVIDEO:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 LNXVIDEO:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 MSFT0001:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/MSFT0001:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 MSFT0002:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/MSFT0002:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 MSFT:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C2:00/MSFT:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 NTRG0001:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C3:00/NTRG0001:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 NXP5442:00 -> ../../../devices/LNXSYSTM:00/NXP5442:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0A08:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0B00:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0B00:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0A:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0A:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0C:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0D:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0E:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:02/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:03/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:04 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:04/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:05 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:05/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:06 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:06/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C0F:07 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0F:07/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C01:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C01:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C01:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C01:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C02:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C02:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C02:01 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C02:01/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C02:02 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:02/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C02:03 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C02:03/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C04:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C04:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C09:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0C09:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0C14:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C14:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0100:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0100:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0103:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0103:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0200:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0200:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0401:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0401:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 PNP0501:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:00/PNP0501:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 SKTD000:00 -> ../../../devices/LNXSYSTM:00/SKTD000:00/ lrwxrwxrwx 1 root root 0 dec 27 09:08 SMO8810:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/SMO8810:00/ -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/9c9551f0/attachment-0001.sig>
[PATCH 1/1 linux-next] drm/nouveau/disp: replace 0x0000 by NULL for pointer
Fix sparse warning: drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c: 815:32: warning: Using plain integer as NULL pointer Signed-off-by: Fabian Frederick --- drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c index 181a2d5..e5ba510 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c @@ -812,7 +812,7 @@ exec_lookup(struct nv50_disp_priv *priv, int head, int or, u32 ctrl, case 0x0900: type = DCB_OUTPUT_DP; mask = 2; break; default: nv_error(priv, "unknown SOR mc 0x%08x\n", ctrl); - return 0x; + return NULL; } } -- 2.1.0
[PATCH 1/1 linux-next] drm/gma500: replace 0 by NULL for pointer
Fix sparse warning: drivers/gpu/drm/gma500/psb_drv.c: 328:56: warning: Using plain integer as NULL pointer Signed-off-by: Fabian Frederick --- drivers/gpu/drm/gma500/psb_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 92e7e57..9b49c155 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -325,7 +325,7 @@ static int psb_driver_load(struct drm_device *dev, unsigned long flags) if (ret) goto out_err; - dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, 0); + dev_priv->mmu = psb_mmu_driver_init(dev, 1, 0, NULL); if (!dev_priv->mmu) goto out_err; -- 2.1.0
i915: regression: after DP connected monitor is turned off, when turned on, it does not work anymore
Hi. I'm experiencing this issue on Fedora kernel, but I tested that upstream kernel behaves the same. Description of problem: On my T440s machine I'm experiencing this regression when if I turn off DP connected display, I can never make graphics work again. Version-Release number of selected component (if applicable): 3.17.6-200.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. have DP connected display 2. turn it off 3. turn it on Actual results: No signal in display. Expected results: There's signal going into display, everything is flooded in colours. Additional info: With 3.16.4-200.fc20.x86_64 this is working without any issues. I tested with current Linus's git (58628a7831edac5f7a13) and the issue is still there. 00:02.0 0300: 8086:0a16 (rev 0b) (prog-if 00 [VGA controller]) Subsystem: 17aa:220c Flags: bus master, fast devsel, latency 0, IRQ 60 Memory at f000 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at 3000 [size=64] Expansion ROM at [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192 eDP-0 connected (normal left inverted right x axis y axis) 1920x1080 60.01 + 1400x1050 59.98 1280x1024 60.02 1280x960 60.00 1024x768 60.00 800x600 60.3256.25 640x480 59.94 DP-0 disconnected (normal left inverted right x axis y axis) HDMI-0 disconnected (normal left inverted right x axis y axis) DP-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.0050.0059.94 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1280x720 60.0050.0059.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.0059.94 640x480 60.0059.94 HDMI-1 disconnected (normal left inverted right x axis y axis) Please let me know if you need me to provide any other info. I'm eager to test patches. Thanks! Jiri
[Intel-gfx] 3.19-rc1 errors when opening LID
On Saturday, December 27, 2014 09:19:49 AM Pali Rohár wrote:
> Hello,
>
> in attachment is output of ls -l /sys/bus/acpi/devices from both
> 3.13 and 3.19 kernels.
>
> Anyway Gabriele Mazzotta wrote me that new acpi devices could be
> created after commit faae404ebdc6bba (ACPICA: Add "Windows 2013"
> string to _OSI support).
>
> Maybe this another output could help you:
>
> $ cat /sys/bus/acpi/devices/INT33C5\:00/status
> 0
> $ cat /sys/bus/acpi/devices/INT33C5\:00/power_state
> (unknown)
>
> Device INT33C5 is in that dmesg log:
> acpi INT33C5:00: Cannot transition to non-D0 state from D3
The appended patch should make these messages go away, please test.
> And status 0 in sysnode could indicate that acpi device is not
> present right?
That's correct.
---
drivers/acpi/device_pm.c |7 ---
include/acpi/acpi_bus.h |3 ++-
2 files changed, 6 insertions(+), 4 deletions(-)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -589,7 +589,8 @@ static inline u32 acpi_target_system_sta
static inline bool acpi_device_power_manageable(struct acpi_device *adev)
{
- return adev->flags.power_manageable;
+ return adev->flags.power_manageable
+ && (adev->status.present || adev->status.functional);
}
static inline bool acpi_device_can_wakeup(struct acpi_device *adev)
Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -68,7 +68,8 @@ int acpi_device_get_power(struct acpi_de
{
int result = ACPI_STATE_UNKNOWN;
- if (!device || !state)
+ if (!device || !state
+ || !(device->status.present || device->status.functional))
return -EINVAL;
if (!device->flags.power_manageable) {
@@ -156,7 +157,7 @@ int acpi_device_set_power(struct acpi_de
int result = 0;
bool cut_power = false;
- if (!device || !device->flags.power_manageable
+ if (!device || !acpi_device_power_manageable(device)
|| (state < ACPI_STATE_D0) || (state > ACPI_STATE_D3_COLD))
return -EINVAL;
@@ -361,7 +362,7 @@ bool acpi_bus_power_manageable(acpi_hand
int result;
result = acpi_bus_get_device(handle, &device);
- return result ? false : device->flags.power_manageable;
+ return result ? false : acpi_device_power_manageable(device);
}
EXPORT_SYMBOL(acpi_bus_power_manageable);
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141227/addd928d/attachment-0001.sig>
[PATCH] nouveau: fix ambiguous backlight controls
Hi,
On 27-12-14 00:51, Jeremiah Mahler wrote:
> Ilia,
>
> On Fri, Dec 26, 2014 at 04:39:08PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 26, 2014 at 4:26 PM, Jeremiah Mahler
>> wrote:
>>> If a display supports backlight control using the nouveau driver, and
>>> also supports standard ACPI backlight control, there will be two sets of
>>> controls.
>>>
>>> /sys/class/backlight/acpi_video0
>>> /sys/class/backlight/nv_backlight
>>>
>>> This creates ambiguity because these controls can be out of sync with
>>> each other. One could be at 100% while the other is at 0% and the
>>> actual display brightness depends on which one was used last. This also
>>> creates anomalies in Powertop which will show two values for brightness
>>> with potentially different values.
>>>
>>> Fix this ambiguity by having the nouveau driver only enable its
>>> backlight controls if the standard ACPI controls are not present.
>>>
>>> Signed-off-by: Jeremiah Mahler
>>> ---
>>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>>> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>>> index e566c5b..3a52bd4 100644
>>> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
>>> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
>>> @@ -221,6 +221,11 @@ nouveau_backlight_init(struct drm_device *dev)
>>> struct nvif_device *device = &drm->device;
>>> struct drm_connector *connector;
>>>
>>> + if (acpi_video_backlight_support()) {
>>
>> None of the other drivers have this. Is nouveau somehow different
>> than, say, radeon in this respect?
>>
>> Unfortunately the backlight situation is pretty fubar'd... sometimes
>> the acpi controls don't work, sometimes the card controls don't work,
>> sometimes they both work but in different ways (and then everyone's
>> favourite -- neither works, and there's some third platform thing).
>> I'm pretty sure this code existed before, but got removed. See commit
>> bee564430feec1175ee64bcfd4913cacc519f817 and the previous commit
>> 5bead799d3f8 before that. The ping-pong is probably not the right way
>> to go.
>>
>
> I was not aware of that change. But you are right, it took out what I
> was trying to put back in.
>
> Thanks for the helpful information. I will have to rethink this fix.
So first of all NAK to the original fix, but I think that much was
already clear.
Let me explain how this currently works, most laptops have up to 3
backlight control interfaces (all talking to the same single backlight):
acpi_video: a standardized acpi interface for backlight control, broken on most
win8 ready laptops.
vendor: e.g. asus_wmi, dell_laptop, etc. typically not much better on
win8 ready laptops.
native: e.g. intel_backlight, nv_backlight, usually your best bet on win8
laptops, but not so much on older models.
Before windows8 only 2 of these 3 get registered / exported to userspace,
either you've:
acpi_video + native:
or:
vendor + native:
Since most vendor drivers contain:
if (acpi_video_backlight_support())
return 0;
And userspace backlight control code knows the prefer the firmware interfaces
over the native one and to simply ignore the native interface, unless there
is no firmware interface, so having 2 interfaces present in sysfs is not
really a problem as userspace knows how to deal with this.
So along came Windows 8, breaking most acpi_video implementations. This got
fixed by a new module parameter to the acpi_video driver called
use_native_backlight,
which now a days defaults to 1. When this parameter is true *and* the BIOS is
a win8 ready bios, then acpi_video will not register a backlight interface
itself,
and acpi_video_backlight_support() will still return 1, causing the vendor
interfaces
to not register. Leaving only the native interface.
Your proposed patch will break things on win8 laptops using nv_backlight, since
in the
use_native_backlight case it will cause nv_backlight to not register resulting
in
not having any backlight interface at all.
I will happily admit that the combination of acpi_backlight=[video|vendor]
+ video.use_native_backlight=[0|1] which has evolved over time is not the
prettiest
solution. IMHO if you want to clean things up, and ensure only one interface
gets
registered at a time, the solution would be to change acpi_backlight to also
take
a native option, so that on the kernel commandline we end up with only:
acpi_backlight=[video|vendor|native] and move the use_native_backlight handling
from drivers/acpi/video.c to drivers/acpi/video_detect.c .
Code wise this would mean replacing acpi_video_backlight_support() with a
function
called acpi_video_get_backlight_type which returns an enum which can be:
acpi_video_backlight_acpi_video,
acpi_video_backlight_vendor,
acpi_video_backlight_native,
And fix all callers to use that.
But, things are not that easy because there also is
acpi_video_dmi_promote_vendor()
which is used by v
