Re: [Intel-gfx] i915 GPU-hang regression in v5.6-rcx
Am Di., 25. Feb. 2020 um 04:33 Uhr schrieb Dave Airlie : > > On Tue, 25 Feb 2020 at 07:13, Chris Wilson wrote: > > > > Quoting Linus Torvalds (2020-02-24 20:18:03) > > > Let's add in some of the i915 people and list. > > > > Haswell eating kittens. The offending patch will be rolled back shortly. > > -Chris > > https://patchwork.freedesktop.org/patch/354775/ > > is the patch that is working it's way through the system. > > Dave. With this patch I get no more hanging GPU. Looks very good for me. Thanks, Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns
2014-05-16 13:53 GMT+02:00 Ville Syrjälä ville.syrj...@linux.intel.com: On Tue, May 13, 2014 at 06:38:32PM +0200, Daniel Vetter wrote: On Tue, May 13, 2014 at 05:21:49PM +0200, Jörg Otte wrote: 2014-05-13 15:22 GMT+02:00 Daniel Vetter dan...@ffwll.ch: On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote: On Tue, May 13, 2014 at 12:29 PM, Jörg Otte jrg.o...@gmail.com wrote: Branch drm-intel-nightly as of ed60c27 drm-intel-nightly: 2014y-05m-09d-21h-51m-45s integration manifest looks badly: - KDE splash screen on boot-up is not visible - x-windows don't have title and menu bars - KDE system menu is not visible - moving windows around destroys its content Ugh, that's ugly. Nothing else change like e.g. the version of xfree-video-intel? (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor=X.Org Foundation compiled for 1.11.3, module version = 2.17.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 11.0 Chris, any ideas? It's an ivybridge apparently. For the fifo underruns I think we've fully confirmed that they only happen on boot-up. I'll try to come up with some ideas what could have gone wrong there. Please test the below patch. -Daniel diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index b10fbde1d5ee..63ced2dee027 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -427,9 +427,6 @@ bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, ret = !intel_crtc-cpu_fifo_underrun_disabled; - if (enable == ret) - goto done; - intel_crtc-cpu_fifo_underrun_disabled = !enable; if (enable (INTEL_INFO(dev)-gen 5 || IS_VALLEYVIEW(dev))) @@ -441,7 +438,6 @@ bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, else if (IS_GEN8(dev)) broadwell_set_fifo_underrun_reporting(dev, pipe, enable); -done: return ret; } -- Doesn't work for me, I still have an underrun at boot-up. I'm at a loss tbh with ideas. We successfully disable both pipes, then enable pipe A and it all works. Then we enable pipe B and _both_ pipes underrun immediately afterwards. Really strange. Can you please reproduce the issue again on drm-intel-nightly (latest -nightly should also have the display corruptions fixed, so good to retest anyway) and attach a new dmesg with drm.debug=0xe. I see a few underrun on my IVB as well. But it seems to be limited to cases that involve the VGA connector, which doesn't actually exist on this machine so I can't be sure if it's really properly set up on the PCH. But so far with just two HDMI connectors I was unable to reproduce it. Meanwhile I'll try to come up with new theories and ideas. I was thinking that we might frob with the PCH refclk during driver init and that might cause the PCH underrun for Jörg, but it looks like the underruns really happen at the modeset time which is much later than the PCH refclock init. For the 1-n pipe transition, I don't think we handle it correctly at the moment. I have a fix as part of my remaining watermark patches. I rebased those and I'll repost them soon. In the meantime I pushed them to [1]. Jörg, can you give that branch a go? [1] git://gitorious.org/vsyrjala/linux.git watermarks_intm_31_notrace Unfortunately not working for me. It gives me some more errors: [drm:ivybridge_set_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A [drm:ivb_err_int_handler] *ERROR* Pipe A FIFO underrun [drm:ivybridge_set_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe B [drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder B [drm:cpt_serr_int_handler] *ERROR* PCH transcoder B FIFO underrun Thanks, Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns
2014-05-12 21:03 GMT+02:00 Daniel Vetter dan...@ffwll.ch: On Mon, May 12, 2014 at 01:25:24PM +0200, Jörg Otte wrote: 2014-05-11 18:49 GMT+02:00 Daniel Vetter daniel.vet...@ffwll.ch: On Sat, May 10, 2014 at 10:52 AM, Jörg Otte jrg.o...@gmail.com wrote: On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote: On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote: Jörg, can you please boot with drm.debug=0xe, reproduce the issue and then attach the complete dmesg? Please make sure that the dmesg contains the boot-up stuff too. Thanks, Daniel Here it is. I should mention it only happens at boot-up. [0.374095] [drm] Wrong MCH_SSKPD value: 0x20100406 [0.374096] [drm] This can cause pipe underruns and display issues. [0.374097] [drm] Please upgrade your BIOS to fix this. That can be a factor, but I think we may have some more general issue in the modeset sequence which causes these to get reported. I'm getting some on my machine as well where SSKPD looks more sane. Maybe we turn on the error reporting too early or something. But I'm not going to spend time worrying about these before my previous watermark stuff gets merged. Also the underrun reporting code itself would need some kind of rewrite to be really useful. If the display doesn't blank out during use everything is more or less fine and you can ignore these errors. It's quite likely that the errors were always present and you didn't know it. We just made them more prominent recently. -- Ville Syrjälä Intel OTC It comes out on the boot-up screen which is normally clean. So it becomes highly visible for anyone. To make sure that you're only seeing this at boot up and not elseplace please check that it doesn't show up when you do anything of the below: a) suspend/resume b) changing the output mode (e.g. with xrandr --mode) c) changing the output pipe (e.g. with xrandr --crtc) d) all of the above but with heavy system load, e.g. compile kernels with make -j num-cores*2 Also please test the latest drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel to make sure we haven't yet fixed this in our -next branch. Ok, that was a lot of homework ;) I checked a,b,d): All worked without FIFO underruns. For c): I must admit I don't know what --crtc is good for and the man page isn't very useful. I can't enter a meaningful command. $ xrandr --output output --auto --crtc 0 and $ xrandr --output output --auto --crtc 1 should do the trick, presuming you only have one output in total. Then switch a bit between them. Works without underruns, with standard and nightly kernel. Branch drm-intel-nightly as of ed60c27 drm-intel-nightly: 2014y-05m-09d-21h-51m-45s integration manifest looks badly: - KDE splash screen on boot-up is not visible - x-windows don't have title and menu bars - KDE system menu is not visible - moving windows around destroys its content Ugh, that's ugly. Nothing else change like e.g. the version of xfree-video-intel? (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor=X.Org Foundation compiled for 1.11.3, module version = 2.17.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 11.0 apart from that: Via control key I can open a terminal and I checked a,b), both worked without FIFO underruns. And what about at boot? If -nightly regresses even on that that's pretty awful. Sorry I forgot to mention this. It behaves like the standard kernel. The FIFO underrun comes at boot-up. And than never again. Also please test http://patchwork.freedesktop.org/patch/25568/ For me it doesn't make any difference. it might help for your case. If it doesn't we need to look into what exactly goes wrong on driver load Don't know if this matters: I always use kernels without loadable modules. Everything is built-in. Thanks, Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns
2014-05-13 15:22 GMT+02:00 Daniel Vetter dan...@ffwll.ch: On Tue, May 13, 2014 at 12:38:41PM +0200, Daniel Vetter wrote: On Tue, May 13, 2014 at 12:29 PM, Jörg Otte jrg.o...@gmail.com wrote: Branch drm-intel-nightly as of ed60c27 drm-intel-nightly: 2014y-05m-09d-21h-51m-45s integration manifest looks badly: - KDE splash screen on boot-up is not visible - x-windows don't have title and menu bars - KDE system menu is not visible - moving windows around destroys its content Ugh, that's ugly. Nothing else change like e.g. the version of xfree-video-intel? (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor=X.Org Foundation compiled for 1.11.3, module version = 2.17.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 11.0 Chris, any ideas? It's an ivybridge apparently. For the fifo underruns I think we've fully confirmed that they only happen on boot-up. I'll try to come up with some ideas what could have gone wrong there. Please test the below patch. -Daniel diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index b10fbde1d5ee..63ced2dee027 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -427,9 +427,6 @@ bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, ret = !intel_crtc-cpu_fifo_underrun_disabled; - if (enable == ret) - goto done; - intel_crtc-cpu_fifo_underrun_disabled = !enable; if (enable (INTEL_INFO(dev)-gen 5 || IS_VALLEYVIEW(dev))) @@ -441,7 +438,6 @@ bool __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev, else if (IS_GEN8(dev)) broadwell_set_fifo_underrun_reporting(dev, pipe, enable); -done: return ret; } -- Doesn't work for me, I still have an underrun at boot-up. Thanks, Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Work-around garbage DR4 from UXA
2014-05-13 15:56 GMT+02:00 Daniel Vetter dan...@ffwll.ch: On Tue, May 13, 2014 at 01:25:49PM +0100, Chris Wilson wrote: On Tue, May 13, 2014 at 02:02:07PM +0200, Daniel Vetter wrote: Somehow UXA submits a completely bogus DR4 value since essentially forever. It was originally introduced in commit bade7d7d2505a10a8a7d24b084aff9742e2d6d64 Author: Eric Anholt e...@anholt.net Date: Fri Jun 6 14:03:25 2008 -0700 Use the DRM for submitting batchbuffers when available. and dutifully copied around ever since. Since we want to keep the general dirt catching around just special case the UXA value. This regression was introduced in commit 9cb346648d9c529eccc5c7f30093e82d37004e37 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Thu Apr 24 08:09:11 2014 +0200 drm/i915: Catch dirt in unused execbuffer fields v2: Pimp commit message a bit and remove the double space. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78494 Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Jörg Otte jrg.o...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch To be fair, it is a sensible value if one supposes a Region style API to cliprects. Under that API, DR[14] define the extents of the clip region, and ((0,0), (0,0)) [DR1==DR4==0] would mean all clipped, do not draw anything. Hm right. I've added this to the commit message. Anyway, as far as fixing up the EINVAL, Acked-by: Chris Wilson ch...@chris-wilson.co.uk And merged the patch to dinq. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch Patch works for me.Thanks Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns
2014-05-11 18:49 GMT+02:00 Daniel Vetter daniel.vet...@ffwll.ch: On Sat, May 10, 2014 at 10:52 AM, Jörg Otte jrg.o...@gmail.com wrote: On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote: On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote: Jörg, can you please boot with drm.debug=0xe, reproduce the issue and then attach the complete dmesg? Please make sure that the dmesg contains the boot-up stuff too. Thanks, Daniel Here it is. I should mention it only happens at boot-up. [0.374095] [drm] Wrong MCH_SSKPD value: 0x20100406 [0.374096] [drm] This can cause pipe underruns and display issues. [0.374097] [drm] Please upgrade your BIOS to fix this. That can be a factor, but I think we may have some more general issue in the modeset sequence which causes these to get reported. I'm getting some on my machine as well where SSKPD looks more sane. Maybe we turn on the error reporting too early or something. But I'm not going to spend time worrying about these before my previous watermark stuff gets merged. Also the underrun reporting code itself would need some kind of rewrite to be really useful. If the display doesn't blank out during use everything is more or less fine and you can ignore these errors. It's quite likely that the errors were always present and you didn't know it. We just made them more prominent recently. -- Ville Syrjälä Intel OTC It comes out on the boot-up screen which is normally clean. So it becomes highly visible for anyone. To make sure that you're only seeing this at boot up and not elseplace please check that it doesn't show up when you do anything of the below: a) suspend/resume b) changing the output mode (e.g. with xrandr --mode) c) changing the output pipe (e.g. with xrandr --crtc) d) all of the above but with heavy system load, e.g. compile kernels with make -j num-cores*2 Also please test the latest drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel to make sure we haven't yet fixed this in our -next branch. Ok, that was a lot of homework ;) I checked a,b,d): All worked without FIFO underruns. For c): I must admit I don't know what --crtc is good for and the man page isn't very useful. I can't enter a meaningful command. Branch drm-intel-nightly as of ed60c27 drm-intel-nightly: 2014y-05m-09d-21h-51m-45s integration manifest looks badly: - KDE splash screen on boot-up is not visible - x-windows don't have title and menu bars - KDE system menu is not visible - moving windows around destroys its content apart from that: Via control key I can open a terminal and I checked a,b), both worked without FIFO underruns. Thanks, Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.14.0-rc4] regression: drm FIFO underruns
2014-05-09 19:03 GMT+02:00 Ville Syrjälä ville.syrj...@linux.intel.com: On Fri, May 09, 2014 at 05:14:38PM +0100, Damien Lespiau wrote: On Fri, May 09, 2014 at 06:11:37PM +0200, Jörg Otte wrote: Jörg, can you please boot with drm.debug=0xe, reproduce the issue and then attach the complete dmesg? Please make sure that the dmesg contains the boot-up stuff too. Thanks, Daniel Here it is. I should mention it only happens at boot-up. [0.374095] [drm] Wrong MCH_SSKPD value: 0x20100406 [0.374096] [drm] This can cause pipe underruns and display issues. [0.374097] [drm] Please upgrade your BIOS to fix this. That can be a factor, but I think we may have some more general issue in the modeset sequence which causes these to get reported. I'm getting some on my machine as well where SSKPD looks more sane. Maybe we turn on the error reporting too early or something. But I'm not going to spend time worrying about these before my previous watermark stuff gets merged. Also the underrun reporting code itself would need some kind of rewrite to be really useful. If the display doesn't blank out during use everything is more or less fine and you can ignore these errors. It's quite likely that the errors were always present and you didn't know it. We just made them more prominent recently. -- Ville Syrjälä Intel OTC It comes out on the boot-up screen which is normally clean. So it becomes highly visible for anyone. Thanks, Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ 3.14.0-12041-g75ff24f ] regression: drm warning
2014-04-09 12:08 GMT+02:00 Jörg Otte jrg.o...@gmail.com: Kernel 3.14.0-12041-g75ff24f from 9.4.2014 introduces the following on the console (driver is i915): [drm:ivb_err_int_handler] *ERROR* Pipe B FIFO underrun [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun [drm:cpt_serr_int_handler] *ERROR* PCH transcoder B FIFO underrun In syslog I find: [ cut here ] WARNING: CPU: 1 PID: 1 at /data/kernel/linux/drivers/gpu/drm/drm_mm.c:211 0xb22a70fa() no hole found for node 0x0 + 0x30 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12041-g75ff24f #45 Hardware name: FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 b2967138 b262ae5d 8802160d5a58 b20391ad 880214994000 0030 880214952800 b2039255 b2967190 Call Trace: [b262ae5d] ? 0xb262ae5d [b20391ad] ? 0xb20391ad [b2039255] ? 0xb2039255 [b22a70fa] ? 0xb22a70fa [b22d4b11] ? 0xb22d4b11 [b2300f92] ? 0xb2300f92 [b232af7b] ? 0xb232af7b [b232f675] ? 0xb232f675 [b21fa38c] ? 0xb21fa38c [b232ec04] ? 0xb232ec04 [b2622997] ? 0xb2622997 [b232ee62] ? 0xb232ee62 [b22a6a5b] ? 0xb22a6a5b [b22a3994] ? 0xb22a3994 [b22a5a38] ? 0xb22a5a38 [b221a019] ? 0xb221a019 [b23327b8] ? 0xb23327b8 [b2332a03] ? 0xb2332a03 [b2332970] ? 0xb2332970 [b2330c45] ? 0xb2330c45 [b2331534] ? 0xb2331534 [b2332fce] ? 0xb2332fce [b2aa2cc5] ? 0xb2aa2cc5 [b2a7fe45] ? 0xb2a7fe45 [b2052100] ? 0xb2052100 [b2a7ffe2] ? 0xb2a7ffe2 [b2a7f79e] ? 0xb2a7f79e [b2624d20] ? 0xb2624d20 [b2624d29] ? 0xb2624d29 [b263223c] ? 0xb263223c [b2624d20] ? 0xb2624d20 ---[ end trace 0d3f14b61bc31dab ]--- This does not happen in 3.14.0-11030-ga7963eb from 8.4.2014 and never before. Suppose merge 12024 e9f37d3 Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux produces this problem. cc to more people.. Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: restore the early forcewake cleanup
2013/11/16 Daniel Vetter daniel.vet...@ffwll.ch:
Some BIOS just leak the forcewak bits, which we clean up.
Unfortunately this has been broken in
commit 521198a2e7095c8c7daa8d7d3a76a110c346be6f
Author: Mika Kuoppala mika.kuopp...@linux.intel.com
Date: Fri Aug 23 16:52:30 2013 +0300
drm/i915: sanitize forcewake registers on reset
To make this work both for resets and for BIOS takeover just add the
forcewake clearing call back to intel_uncore_early_sanitize.
Cc: Mika Kuoppala mika.kuopp...@linux.intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Reported-by: Jörg Otte jrg.o...@gmail.com
Cc: Jörg Otte jrg.o...@gmail.com
References: https://lkml.org/lkml/2013/11/16/40
Cc: sta...@vger.kernel.org (for 3.12 only)
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_uncore.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 29532aeef294..ed65f5f93a59 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -217,6 +217,19 @@ static void gen6_force_wake_work(struct work_struct
*work)
spin_unlock_irqrestore(dev_priv-uncore.lock, irqflags);
}
+static void intel_uncore_forcewake_reset(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (IS_VALLEYVIEW(dev)) {
+ vlv_force_wake_reset(dev_priv);
+ } else if (INTEL_INFO(dev)-gen = 6) {
+ __gen6_gt_force_wake_reset(dev_priv);
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
+ __gen6_gt_force_wake_mt_reset(dev_priv);
+ }
+}
+
void intel_uncore_early_sanitize(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -234,19 +247,8 @@ void intel_uncore_early_sanitize(struct drm_device *dev)
dev_priv-ellc_size = 128;
DRM_INFO(Found %zuMB of eLLC\n, dev_priv-ellc_size);
}
-}
-static void intel_uncore_forcewake_reset(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
-
- if (IS_VALLEYVIEW(dev)) {
- vlv_force_wake_reset(dev_priv);
- } else if (INTEL_INFO(dev)-gen = 6) {
- __gen6_gt_force_wake_reset(dev_priv);
- if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
- __gen6_gt_force_wake_mt_reset(dev_priv);
- }
+ intel_uncore_forcewake_reset(dev);
}
void intel_uncore_sanitize(struct drm_device *dev)
--
1.8.4.3
Patch works for me, Thanks again!
Jörg
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] Fix Win8 backlight issue
2013/9/27 Rafael J. Wysocki r...@sisk.pl: On Thursday, September 26, 2013 09:49:03 AM Jörg Otte wrote: 2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Jörg Otte jrg.o...@gmail.com wrote: 2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Aaron Lu aaron...@intel.com wrote: On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? In v3.11-rc1 it didn't work. Since a later rc (I don't remember exactly which) it did work. In v3.12-rc1/2 it does work. In v3.12-rc2 + Aaron's patch set it again doesn't work. Thanks for the test. Please check /sys/class/backlight, is there only one link file intel_backlight? Indeed, are there others? fujitsu-laptop perhaps? If yes, try CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? There is only one intel_backlight link. Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y Embarrassingly there was a bug in i915 fixed just recently where the backlight device wasn't registered for CONFIG_BACKLIGHT_CLASS_DEVICE=m... If so, please cd inside and try modify the brightness file using echo with some values in the range of 0 - max_brightness, does the backlight level change when you echo a new value? I guess it doesn't, or you wouldn't notice problem. If indeed so, perhaps file a bug at http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani and Daniel can help fix your problem. Yup, please check the above, and report back. - echo 0..max_brightness brightness does not work. Thanks for the info. How about v3.12-rc2 without Aaron's patches? Does intel_backlight also not work there? How about the acpi_video0 (which I presume is present) sysfs interface? Without Aaron's patches intel_backlight also does not work. But acpi_video0 does (and takes precedence I think). So can you please open a bug entry at bugzilla.kernel.org against i915? The fact that ACPI video works for you doesn't mean that intel_backlight shouldn't, I suppose? Rafael done. Bug-Id:62281 Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] Fix Win8 backlight issue
2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Jörg Otte jrg.o...@gmail.com wrote: 2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Aaron Lu aaron...@intel.com wrote: On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? In v3.11-rc1 it didn't work. Since a later rc (I don't remember exactly which) it did work. In v3.12-rc1/2 it does work. In v3.12-rc2 + Aaron's patch set it again doesn't work. Thanks for the test. Please check /sys/class/backlight, is there only one link file intel_backlight? Indeed, are there others? fujitsu-laptop perhaps? If yes, try CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? There is only one intel_backlight link. Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y Embarrassingly there was a bug in i915 fixed just recently where the backlight device wasn't registered for CONFIG_BACKLIGHT_CLASS_DEVICE=m... If so, please cd inside and try modify the brightness file using echo with some values in the range of 0 - max_brightness, does the backlight level change when you echo a new value? I guess it doesn't, or you wouldn't notice problem. If indeed so, perhaps file a bug at http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani and Daniel can help fix your problem. Yup, please check the above, and report back. - echo 0..max_brightness brightness does not work. Thanks for the info. How about v3.12-rc2 without Aaron's patches? Does intel_backlight also not work there? How about the acpi_video0 (which I presume is present) sysfs interface? Without Aaron's patches intel_backlight also does not work. But acpi_video0 does (and takes precedence I think). Video driver: i915 FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] Fix Win8 backlight issue
Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 Video driver: i915 FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 acpi_backlight=video works. Jörg 2013/9/24 Igor Gnatenko i.gnatenko.br...@gmail.com On Tue, 2013-09-24 at 17:47 +0800, Aaron Lu wrote: v3: 1 Add a new patch 4/4 to fix some problems in thinkpad-acpi module; 2 Remove unnecessary function acpi_video_unregister introduced in patch 2/3 as pointed out by Jani Nikula. v2: v1 has the subject of Rework ACPI video driver and is posted here: http://lkml.org/lkml/2013/9/9/74 Since the objective is really to fix Win8 backlight issues, I changed the subject in this version, sorry about that. This patchset has three patches, the first introduced a new API named backlight_device_registered in backlight layer that can be used for backlight interface provider module to check if a specific type backlight interface has been registered, see changelog for patch 1/3 for details. Then patch 2/3 does the cleanup to sepeate the backlight control and event delivery functionality in the ACPI video module and patch 3/3 solves some Win8 backlight control problems by avoiding register ACPI video's backlight interface if: 1 Kernel cmdline option acpi_backlight=video is not given; 2 This is a Win8 system; 3 Native backlight control interface exists. Technically, patch 2/3 is not required to fix the issue here. So if you think it is not necessary, I can remove it from the series. Aaron Lu (4): backlight: introduce backlight_device_registered ACPI / video: seperate backlight control and event interface ACPI / video: Do not register backlight if win8 and native interface exists thinkpad-acpi: fix handle locate for video and query of _BCL drivers/acpi/internal.h | 5 +- drivers/acpi/video.c | 442 --- drivers/acpi/video_detect.c | 14 +- drivers/platform/x86/thinkpad_acpi.c | 31 ++- drivers/video/backlight/backlight.c | 31 +++ include/acpi/video.h | 2 + include/linux/backlight.h| 4 + 7 files changed, 324 insertions(+), 205 deletions(-) Excellent! I've tested this patch-set on ThinkPad X230 and backlight issue is exhausted. Thanks. -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.1-300.fc20.x86_64 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/4] Fix Win8 backlight issue
2013/9/25 Jani Nikula jani.nik...@linux.intel.com: On Wed, 25 Sep 2013, Aaron Lu aaron...@intel.com wrote: On Wed, Sep 25, 2013 at 10:29:37AM +0200, Jörg Otte wrote: Backlight can't be modified with this patch set - neither with function keys nor with the gui. It is a step backward to v3.11-rc1 So both hotkeys and GUI work in v3.11-rc1? And v3.12-rc2? In v3.11-rc1 it didn't work. Since a later rc (I don't remember exactly which) it did work. In v3.12-rc1/2 it does work. In v3.12-rc2 + Aaron's patch set it again doesn't work. Thanks for the test. Please check /sys/class/backlight, is there only one link file intel_backlight? Indeed, are there others? fujitsu-laptop perhaps? If yes, try CONFIG_FUJITSU_LAPTOP=n or an appropriate module blacklist. Just checking, you do have CONFIG_BACKLIGHT_CLASS_DEVICE=y? There is only one intel_backlight link. Yes, I have CONFIG_BACKLIGHT_CLASS_DEVICE=y Embarrassingly there was a bug in i915 fixed just recently where the backlight device wasn't registered for CONFIG_BACKLIGHT_CLASS_DEVICE=m... If so, please cd inside and try modify the brightness file using echo with some values in the range of 0 - max_brightness, does the backlight level change when you echo a new value? I guess it doesn't, or you wouldn't notice problem. If indeed so, perhaps file a bug at http://bugzilla.kernel.org, Drivers/Video(DRI-Intel)? I suppose Jani and Daniel can help fix your problem. Yup, please check the above, and report back. - echo 0..max_brightness brightness does not work. Video driver: i915 FUJITSU LIFEBOOK AH532/FJNBB1C, BIOS Version 1.09 05/22/2012 acpi_backlight=video works. Jörg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.11-rc2 (acpi backlight, revert)
2013/7/25 Rafael J. Wysocki r...@sisk.pl: 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 r...@sisk.pl 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
