- 05 12月, 2015 7 次提交
-
-
由 Mario Kleiner 提交于
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core more fragile to drivers which don't update hw vblank counters and vblank timestamps in sync with firing of the vblank irq and essentially at leading edge of vblank. This exposed a problem with radeon-kms/amdgpu-kms which do not satisfy above requirements: The vblank irq fires a few scanlines before start of vblank, but programmed pageflips complete at start of vblank and vblank timestamps update at start of vblank, whereas the hw vblank counter increments only later, at start of vsync. This leads to problems like off by one errors for vblank counter updates, vblank counters apparently going backwards or vblank timestamps apparently having time going backwards. The net result is stuttering of graphics in games, or little hangs, as well as total failure of timing sensitive applications. See bug #93147 for an example of the regression on Linux 4.4-rc: https://bugs.freedesktop.org/show_bug.cgi?id=93147 This patch tries to align all above events better from the viewpoint of the drm core / of external callers to fix the problem: 1. The apparent start of vblank is shifted a few scanlines earlier, so the vblank irq now always happens after start of this extended vblank interval and thereby drm_update_vblank_count() always samples the updated vblank count and timestamp of the new vblank interval. To achieve this, the reporting of scanout positions by radeon_get_crtc_scanoutpos() now operates as if the vblank starts radeon_crtc->lb_vblank_lead_lines before the real start of the hw vblank interval. This means that the vblank timestamps which are based on these scanout positions will now update at this earlier start of vblank. 2. The driver->get_vblank_counter() function will bump the returned vblank count as read from the hw by +1 if the query happens after the shifted earlier start of the vblank, but before the real hw increment at start of vsync, so the counter appears to increment at start of vblank in sync with the timestamp update. 3. Calls from vblank irq-context and regular non-irq calls are now treated identical, always simulating the shifted vblank start, to avoid inconsistent results for queries happening from vblank irq vs. happening from drm_vblank_enable() or vblank_disable_fn(). 4. The radeon_flip_work_func will delay mmio programming a pageflip until the start of the real vblank iff it happens to execute inside the shifted earlier start of the vblank, so pageflips now also appear to execute at start of the shifted vblank, in sync with vblank counter and timestamp updates. This to avoid some races between updates of vblank count and timestamps that are used for swap scheduling and pageflip execution which could cause pageflips to execute before the scheduled target vblank. The lb_vblank_lead_lines "fudge" value is calculated as the size of the display controllers line buffer in scanlines for the given video mode: Vblank irq's are triggered by the line buffer logic when the line buffer refill for a video frame ends, ie. when the line buffer source read position enters the hw vblank. This means that a vblank irq could fire at most as many scanlines before the current reported scanout position of the crtc timing generator as the number of scanlines the line buffer can maximally hold for a given video mode. This patch has been successfully tested on a RV730 card with DCE-3 display engine and on a evergreen card with DCE-4 display engine, in single-display and dual-display configuration, with different video modes. A similar patch is needed for amdgpu-kms to fix the same problem. Limitations: - Line buffer sizes in pixels are hard-coded on < DCE-4 to a value i just guessed to be high enough to work ok, lacking info on the true sizes atm. Fixes: fdo#93147 Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Tested-by: Dave Witbrodt <dawitbro@sbcglobal.net> (v2) Refine radeon_flip_work_func() for better efficiency: In radeon_flip_work_func, replace the busy waiting udelay(5) with event lock held by a more performance and energy efficient usleep_range() until at least predicted true start of hw vblank, with some slack for scheduler happiness. Release the event lock during waits to not delay other outputs in doing their stuff, as the waiting can last up to 200 usecs in some cases. Retested on DCE-3 and DCE-4 to verify it still works nicely. (v2) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lyude 提交于
HPD signals on DVI ports can be fired off before the pins required for DDC probing actually make contact, due to the pins for HPD making contact first. This results in a HPD signal being asserted but DDC probing failing, resulting in hotplugging occasionally failing. This is somewhat rare on most cards (depending on what angle you plug the DVI connector in), but on some cards it happens constantly. The Radeon R5 on the machine used for testing this patch for instance, runs into this issue just about every time I try to hotplug a DVI monitor and as a result hotplugging almost never works. Rescheduling the hotplug work for a second when we run into an HPD signal with a failing DDC probe usually gives enough time for the rest of the connector's pins to make contact, and fixes this issue. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NLyude <cpaul@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 jimqu 提交于
there is a protection fault about freed list when OCL test. add a spin lock to protect it. v2: drop changes in vm_fini Signed-off-by: NJimQu <jim.qu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Christian König 提交于
The gtt_end is already inclusive, we don't need to subtract one here. v2 (chk): keep the fix for the VM code, cause here it really applies. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAnatoli Antonovitch <anatoli.antonovitch@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
No need for a GEM reference here. Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
No need for the GEM reference here. Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Not necessary for VRAM. v2: no need to check if ttm is NULL. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 03 12月, 2015 2 次提交
-
-
由 Nicolai Hähnle 提交于
As soon as we leave the spinlock after the job has been added to the job queue, we can no longer rely on the job's data to be available. I have seen a null-pointer dereference due to sched == NULL in amd_sched_wakeup via amd_sched_entity_push_job and amd_sched_ib_submit_kernel_helper. Since the latter initializes sched_job->sched with the address of the ring scheduler, which is guaranteed to be non-NULL, this race appears to be a likely culprit. Signed-off-by: NNicolai Hähnle <nicolai.haehnle@amd.com> Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=93079Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Missing error check if the operation failed. Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
- 01 12月, 2015 3 次提交
-
-
由 Pavel Machek 提交于
Thinkpad T40p needs agpmode 1. Signed-off-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
We use the reservation object of the page directory for the page tables as well, because of this the page directory should be freed last. Ensure that by keeping a reference from the page tables to the directory. Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
That got messed up while porting it from Radeon. Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NChristian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 26 11月, 2015 1 次提交
-
-
由 Alex Deucher 提交于
"Could not force DPM to low", etc. is usually harmless and just confuses users. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 25 11月, 2015 11 次提交
-
-
由 Martin Peres 提交于
Reported-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NMartin Peres <martin.peres@free.fr>
-
由 Ben Skeggs 提交于
Regression from "abi16: implement limited interoperability with usif/nvif". Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Somehow missed these two when removing dodgy void casts during the rework. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
fdo#92761 Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Each GPCCS unit was reading the mask from GPC0, which causes problems on boards where some GPCs are missing PPCs. Part of the fix for fdo#92761. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
There's a few places where we need to access a GPC register from ucode, but outside of the falcon's io address space. To do this we need to calculate the offset based on which GPC we're executing on. This used to be done manually, but we've since found a "base" offset that can be added by the hardware. To use this, an extra bit needs to be set in the register address, which is what this macro achieves. There should be no functional change from this commit. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes detection of a failed attempt at fetching the entire ROM image in one-shot (a violation of the spec, that works a lot of the time). Tested on a HP Zbook 15 G2. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
No locking is required for the traversal of this list, as it only happens during suspend/resume where nothing else can be executing. Fixes some of the issues noticed during parallel piglit runs. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
fdo#70354 - comment #88. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Karol Herbst 提交于
this is needed for my gpu Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alex Deucher 提交于
On some cards it takes a relatively long time for the change to take place. Make a timeout non-fatal. bug: https://bugs.freedesktop.org/show_bug.cgi?id=76130Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 24 11月, 2015 2 次提交
-
-
由 Christian König 提交于
This way the driver isn't limited in the dependency handling callback. v2: remove extra check in amd_sched_entity_pop_job() Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
由 Christian König 提交于
We only need to wait for jobs to be scheduled when the dependency is from the same scheduler. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <david1.zhou@amd.com>
-
- 21 11月, 2015 5 次提交
-
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Leo Liu 提交于
Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Leo Liu 提交于
Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Leo Liu 提交于
Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 19 11月, 2015 9 次提交
-
-
由 Daniel Vetter 提交于
This was totally lost when I originally created the atomic helpers. We probably should also check possible_clones in the helpers, but since the legacy ones didn't do that this is for a separate patch. Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Stone <daniels@collabora.com> Reviewed-by: NDaniel Stone <daniels@collabora.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447868808-10266-1-git-send-email-daniel.vetter@ffwll.ch
-
由 Jani Nikula 提交于
This reverts commit 6764e9f8 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Thu Aug 27 15:44:06 2015 +0200 drm/i915: skip modeset if compatible for everyone. Bring back the i915.fastboot module parameter, disabled by default, due to backlight regression on Chromebook Pixel 2015. Apparently the firmware of the Chromebook in question enables the panel but disables backlight to avoid a brief garbage scanout upon loading the kernel/module. With fastboot, we leave the backlight untouched, in this case disabled. The user would have to do a modeset (i.e. not just crank up the brightness) to enable the backlight. There is no clean fix readily available, so get back to the drawing board by reverting. [N.B. The reference below is for when the thread was included on public lists, and some of the context had already been dropped by then.] Reported-and-tested-by: NOlof Johansson <olof@lixom.net> Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> References: http://marc.info/?i=CAKMK7uES7xk05ki92oeX6gmvZWAh9f2vL7yz=6T+fGK9J3X7cQ@mail.gmail.com Fixes: 6764e9f8 ("drm/i915: skip modeset if compatible for everyone.") Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447921590-3785-1-git-send-email-jani.nikula@intel.com
-
由 Wang, Rui Y 提交于
The machine hang completely with the following message on the console: [ 487.777538] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 487.777554] IP: [<ffffffff8158aaee>] _raw_spin_lock+0xe/0x30 [ 487.777557] PGD 42e9f7067 PUD 42f2fa067 PMD 0 [ 487.777560] Oops: 0002 [#1] SMP ... [ 487.777618] CPU: 21 PID: 3190 Comm: Xorg Tainted: G E 4.4.0-rc1-3-default+ #6 [ 487.777620] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS BRHSXSD1.86B.0059.R00.1501081238 01/08/2015 [ 487.777621] task: ffff880853ae4680 ti: ffff8808696d4000 task.ti: ffff8808696d4000 [ 487.777625] RIP: 0010:[<ffffffff8158aaee>] [<ffffffff8158aaee>] _raw_spin_lock+0xe/0x30 [ 487.777627] RSP: 0018:ffff8808696d79c0 EFLAGS: 00010246 [ 487.777628] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 487.777629] RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000060 [ 487.777630] RBP: ffff8808696d79e0 R08: 0000000000000000 R09: ffff88086924a780 [ 487.777631] R10: 000000000001bb40 R11: 0000000000003246 R12: 0000000000000000 [ 487.777632] R13: ffff880463a27360 R14: ffff88046ca50218 R15: 0000000000000080 [ 487.777634] FS: 00007f3f81c5a8c0(0000) GS:ffff88086f060000(0000) knlGS:0000000000000000 [ 487.777635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 487.777636] CR2: 0000000000000060 CR3: 000000042e678000 CR4: 00000000001406e0 [ 487.777638] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 487.777639] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 487.777639] Stack: [ 487.777642] ffffffffa00eb5fa ffff8808696d7b60 ffff88086b87d800 0000000000000000 [ 487.777644] ffff8808696d7ac8 ffffffffa01694b6 ffff8808696d7ae8 ffffffff8109c8d5 [ 487.777647] ffff880469158740 ffff880463a27000 ffff88086b87d800 ffff88086b87d800 [ 487.777647] Call Trace: [ 487.777674] [<ffffffffa00eb5fa>] ? drm_gem_object_lookup+0x1a/0xa0 [drm] [ 487.777681] [<ffffffffa01694b6>] mga_crtc_cursor_set+0xc6/0xb60 [mgag200] [ 487.777691] [<ffffffff8109c8d5>] ? find_busiest_group+0x35/0x4a0 [ 487.777696] [<ffffffff81086294>] ? __might_sleep+0x44/0x80 [ 487.777699] [<ffffffff815888c2>] ? __ww_mutex_lock+0x22/0x9c [ 487.777722] [<ffffffffa0104f64>] ? drm_modeset_lock+0x34/0xf0 [drm] [ 487.777733] [<ffffffffa0148d9e>] restore_fbdev_mode+0xee/0x2a0 [drm_kms_helper] [ 487.777742] [<ffffffffa014afce>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70 [drm_kms_helper] [ 487.777748] [<ffffffffa014b037>] drm_fb_helper_set_par+0x27/0x50 [drm_kms_helper] [ 487.777752] [<ffffffff8134560c>] fb_set_var+0x18c/0x3f0 [ 487.777777] [<ffffffffa02a9b0a>] ? __ext4_handle_dirty_metadata+0x8a/0x210 [ext4] [ 487.777783] [<ffffffff8133cb97>] fbcon_blank+0x1b7/0x2b0 [ 487.777790] [<ffffffff813be2a3>] do_unblank_screen+0xb3/0x1c0 [ 487.777795] [<ffffffff813b5aba>] vt_ioctl+0x118a/0x1210 [ 487.777801] [<ffffffff813a8fe0>] tty_ioctl+0x3f0/0xc90 [ 487.777808] [<ffffffff81172018>] ? kzfree+0x28/0x30 [ 487.777813] [<ffffffff811e053f>] ? mntput+0x1f/0x30 [ 487.777817] [<ffffffff811d3f5d>] do_vfs_ioctl+0x30d/0x570 [ 487.777822] [<ffffffff8107ed3a>] ? task_work_run+0x8a/0xa0 [ 487.777825] [<ffffffff811d4234>] SyS_ioctl+0x74/0x80 [ 487.777829] [<ffffffff8158aeae>] entry_SYSCALL_64_fastpath+0x12/0x71 [ 487.777851] Code: 65 ff 0d ce 02 a8 7e 5d c3 ba 01 00 00 00 f0 0f b1 17 85 c0 75 e8 b0 01 5d c3 0f 1f 00 65 ff 05 b1 02 a8 7e 31 c0 ba 01 00 00 00 <f0> 0f b1 17 85 c0 75 01 c3 55 89 c6 48 89 e5 e8 4e f5 b1 ff 5d [ 487.777854] RIP [<ffffffff8158aaee>] _raw_spin_lock+0xe/0x30 [ 487.777855] RSP <ffff8808696d79c0> [ 487.777856] CR2: 0000000000000060 [ 487.777860] ---[ end trace 672a2cd555e0ebd3 ]--- The cursor code may be entered with file_priv == NULL && handle == NULL. The problem was introduced by: "bf89209a drm/mga200g: Hold a proper reference for cursor_set" which calls drm_gem_object_lookup(dev, file_priv...). Previously this wasn't a problem because we checked the handle. Move the check early in the function can fix the problem. Signed-off-by: NRui Wang <rui.y.wang@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Chunming Zhou 提交于
Change-Id: Id6514f2fb6e002437fdbe99353d5d35f4ac736c7 Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Change-Id: Ifbb0c06680494bfa04d0be5e5941d31ae2e5ef28 Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Chunming Zhou 提交于
Change-Id: I62b892a22af37b32e6b4aefca80a25cf45426ed2 Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Christian König 提交于
We don't need the last VM use any more, keep the owner directly. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <davdi1.zhou@amd.com>
-
由 Christian König 提交于
It's not a good idea to duplicate that code. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <davdi1.zhou@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Fix the indentation and move the VM functions to the structures. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NChunming Zhou <davdi1.zhou@amd.com> Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-