Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
Woody Suwalski wrote: Christian König wrote: Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: Hi Woody, sorry for the late reply, I've been off to a vacation over the holidays. On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: Regression in 5.4 kernel on 32-bit Radeon IBM T40 triggered by commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 Author: Christoph Hellwig Date: Thu Aug 15 09:27:00 2019 +0200 Howdy, The above patch has triggered a display problem on IBM Thinkpad T40, where the screen is covered with a lots of random short black horizontal lines, or distorted letters in X terms. The culprit seems to be that the dma_get_required_mask() is returning a value 0x3fff which is smaller than dma_get_mask()0x.That results in dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma instead of 32-bits. Which is the intended behavior assuming your system has 1GB of memory. Does it? Assuming the system doesn't have the 1GB split up somehow crazy over the address space that should indeed work as intended. If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of a call to dma_addressing_limited(),the problem goes away. I'll need some help from the drm / radeon / TTM maintainers if there are any other side effects from not passing the need_dma32 paramters. Obviously if the device doesn't have more than 32-bits worth of dram and no DMA offset we can't feed unaddressable memory to the device. Unfortunately I have a very hard time following the implementation of the TTM pool if it does anything else in this case. The only other thing which comes to mind is using huge pages. Can you try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled? Thanks, Christian. Happy New Year :-) Yes, the box has 1G of RAM, and unfortunately nope, TRANSPARENT_HUGEPAGE is not on. I am attaching the .config, maybe you can find some insanity there... Also - for reference - a minimalistic patch fixing symptoms (but not addressing the root cause :-( ) I can try to rebuild the kernel with HIGHMEM off, although I am not optimistic it will change anything. But at least it should simplify the 1G split... So if you have any other ideas - pls let me know.. Thanks, Woody Interesting. Rebuilding the kernel with HIMEM disabled actually solves the display problem. The debug lines show exactly same values for dma_get_required_mask() and dma_get_mask(), yet now it works OK... So what has solved it??? Woody ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Regression in 5.4 kernel on 32-bit Radeon IBM T40
Regression in 5.4 kernel on 32-bit Radeon IBM T40 triggered by commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 Author: Christoph Hellwig Date: Thu Aug 15 09:27:00 2019 +0200 Howdy, The above patch has triggered a display problem on IBM Thinkpad T40, where the screen is covered with a lots of random short black horizontal lines, or distorted letters in X terms. The culprit seems to be that the dma_get_required_mask() is returning a value 0x3fff which is smaller than dma_get_mask()0x.That results in dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma instead of 32-bits. If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of a call to dma_addressing_limited(),the problem goes away. I have added the debug lines starting with "wms:" to the start of radeon_ttm_init() and of radeon_device_init()printing the interesting variables. / [ 2.091692] Linux agpgart interface v0.103 [ 2.092380] agpgart-intel :00:00.0: Intel 855PM Chipset [ 2.107706] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000 [ 2.108111] [drm] radeon kernel modesetting enabled. [ 2.108200] radeon :01:00.0: vgaarb: deactivate vga console [ 2.109365] Console: switching to colour dummy device 80x25 *** radeon_device_init() [ 2.110712] wms: radeon_init flags = 0x90003 [ 2.110718] [drm] initializing kernel modesetting (RV200 0x1002:0x4C57 0x1014:0x0530 0x00). [ 2.111220] agpgart-intel :00:00.0: AGP 2.0 bridge [ 2.111233] agpgart-intel :00:00.0: putting AGP V2 device into 1x mode [ 2.111265] radeon :01:00.0: putting AGP V2 device into 1x mode [ 2.111286] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF [ 2.111295] radeon :01:00.0: VRAM: 128M 0xE000 - 0xE7FF (32M used) [ 2.111701] [drm] Detected VRAM RAM=128M, BAR=128M [ 2.111704] [drm] RAM width 64bits DDR *** radeon_ttm_init() [ 2.111706] wms: dma_addressing_limited=0x0 [ 2.111709] wms: dma_get_mask=0x, bus_dma_limit=0x0, dma_get_required_mask=0x3fff [ 2.115971] [TTM] Zone kernel: Available graphics memory: 437028 KiB [ 2.115973] [TTM] Zone highmem: Available graphics memory: 510440 KiB What should be the proper value of these dma variables on the 32-bit system? How to fix that issue correctly (patches welcomed :-) )Or is the platform fubar? Thanks, Woody ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RESEND] vmwgfx: use monotonic event timestamps
Thomas Hellstrom wrote:
Hi, Arnd,
Sinclair's on paternal leave and I thought this patch was already in
drm-next. My bad.
Dave, is it too late to pull this in for the next merge window?
/Thomas
On 01/16/2018 06:18 PM, Arnd Bergmann wrote:
DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.
As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic times for
drm_event_vblank,
but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
the y2038/y2106 overflow as well as time jumps.
For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
which solves those problems and avoids the deprecated do_gettimeofday()
function.
This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().
Link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_10076599_&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=8M6vawBo0zDsjbqhzV0xpOwAzX7Zm-uyGlIDnQ7-Gms&s=sHGuz0aoE9aLjVp5GALo8mYrN1bwOHW6mGpJIZmhwAc&e=
Signed-off-by: Arnd Bergmann
---
Originally sent on Nov 27. Sinclair Yeh said he'd pick it up
for the next pull request, but it's not in linux-next yet.
Resending the unchanged patch, please pick it up when you have time,
or feel free to ignore this email in case it's already in some tree
that just isn't part of linux-next but will be sent during the
next merge window.
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 6c5c75cf5e6c..9ed544f8958f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -901,11 +901,12 @@ static void
vmw_event_fence_action_seq_passed(struct vmw_fence_action *action)
spin_lock_irq(&dev->event_lock);
if (likely(eaction->tv_sec != NULL)) {
- struct timeval tv;
+ struct timespec64 ts;
- do_gettimeofday(&tv);
- *eaction->tv_sec = tv.tv_sec;
- *eaction->tv_usec = tv.tv_usec;
+ ktime_get_ts64(&ts);
+ /* monotonic time, so no y2038 overflow */
+ *eaction->tv_sec = ts.tv_sec;
+ *eaction->tv_usec = ts.tv_nsec / NSEC_PER_USEC;
}
drm_send_event_locked(dev, eaction->event);
Thomas, the same way my DRM patch has disappeared:
Date
Tue, 19 Dec 2017 11:50:57 -0800
FromSinclair Yeh <>
Subject Re: [PATCH v.2] 4.15 vmgfx boot warning
This looks okay to me.
On Mon, Dec 18, 2017 at 07:26:03PM -0500, Woody Suwalski wrote:
The 4.15 drm_atomic_helper driver shows a warning during boot (both 32 and
64 bit x86)
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
/...
ret = drm_crtc_vblank_get(crtc);
WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
/...
Signed-off by: Woody Suwalski
--- a/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 09:55:33.853374561
-0500
+++ b/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 10:55:56.089090752
-0500
@@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
continue;
ret = drm_crtc_vblank_get(crtc);
- WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
+ WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to
call drm_crtc_vblank_off()\n");
if (ret == 0)
drm_crtc_vblank_put(crtc);
}
===
The 4.15 drm_atomic_helper driver shows a warning during boot.
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
/...
ret = drm_crtc_vblank_get(crtc);
WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n");
/...
Signed-off by: Woody Suwalski
--- a/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 09:55:33.853374561
-0500
+++ b/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 10:55:56.089090752
-0500
@@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev,
continue;
ret = drm_crtc_vblank_get(crtc);
- WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
+ WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to call
drm_crtc_vblank_off()\n");
if (ret == 0)
drm_crtc_vblank_put(crtc);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v.2] 4.15 vmgfx boot warning
The 4.15 drm_atomic_helper driver shows a warning during boot (both 32 and 64 bit x86) It is caused by a mismatch between the result of vmw_enable_vblank() and what the drm_atomic_helper expects: /... ret = drm_crtc_vblank_get(crtc); WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n"); /... Signed-off by: Woody Suwalski --- a/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 09:55:33.853374561 -0500 +++ b/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 10:55:56.089090752 -0500 @@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev, continue; ret = drm_crtc_vblank_get(crtc); - WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n"); + WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to call drm_crtc_vblank_off()\n"); if (ret == 0) drm_crtc_vblank_put(crtc); } --- a/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 09:55:33.853374561 -0500 +++ b/drivers/gpu/drm/drm_atomic_helper.c 2017-12-16 10:55:56.089090752 -0500 @@ -889,7 +889,7 @@ disable_outputs(struct drm_device *dev, continue; ret = drm_crtc_vblank_get(crtc); - WARN_ONCE(ret != -EINVAL, "driver forgot to call drm_crtc_vblank_off()\n"); + WARN_ONCE((ret != -EINVAL && ret != -ENOSYS), "driver forgot to call drm_crtc_vblank_off()\n"); if (ret == 0) drm_crtc_vblank_put(crtc); } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] 4.15 vmgfx boot warning
Sinclair Yeh wrote:
Hi Woody,
On Wed, Nov 22, 2017 at 04:05:50PM -0500, Woody Suwalski wrote:
The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
/...
ret = drm_crtc_vblank_get(crtc);
WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
This doesn't apply to us because we don't have vblank support, and so
-ENOSYS seems to be the right error.
In the commit message for 84014b0a39ee, it does state a check for this
condition, but the check itself is based on dev->irq_enabled.
Is there another way to check for vblank support?
/...
Signed-off by: Woody Suwalski
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 2017-11-22 15:29:46.511674079
-0500
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 2017-11-22 15:30:35.344559592
-0500
@@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de
*/
int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
{
- return -ENOSYS;
+ return -EINVAL;
}
/**
Sinclair, it is a valid stand, so I guess it is time to ask Daniel...
Would it be OK to convert the WARN_ONCE statement in drm_atomic_helper
to recognize ENOSYS as a valid error? Something like
WARN_ONCE((ret != -EINVAL && ret != _ENOSYS), "driver forgot to call
drm_crtc_vblank_off()\n");
Thanks, Woody
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] 4.15 vmgfx boot warning
The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
/...
ret = drm_crtc_vblank_get(crtc);
WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
/...
Signed-off by: Woody Suwalski
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 2017-11-22
15:29:46.511674079 -0500
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 2017-11-22
15:30:35.344559592 -0500
@@ -1869,7 +1869,7 @@ u32 vmw_get_vblank_counter(struct drm_de
*/
int vmw_enable_vblank(struct drm_device *dev, unsigned int pipe)
{
- return -ENOSYS;
+ return -EINVAL;
}
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nouveau nullptr on NVIDIA NVA8
Starting with the drm merge af3c8d98508d37541d4bf57f13a984a7f73a328c for 4.13-rc1, the NVidia NVS3100M display on Dell Latitude E6410 had a nullptr crash on startup. As a result later the suspend2ram was locking up. Traced to a null ptr in nv50_mstm_service(), which seems to be called only from nouveau_connector_hotplug(). Fixed by checking if mstm is not NULL before calling the service function. [1.176456] Linux agpgart interface v0.103 [1.176610] [drm] radeon kernel modesetting enabled. [1.17] [drm] amdgpu kernel modesetting enabled. [1.176749] ACPI Warning: \_SB.PCI0.AGP.VID._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170531/nsarguments-95) [1.176780] ACPI: \_SB_.PCI0.AGP_.VID_: failed to evaluate _DSM [1.176948] nouveau :01:00.0: NVIDIA GT218 (0a8600b1) [1.196734] nouveau :01:00.0: bios: version 70.18.53.00.04 [1.198112] nouveau :01:00.0: fb: 512 MiB DDR3 [1.251598] [TTM] Zone kernel: Available graphics memory: 1496332 kiB [1.251600] [TTM] Initializing pool allocator [1.251605] [TTM] Initializing DMA pool allocator [1.251625] nouveau :01:00.0: DRM: VRAM: 512 MiB [1.251628] nouveau :01:00.0: DRM: GART: 1048576 MiB [1.251634] nouveau :01:00.0: DRM: TMDS table version 2.0 [1.251637] nouveau :01:00.0: DRM: DCB version 4.0 [1.251641] nouveau :01:00.0: DRM: DCB outp 00: 048003b6 0f200014 [1.251644] nouveau :01:00.0: DRM: DCB outp 01: 02033300 [1.251647] nouveau :01:00.0: DRM: DCB outp 02: 088223a6 0f220010 [1.251650] nouveau :01:00.0: DRM: DCB outp 03: 08022362 00020010 [1.251652] nouveau :01:00.0: DRM: DCB outp 04: 028113c6 0f220010 [1.251655] nouveau :01:00.0: DRM: DCB outp 05: 02011382 00020010 [1.251657] nouveau :01:00.0: DRM: DCB conn 00: 2047 [1.251660] nouveau :01:00.0: DRM: DCB conn 01: 00101146 [1.251662] nouveau :01:00.0: DRM: DCB conn 02: 00410246 [1.251664] nouveau :01:00.0: DRM: DCB conn 03: 0300 [1.278401] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.278403] [drm] Driver supports precise vblank timestamp query. [1.323205] nouveau :01:00.0: DRM: MM: using COPY for buffer copies [1.473861] nouveau :01:00.0: DRM: allocated 1440x900 fb: 0x7, bo 8800b7baa000 [1.476208] fbcon: nouveaufb (fb0) is primary device [1.830143] BUG: unable to handle kernel NULL pointer dereference at 0020 [1.830152] IP: nv50_mstm_service+0xc/0xb0 [1.830153] PGD 0 [1.830154] P4D 0 [1.830158] Oops: [#1] PREEMPT SMP [1.830159] Modules linked in: [1.830164] CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 4.13-pingu #1 [1.830166] Hardware name: Dell Inc. Latitude E6410/0K42JR, BIOS A16 12/05/2013 [1.830171] Workqueue: events nvif_notify_work [1.830173] task: 8800b79f1680 task.stack: c9154000 [1.830176] RIP: 0010:nv50_mstm_service+0xc/0xb0 [1.830178] RSP: :c9157df0 EFLAGS: 00010286 [1.830180] RAX: 8800b7096800 RBX: 8800b71b9418 RCX: 8800b7096800 [1.830182] RDX: 8800b7a98b9c RSI: 002b RDI: [1.830183] RBP: 0008 R08: 8800b7096818 R09: [1.830185] R10: R11: 0040 R12: 8800b71b9000 [1.830187] R13: R14: R15: 8800b71b9418 [1.830189] FS: () GS:8800bb2c() knlGS: [1.830191] CS: 0010 DS: ES: CR0: 80050033 [1.830193] CR2: 0020 CR3: 02209000 CR4: 06e0 [1.830194] Call Trace: [1.830200] ? find_encoder+0x33/0x70 [1.830204] ? nouveau_connector_hotplug+0x56/0x100 [1.830206] ? nvif_notify_work+0x1f/0xa0 [1.830210] ? nvkm_notify_work+0x64/0x70 [1.830214] ? process_one_work+0x1a3/0x320 [1.830217] ? worker_thread+0x42/0x3d0 [1.830220] ? kthread+0xf2/0x130 [1.830223] ? process_one_work+0x320/0x320 [1.830225] ? kthread_create_on_node+0x40/0x40 [1.830228] ? call_usermodehelper_exec_async+0x125/0x130 [1.830233] ? ret_from_fork+0x25/0x30 [1.830234] Code: 89 04 24 e8 d7 2f ca ff 48 89 df e8 2f 72 c8 ff 48 89 df e8 f7 ac 99 ff 48 83 c4 08 5b c3 90 41 54 55 48 8d 6f 08 53 48 83 ec 18 <48> 8b 5f 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 c6 [1.830276] RIP: nv50_mstm_service+0xc/0xb0 RSP: c9157df0 [1.830277] CR2: 0020 [1.830281] ---[ end trace 9578c3b6b1cff0d4 ]--- [1.957826] Console: switching to colour frame buffer device 180x56 [1.975000] nouveau :01:00.0: fb0: nouveaufb frame buffer device [1.975037] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 Signed-off-by: Woody Suwalski --- diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/g
Radeon wakeup regression in 3.15-rc6
Malte Schr?der wrote: > Hi, > I just tried 3.15-rc6. I encountered a pretty nasty problem, which is > after suspending to RAM the system doesn't wake up properly. v3.14 is fine. > On wakeup all seems fine, i.e. hd starts to spin an USB-stuff wakes up. > But all I get from the graphics card is a white screen slowly filling > with random colored pixels. I had to hard reset the system. > > I attached the kernel log, the X-servers log, lspci-output and my kernel > config. > > Regards > Malte I have seen a bit of a screen distortion at the bottom of LCD on Radeon after a wakeup. I tried to re-run with drm.debug=0x0e, however once I did it - the problem has disappeared, and I have not been able to duplicate it again. So just watching for now. OTOH I have seen (only one time) a black screen after wakeup on Nvidia. So maybe some timing is now exposed in PM / DRM... Woody
[git pull] drm fixes
Christian K?nig wrote: > Am 23.04.2014 23:36, schrieb Woody Suwalski: >> Dave Airlie wrote: >>> On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds >>> wrote: >>>> Dave, mind sending me a pull request for drm fixes? >>>> >>>> There's now at least these two: >>>> >>>> - "drm/radeon/aux: fix hpd assignment for aux bus" >>>> - "drm/radeon: use fixed PPL ref divider if needed" >>>> >>>> that look like fairly fatal regressions when they affect somebody. >>>> >>>> The fact that we already had *two* independent bugs be reported within >>>> days of that last out-of-merge-window pull request makes me very >>>> unhappy with the state of drm pulls. >>>> >>>> So please make sure that future fixes really are *fixes*. For >>>> regressions only. No more games like this. >>> The pll fallout is fixes for the initial feature that was in the >>> merge window, >>> Tuning plls for monitors is always a pain in the ass, the previous >>> algorithm >>> took a couple of kernels a few years back to get where it was, >>> unfortunately >>> HDMI came along and showed up a bunch of its shortcomings. I'm happy >>> Alex and Christian are on top of things in terms of tracking >>> regressions >>> and making sure they get fixed, >>> >>> the AUX fix yes I'm a bit pissed off about myself, but I missed a pull >>> from a few >>> weeks ago, felt guilty, and maybe should have chosen the other path >>> and let it >>> wait a merge, >>> >>> Christian just sent me a -fixes pull with all of these in it and I'll >>> send it on to you >>> in a few mins. >>> >>> Dave. >>> >> That patch also fixes a shimmering (water floating) issue on Radeon >> RV635 (Thinkpad T500) >> 1002:9591 > > Was this a long outstanding bug or a regression introduced with one of > the recent patches? > > Thanks for the info, > Christian. Regression from 3.15-rc1 (still OK in -rc1, shimmering in -rc2) Woody
[git pull] drm fixes
Dave Airlie wrote: > On Wed, Apr 23, 2014 at 1:59 AM, Linus Torvalds > wrote: >> Dave, mind sending me a pull request for drm fixes? >> >> There's now at least these two: >> >> - "drm/radeon/aux: fix hpd assignment for aux bus" >> - "drm/radeon: use fixed PPL ref divider if needed" >> >> that look like fairly fatal regressions when they affect somebody. >> >> The fact that we already had *two* independent bugs be reported within >> days of that last out-of-merge-window pull request makes me very >> unhappy with the state of drm pulls. >> >> So please make sure that future fixes really are *fixes*. For >> regressions only. No more games like this. > The pll fallout is fixes for the initial feature that was in the merge window, > Tuning plls for monitors is always a pain in the ass, the previous algorithm > took a couple of kernels a few years back to get where it was, unfortunately > HDMI came along and showed up a bunch of its shortcomings. I'm happy > Alex and Christian are on top of things in terms of tracking regressions > and making sure they get fixed, > > the AUX fix yes I'm a bit pissed off about myself, but I missed a pull > from a few > weeks ago, felt guilty, and maybe should have chosen the other path and let it > wait a merge, > > Christian just sent me a -fixes pull with all of these in it and I'll > send it on to you > in a few mins. > > Dave. > That patch also fixes a shimmering (water floating) issue on Radeon RV635 (Thinkpad T500) 1002:9591
Re: [PULL] drm-intel-fixes (drm/i915 driver)
Keith Packard wrote: On Thu, 6 Oct 2011 10:12:57 -0700, Linus Torvalds wrote: [drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH Thanks. I've got a patch series that fixes a pile of refclk bugs which is still out for review that should fix this. This error should be harmless, but still.. And what about blanking (black screen) issue reported Sep21? I confirm that disabling the blanking e.g. commenting out /* intel_panel_set_backlight(dev, 0); */ in intel_panel.c is somehow working on EeePC as well as Dell machine. I guess Linus has stopped using EeePCs ;-) Woody ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes (drm/i915 driver)
Keith Packard wrote: > On Thu, 6 Oct 2011 10:12:57 -0700, Linus Torvalds linux-foundation.org> wrote: > >>[drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH > Thanks. I've got a patch series that fixes a pile of refclk bugs which > is still out for review that should fix this. This error should be > harmless, but still.. > And what about blanking (black screen) issue reported Sep21? I confirm that disabling the blanking e.g. commenting out /* intel_panel_set_backlight(dev, 0); */ in intel_panel.c is somehow working on EeePC as well as Dell machine. I guess Linus has stopped using EeePCs ;-) Woody
