[pull] radeon drm-fixes-3.19
Hi Dave, Some radeon fixes for 3.19: - GPUVM stability fixes - SI dpm quirks - Regression fixes The following changes since commit 79305ec6e60d320832505e95c1a028d309fcd2b6: Merge tag 'amdkfd-fixes-2015-01-06' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes (2015-01-08 10:36:37 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.19 for you to fetch changes up to d8a74e186949e1a2c2f1309212478b0659bf9225: drm/radeon: use rv515_ring_start on r5xx (2015-01-15 11:11:02 -0500) Alex Deucher (6): drm/radeon: fix VM flush on cayman/aruba (v3) drm/radeon: fix VM flush on SI (v3) drm/radeon: fix VM flush on CIK (v3) drm/radeon: add a dpm quirk list drm/radeon: add si dpm quirk list drm/radeon: use rv515_ring_start on r5xx Christian König (1): drm/radeon: don't print error on -ERESTARTSYS drivers/gpu/drm/radeon/cik.c | 11 ++ drivers/gpu/drm/radeon/cik_sdma.c| 10 + drivers/gpu/drm/radeon/ni.c | 10 + drivers/gpu/drm/radeon/ni_dma.c | 6 ++ drivers/gpu/drm/radeon/nid.h | 24 ++ drivers/gpu/drm/radeon/radeon_asic.c | 18 +++-- drivers/gpu/drm/radeon/radeon_gem.c | 2 +- drivers/gpu/drm/radeon/radeon_pm.c | 33 ++ drivers/gpu/drm/radeon/si.c | 10 + drivers/gpu/drm/radeon/si_dma.c | 8 drivers/gpu/drm/radeon/si_dpm.c | 39 drivers/gpu/drm/radeon/sid.h | 18 + 12 files changed, 186 insertions(+), 3 deletions(-)
[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=88183 --- Comment #7 from smoki --- Game works fine for me if i disable texture compression in options. BTW, they have disabled compression for any intel driver, that might mean this is not only radeonsi driver issue: https://github.com/supertuxkart/stk-code/blob/master/data/graphical_restrictions.xml -- 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/20150115/a06c1eeb/attachment.html>
[RESEND PATCH] qxl: catch qxlfb_create_pinned_object failures
Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_fb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c index 3d7c1d0..18ef31a 100644 --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c @@ -521,6 +521,9 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev, mode_cmd.pixel_format = drm_mode_legacy_fb_format(bpp, depth); ret = qxlfb_create_pinned_object(qfbdev, &mode_cmd, &gobj); + if (ret < 0) + return ret; + qbo = gem_to_qxl_bo(gobj); QXL_INFO(qdev, "%s: %dx%d %d\n", __func__, mode_cmd.width, mode_cmd.height, mode_cmd.pitches[0]); -- 1.8.3.1
[Bug 88408] Black screen in Nuclear Dawn
centroid mask (0x00E0) differs from mask derived from shader name (0x00C0) for shader ps-file water_ps20b ps-index 1272 ps-combo 1 IDirect3DDevice9::CreatePixelShader: shaderapi's centroid mask (0x00E0) differs from mask derived from shader name (0x00C0) for shader ps-file water_ps20b ps-index 20 ps-combo 0 IDirect3DDevice9::CreatePixelShadeInstalling breakpad exception handler for appid(gameoverlayui)/version(1.0) Installing breakpad exception handler for appid(steam)/version(1421286787) Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 70: non-double matrix element Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 78: saw unknown, expected number Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(nd_linux)/version(1.0) Looking up breakpad interfaces from steamclient Calling BreakpadMiniDumpSystemInit Steam_SetMinidumpSteamID: Caching Steam ID: 7656119703242 [API loaded yes] Steam_SetMinidumpSteamID: Setting Steam ID: 7656119703242 Game update: AppID 17710 "Nuclear Dawn", ProcID 20999, IP 127.0.0.1:27015 Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) warning: Unknown nb_ctl request: 4 warning: Unknown nb_ctl request: 4 warning: Unknown nb_ctl request: 4 warning: Unknown nb_ctl request: 4 warning: Unknown nb_ctl request: 4 warning: Unknown nb_ctl request: 4 Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(gameoverlayui)/version(1.0) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Game removed: AppID 17710 "Nuclear Dawn", ProcID 20999 Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) Generating new string page texture 182: 128x256, total string texture memory is 3,92 MB Installing breakpad exception handler for appid(steam)/version(1421286787) Installing breakpad exception handler for appid(steam)/version(1421286787) process 20855: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details. Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection. Requested Force create but SharedObjectMutex already created Forced create but already created for SharedObjectEvent Forced create but already created for SharedObjectEvent [2015-01-15 23:13:30] Startup - updater built Jan 14 2015 17:18:52 [2015-01-15 23:13:30] Opted in to client beta 'publicbeta' via beta file You are in the 'publicbeta' client beta. [2015-01-15 23:13:30] Verifying installation... [2015-01-15 23:13:30] Verification complete [2015-01-15 23:17:37] Shutdown -- 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/20150115/e4b08368/attachment-0001.html>
[RESEND PATCH] bochs: ignore device if there isn't enougth memory
The qemu stdvga can be configured with a wide range of video memory,
from 1 MB to 256 MB (default is 16 MB). In case it is configured
with only 1 or 2 MB it isn't really usable with bochsdrm, due to
depths other than 32bpp not being supported so that isn't enough
memory for a reasonable sized framebuffer. So skip the device
and let vgacon or vesafb+fbcon handle the it.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_drv.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index 98837bd..9874d4a 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -162,8 +162,15 @@ static int bochs_kick_out_firmware_fb(struct pci_dev *pdev)
static int bochs_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
+ unsigned long fbsize;
int ret;
+ fbsize = pci_resource_len(pdev, 0);
+ if (fbsize < 4 * 1024 * 1024) {
+ DRM_ERROR("less than 4 MB video memory, ignoring device\n");
+ return -ENOMEM;
+ }
+
ret = bochs_kick_out_firmware_fb(pdev);
if (ret)
return ret;
--
1.8.3.1
[Bug 88301] Dota causes GPU fault and kernel hang
https://bugs.freedesktop.org/show_bug.cgi?id=88301 --- Comment #3 from smoki --- I can reproduce this on Kabini with current proper mesa and llvm, but not with Tom's perf-Jan-08-2015 llvm + vgpr-spilling-Jan07-2014 mesa branches it works fine there. -- 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/20150115/3e2ce992/attachment.html>
[Bug 88461] The computer sometimes freezes after waking up when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88461 --- Comment #3 from Andrew --- Created attachment 112317 --> https://bugs.freedesktop.org/attachment.cgi?id=112317&action=edit freeze dmesg log for linux 3.18 -- 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/20150115/786dd89b/attachment.html>
[Bug 88459] Сomputer is not in sleep mode when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88459 --- Comment #4 from Andrew --- I switched to the core of 3.18 and sleep is working correctly. -- 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/20150115/e0f9b146/attachment-0001.html>
[Bug 88301] Dota causes GPU fault and kernel hang
https://bugs.freedesktop.org/show_bug.cgi?id=88301 --- Comment #2 from Tilman Sauerbeck --- Sorry about that misinformation. It's not a hang at all since I'm still able to use sysrq to reboot. What's happening after the GPU faults is that apparently the driver attempts to get the card back into working shape, but fails to do so. X doesn't become usable again after the GPU faults anyway. Here's the kernel log following the GPU faults: radeon :01:00.0: ring 0 stalled for more than 10428msec radeon :01:00.0: GPU lockup (current fence id 0x00107f5c last fence id 0x001080f7 on ring 0) radeon :01:00.0: failed to get a new IB (-35) [drm:radeon_cs_ib_fill] *ERROR* Failed to get ib ! radeon :01:00.0: Saved 7977 dwords of commands on ring 0. radeon :01:00.0: GPU softreset: 0x0009 [snipped list of registers that were reset (I think)] [drm] probing gen 2 caps for device 1002:5a16 = 31cd02/0 [drm] PCIE gen 2 link speeds already enabled [drm] PCIE GART of 1024M enabled (table at 0x0078C000). radeon :01:00.0: WB enabled radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x8800bac4cc00 radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x8800bac4cc04 radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x8800bac4cc08 radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x8800bac4cc0c radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x8800bac4cc10 radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00076c98 and cpu addr 0xc90010c36c98 radeon :01:00.0: fence driver on ring 6 use gpu addr 0x8c18 and cpu addr 0x8800bac4cc18 radeon :01:00.0: fence driver on ring 7 use gpu addr 0x8c1c and cpu addr 0x8800bac4cc1c [drm] ring test on 0 succeeded in 3 usecs [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed (scratch(0x3010C)=0xCAFEDEAD) [drm:cik_ring_test] *ERROR* radeon: ring 2 test failed (scratch(0x3010C)=0xCAFEDEAD) [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) [drm:cik_resume] *ERROR* cik startup failed on resume [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed -- 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/20150115/8758441f/attachment.html>
[Bug 88459] Сomputer is not in sleep mode when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88459 --- Comment #3 from Lorenzo Bona --- I can't reproduce this issue. I'm using a self compiled kernel from linus's git and graphical stuff too (mesa, ddx, xorg, drm). I've played a video on mpv, using vdpau as hwdec, and it goes to sleep and I can resume it without any issue. I've checked dmesg and I can't see any warning or error. -- 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/20150115/9d0ce915/attachment.html>
[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3)
https://bugs.freedesktop.org/show_bug.cgi?id=86720 --- Comment #10 from Felix Schwarz --- I can confirm that the issue was introduced (on master) with this commit: commit 6fcb5520b78cdf1e5013c125501932315a069955 Author: Marek Olšák Date: Tue Oct 28 19:49:44 2014 +0100 Revert "st/mesa: set MaxUnrollIterations = 255" This reverts commit 20836c81851e0df29a8ee9c86e5e5388738c840b. 255 is a huge number. If you have a loop with 255 iterations, unrolling it will exceed the SM3 instruction limit. Let's use the default again. The comment about a SM3 limit doesn't make sense. For SM3, we generally want 32 (default) or a lower number due to the SM3 instruction limit, which is 512 instructions. For SM4, we can try higher numbers if needed, but some shaders can end up being pretty huge and shader compilation can take more time. This fixes a shader compile failure on R500/SM3. Reported on IRC. Cc: 10.2 10.3 Reviewed-by: Brian Paul Marek: You mentioned that the r600 driver might be unable to handle certain loops. Is there anything the community can do to get this fixed? apitrace? Checking for piglit regressions related to the mentioned commit? I assume that you would be able to fix this much better if you could reproduce the problem easily. -- 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/20150115/ecc1d1e2/attachment.html>
[Bug 91371] UVD not responding error during UVD initialization for AMD 7670M graphics
https://bugzilla.kernel.org/show_bug.cgi?id=91371 --- Comment #1 from Arun George --- Created attachment 163561 --> https://bugzilla.kernel.org/attachment.cgi?id=163561&action=edit xorg log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 91371] New: UVD not responding error during UVD initialization for AMD 7670M graphics
https://bugzilla.kernel.org/show_bug.cgi?id=91371 Bug ID: 91371 Summary: UVD not responding error during UVD initialization for AMD 7670M graphics Product: Drivers Version: 2.5 Kernel Version: 3.16 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: arugeo1 at gmail.com Regression: No Created attachment 163551 --> https://bugzilla.kernel.org/attachment.cgi?id=163551&action=edit dmesg My Linux Kernel version is 3.16.7 .My System is a HP Pavillion g6 laptop with AMD A8-4500M APU with 7640G + 7670M Dual Graphics.On booting Manjaro (and Ubuntu) distro i get these errors and display blinks before and after showing them. [ 26.971983] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 27.992402] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 29.012898] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 30.033439] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 31.053953] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 32.074424] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 33.094895] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 34.115369] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 35.135841] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 36.156319] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 36.176381] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! [ 36.176432] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). [ 37.611579] [drm:radeon_acpi_init] *ERROR* Cannot find a backlight controller I found some cards reported having these errors earlier in 3.13 kernel but it was found to be fixed in 3.15 (dont know if this is a reccurence of that bug). The UVD initialization for integrated card seems to be fine while UVD fails for Dedicated card.Currently the problems faced due to this are that booting succeeds randomly(sometimes it gives a black screen sometimes it gets stuck before login screen) and when it does the booting time is high. It also shows these errors during shutdown.I tried to turn off dpm ,but that gave me a blank screen(and not able to load X).I tried other kernels and it persists in 3.17 and 3.18 kernels. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 4/6] drm/plane-helper: Fix transitional helper kerneldocs
drm_plane_helper_{update,disable} are not specific to primary planes;
fix some copy/paste summaries to avoid confusion.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 1b1e927..3e7e26f 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -484,7 +484,7 @@ out:
}
/**
- * drm_plane_helper_update() - Helper for primary plane update
+ * drm_plane_helper_update() - Transitional helper for plane update
* @plane: plane object to update
* @crtc: owning CRTC of owning plane
* @fb: framebuffer to flip onto plane
@@ -541,7 +541,7 @@ int drm_plane_helper_update(struct drm_plane *plane, struct
drm_crtc *crtc,
EXPORT_SYMBOL(drm_plane_helper_update);
/**
- * drm_plane_helper_disable() - Helper for primary plane disable
+ * drm_plane_helper_disable() - Transitional helper for plane disable
* @plane: plane to disable
*
* Provides a default plane disable handler using the atomic plane update
--
1.8.5.1
[PATCH 3/6] drm/plane-helper: Add transitional helper for .set_plane().
Add a transitional helper for planes' .set_property() entrypoint,
similar to what we already have for .update_plane() and
.disable_plane(). This allows drivers that are still in the process of
transitioning to implement and exercise the .atomic_set_property()
driver entrypoint that will eventually be used by atomic.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 105 +
include/drm/drm_plane_helper.h | 3 ++
2 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index f24c4cf..1b1e927 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -578,3 +578,108 @@ int drm_plane_helper_disable(struct drm_plane *plane)
return drm_plane_helper_commit(plane, plane_state, plane->fb);
}
EXPORT_SYMBOL(drm_plane_helper_disable);
+
+/**
+ * drm_plane_helper_set_property() - Transitional helper for property updates
+ * @plane: plane object to update
+ * @prop: property to update
+ * @val: value to set property to
+ *
+ * Provides a default plane property handler using the atomic plane update
+ * functions. Drivers in the process of transitioning to atomic should
+ * replace their plane.set_property() entrypoint with this function and
+ * then implement the plane.atomic_set_property() entrypoint.
+ *
+ * This is useful for piecewise transitioning of a driver to the atomic
helpers.
+ *
+ * Note that this helper assumes that no hardware programming should be
+ * performed if the plane is disabled. When the plane is not attached to a
+ * crtc, we just swap in the validated plane state and return; there's no
+ * call to atomic_begin()/atomic_update()/atomic_flush().
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_plane_helper_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct drm_plane_state *plane_state;
+ struct drm_plane_helper_funcs *plane_funcs = plane->helper_private;
+ struct drm_crtc_helper_funcs *crtc_funcs;
+ int ret;
+
+ /*
+* Drivers may not have an .atomic_set_property() handler if they have
+* no driver-specific properties, but they generally wouldn't setup a
+* .set_property() handler (pointing to this function) for the plane in
+* that case either; throw a warning since this is probably a mistake.
+*/
+ if (WARN_ON(!plane->funcs->atomic_set_property))
+ return -EINVAL;
+
+ if (plane->funcs->atomic_duplicate_state)
+ plane_state = plane->funcs->atomic_duplicate_state(plane);
+ else if (plane->state)
+ plane_state = drm_atomic_helper_plane_duplicate_state(plane);
+ else
+ plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
+ if (!plane_state)
+ return -ENOMEM;
+ plane_state->plane = plane;
+
+ /*
+* Update the state object with the new property value we want to
+* set. If the property is not recognized as a driver-specific
property,
+* -EINVAL will be returned here.
+*/
+ ret = plane->funcs->atomic_set_property(plane, plane_state, prop, val);
+ if (ret)
+ goto out;
+
+ /*
+* Check that the updated plane state is actually programmable (e.g.,
+* doesn't violate hardware constraints).
+*/
+ if (plane_funcs->atomic_check) {
+ ret = plane_funcs->atomic_check(plane, plane_state);
+ if (ret)
+ goto out;
+ }
+
+ /* Point of no return, commit sw state. */
+ swap(plane->state, plane_state);
+
+ /*
+* If the plane is disabled, we're done. No hardware programming is
+* attempted when the plane is disabled.
+*/
+ if (!plane->crtc)
+ goto out;
+
+ /* Start hardware transaction to commit new state to hardware */
+ crtc_funcs = plane->crtc->helper_private;
+ if (crtc_funcs && crtc_funcs->atomic_begin)
+ crtc_funcs->atomic_begin(plane->crtc);
+ plane_funcs->atomic_update(plane, plane_state);
+ if (crtc_funcs && crtc_funcs->atomic_flush)
+ crtc_funcs->atomic_flush(plane->crtc);
+
+ /*
+* Since we're not using full atomic yet, we still need to update the
shadow
+* property value that's managed by the DRM core since that's where the
+* property values will be read back from.
+*/
+ drm_object_property_set_value(&plane->base, prop, val);
+
+out:
+ if (plane_state) {
+ if (plane->funcs->atomic_destroy_state)
+ plane->funcs->atomic_destroy_state(plane, plane_state);
+ else
+ drm_atomic_helper_plane_destroy_state(plane
[PATCH 0/6] i915 atomic properties
I had hoped to make this a full "nuclear pageflip" enablement series, but I
didn't have as much time to work on this today as I hoped, so I still need to
finish up the final integration with the DRM core atomic code. Several of my
early patches are working and relatively straightforward, so I figured I'd post
these as a preliminary patchset; hopefully I'll have the rest of the patches
necessary to expose "nuclear pageflip" (i.e., single-crtc, plane-only updates)
ready in the next day or so.
This series does add (and then use) a transitional helper for planes'
.set_property() handler, similar to what we have for .update_plane() and
.disable_plane(). The transitional helper can be used by drivers that are
starting to implement the atomic driver entrypoints, but aren't ready to switch
over to full atomic functionality yet.
Note that the i915-specific patches here depend on Ander's recent series which
hasn't been merged yet:
[PATCH 0/7] Make drm_crtc->state match pipe_config
Cc: dri-devel at lists.freedesktop.org
Matt Roper (6):
drm/i915: Move rotation from intel_plane to intel_plane_state
drm/i915: Consolidate plane handler vtables
drm/plane-helper: Add transitional helper for .set_plane().
drm/plane-helper: Fix transitional helper kerneldocs
drm/i915: Add .atomic_{get,set}_property() entrypoints to planes
drm/i915: Replace intel_set_property() with transitional helper
drivers/gpu/drm/drm_plane_helper.c| 109 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 84 +--
drivers/gpu/drm/i915/intel_display.c | 63 ++---
drivers/gpu/drm/i915/intel_drv.h | 22 --
drivers/gpu/drm/i915/intel_fbc.c | 4 +-
drivers/gpu/drm/i915/intel_sprite.c | 65 ++
include/drm/drm_plane_helper.h| 3 +
7 files changed, 268 insertions(+), 82 deletions(-)
--
1.8.5.1
Softlockup on boot with Cape Verde XT on many kernels
It works. - I applied the patch (manually), - recompiled Ubuntu 14.04's kernel 3.13.0-44-generic AMD64, - uninstalled Catalyst, - and removed nomodeset kernel parameter from grub. Ubuntu says I'm running Gallium 0.4 on AMD CAPE VERDE sudo lshw -c video [sudo] password for fede: *-display descripción: VGA compatible controller producto: Cape Verde XT [Radeon HD 7770/8760 / R7 250X] fabricante: Advanced Micro Devices, Inc. [AMD/ATI] id fÃsico: 0 información del bus: pci at :01:00.0 versión: 00 anchura: 64 bits reloj: 33MHz capacidades: pm pciexpress msi vga_controller bus_master cap_list rom configuración: driver=radeon latency=0 recursos: irq:50 memoria:d000-dfff memoria:fde8-fdeb ioport:ee00(size=256) memoria:fde0-fde1 It's working fine AFAIK. I player a few 1080 videos full screen, played duke nukem3d. Unity desktop seems fine. Here are some logs in case you want to see anything there. Xorg.log: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299507/+files/Xorg.0.log dmesg: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299508/+files/dmesg_working.txt lspci: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4299509/+files/lspci_working.txt I'd love to see this patch pushed everywhere. :-) 2015-01-15 3:21 GMT-03:00 Michel Dänzer : > On 15.01.2015 12:53, Federico wrote: > > How about this? It seems at least related. > > > > https://github.com/alterapraxisptyltd/openatom/issues/1 > > > > Quote: > > [linux] Infinite loop in pci_get_rom_size() > > > > This is one of those issues that you find when putting supposedly stable > > code through unusual situations. I did expect any function in linux that > > is not part of radeon.ko to not be rock solid. Turns out that's not > > really the case. > > > > If we have a PCIR structure with a zero size length, the loop iterating > > through those structure does not advance. It simply does "image += > > readw(pds + 16) * 512;", but if that field is zero we're back analyzing > > the same structure on the next loop. The way to get out of this loop is > > to set bit 7 of the type field. That's what 'last_image' does. If that > > bit is not set, with the above, that's an infinite loop. > > > > Luckily, it doesn't crash the kernel, but it hangs any driver that calls > > the function under said circumstances. No more modprobe -r or unbinding. > > Reboot is needed. No idea why a firmware blob here is treated as trusted > > input. > > That could indeed explain it, does the attached patch help? > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150115/c63a526c/attachment.html>
[PATCH v2 05/11] drm/panel: add support for Samsung LTN140AT29 panel
From: Stéphane Marchesin
This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e95385b..5ee1d2c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -722,6 +722,29 @@ static const struct panel_desc samsung_ltn101nt05 = {
},
};
+static const struct drm_display_mode samsung_ltn140at29_301_mode = {
+ .clock = 76300,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 64,
+ .hsync_end = 1366 + 64 + 48,
+ .htotal = 1366 + 64 + 48 + 128,
+ .vdisplay = 768,
+ .vsync_start = 768 + 2,
+ .vsync_end = 768 + 2 + 5,
+ .vtotal = 768 + 2 + 5 + 17,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc samsung_ltn140at29_301 = {
+ .modes = &samsung_ltn140at29_301_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 320,
+ .height = 187,
+ },
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "auo,b101aw03",
@@ -778,6 +801,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "samsung,ltn101nt05",
.data = &samsung_ltn101nt05,
}, {
+ .compatible = "samsung,ltn140at29-301",
+ .data = &samsung_ltn140at29_301,
+ }, {
/* sentinel */
}
};
--
1.9.3
[PATCH] drm/radeon/rv515: Remove unused function
On Thu, 2015-01-15 at 10:43 -0500, Jerome Glisse wrote:
> This one looks highly suspicious, i need to check, but i would think
> that this function should be use !
Have a look at commit 76a0df859def ("drm/radeon: rework ring function
handling"), which removed the two users of rv515_ring_start.
I don't think Rickard ever included information like that in this
seemingly unending series. I'd guess looking for information like that
might slow things down, but it would aid the reviewers and improve the
overall quality of the series.
> On Wed, Jan 14, 2015 at 4:44 PM, Alex Deucher
> wrote:
> > On Tue, Jan 13, 2015 at 1:55 PM, Rickard Strandqvist
> > wrote:
> >> Remove the function rv515_ring_start() that is not used anywhere.
> >>
> >> This was partially found by using a static code analysis program called
> >> cppcheck.
> >>
> >> Signed-off-by: Rickard Strandqvist >> spectrumdigital.se>
> >
> > Applied. thanks!
> >
> > Alex
> >
> >> ---
> >> drivers/gpu/drm/radeon/radeon_asic.h |1 -
> >> drivers/gpu/drm/radeon/rv515.c | 68
> >> --
> >> 2 files changed, 69 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> >> b/drivers/gpu/drm/radeon/radeon_asic.h
> >> index d8ace5b..52667b3 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> >> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> >> @@ -280,7 +280,6 @@ int rv515_init(struct radeon_device *rdev);
> >> void rv515_fini(struct radeon_device *rdev);
> >> uint32_t rv515_mc_rreg(struct radeon_device *rdev, uint32_t reg);
> >> void rv515_mc_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
> >> -void rv515_ring_start(struct radeon_device *rdev, struct radeon_ring
> >> *ring);
> >> void rv515_bandwidth_update(struct radeon_device *rdev);
> >> int rv515_resume(struct radeon_device *rdev);
> >> int rv515_suspend(struct radeon_device *rdev);
> >> diff --git a/drivers/gpu/drm/radeon/rv515.c
> >> b/drivers/gpu/drm/radeon/rv515.c
> >> index 8a477bf..cb966e6 100644
> >> --- a/drivers/gpu/drm/radeon/rv515.c
> >> +++ b/drivers/gpu/drm/radeon/rv515.c
> >> @@ -59,74 +59,6 @@ void rv515_debugfs(struct radeon_device *rdev)
> >> }
> >> }
> >>
> >> -void rv515_ring_start(struct radeon_device *rdev, struct radeon_ring
> >> *ring)
> >> -{
> >> - int r;
> >> -
> >> - r = radeon_ring_lock(rdev, ring, 64);
> >> - if (r) {
> >> - return;
> >> - }
> >> - radeon_ring_write(ring, PACKET0(ISYNC_CNTL, 0));
> >> - radeon_ring_write(ring,
> >> - ISYNC_ANY2D_IDLE3D |
> >> - ISYNC_ANY3D_IDLE2D |
> >> - ISYNC_WAIT_IDLEGUI |
> >> - ISYNC_CPSCRATCH_IDLEGUI);
> >> - radeon_ring_write(ring, PACKET0(WAIT_UNTIL, 0));
> >> - radeon_ring_write(ring, WAIT_2D_IDLECLEAN | WAIT_3D_IDLECLEAN);
> >> - radeon_ring_write(ring, PACKET0(R300_DST_PIPE_CONFIG, 0));
> >> - radeon_ring_write(ring, R300_PIPE_AUTO_CONFIG);
> >> - radeon_ring_write(ring, PACKET0(GB_SELECT, 0));
> >> - radeon_ring_write(ring, 0);
> >> - radeon_ring_write(ring, PACKET0(GB_ENABLE, 0));
> >> - radeon_ring_write(ring, 0);
> >> - radeon_ring_write(ring, PACKET0(R500_SU_REG_DEST, 0));
> >> - radeon_ring_write(ring, (1 << rdev->num_gb_pipes) - 1);
> >> - radeon_ring_write(ring, PACKET0(VAP_INDEX_OFFSET, 0));
> >> - radeon_ring_write(ring, 0);
> >> - radeon_ring_write(ring, PACKET0(RB3D_DSTCACHE_CTLSTAT, 0));
> >> - radeon_ring_write(ring, RB3D_DC_FLUSH | RB3D_DC_FREE);
> >> - radeon_ring_write(ring, PACKET0(ZB_ZCACHE_CTLSTAT, 0));
> >> - radeon_ring_write(ring, ZC_FLUSH | ZC_FREE);
> >> - radeon_ring_write(ring, PACKET0(WAIT_UNTIL, 0));
> >> - radeon_ring_write(ring, WAIT_2D_IDLECLEAN | WAIT_3D_IDLECLEAN);
> >> - radeon_ring_write(ring, PACKET0(GB_AA_CONFIG, 0));
> >> - radeon_ring_write(ring, 0);
> >> - radeon_ring_write(ring, PACKET0(RB3D_DSTCACHE_CTLSTAT, 0));
> >> - radeon_ring_write(ring, RB3D_DC_FLUSH | RB3D_DC_FREE);
> >> - radeon_ring_write(ring, PACKET0(ZB_ZCACHE_CTLSTAT, 0));
> >> - radeon_ring_write(ring, ZC_FLUSH | ZC_FREE);
> >> - radeon_ring_write(ring, PACKET0(GB_MSPOS0, 0));
> >> - radeon_ring_write(ring,
> >> - ((6 << MS_X0_SHIFT) |
> >> - (6 << MS_Y0_SHIFT) |
> >> - (6 << MS_X1_SHIFT) |
> >> - (6 << MS_Y1_SHIFT) |
> >> - (6 << MS_X2_SHIFT) |
> >> - (6 << MS_Y2_SHIFT) |
> >> - (6 << MSBD0_Y_SHIFT) |
> >> - (6 << MSBD0_X_SHIFT)));
> >> - radeon_ring_write(ring, PACKET0(GB_MSPOS1, 0));
> >> - radeon_ring_write(ring,
> >> - ((6 << MS_X3_SHIFT) |
> >> - (6 << MS_Y3_SHIFT) |
> >> -
[LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel
On Sun, Jan 4, 2015 at 8:28 PM, Rusty Russell wrote:
> Oded Gabbay writes:
>> On 12/24/2014 01:01 AM, Rusty Russell wrote:
>>> Oded Gabbay writes:
I didn't say it doesn't always work.
The actual thing that doesn't work is the define symbol_get and only in a
specific case of 32bit kernel AND CONFIG_MODULES is unset AND
CONFIG_RANDOMIZE_BASE is set.
The define in that case is:
#define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); })
Why it doesn't work (doesn't return NULL when symbol doesn't exists) ?
>>>
>>> Hmm, I'd guess CONFIG_RANDOMIZE_BASE is relocating NULL symbols...
>>>
>>> No, I can't reproduce this. Please send your .config privately.
>>>
>>> Here's my test case:
>>>
>>> diff --git a/init/main.c b/init/main.c
>>> index 61b993767db5..a3ee1ec97ec3 100644
>>> --- a/init/main.c
>>> +++ b/init/main.c
>>> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>>>
>>> ftrace_init();
>>>
>>> +{
>>> +extern void nonexistent_fn(void);
>>> +printk("symbol_get(nonexistent_fn) = %p\n",
>>> + symbol_get(nonexistent_fn));
>>> +}
>>> +
>>> /* Do the rest non-__init'ed, we're now alive */
>>> rest_init();
>>> }
>>>
>>> Thanks,
>>> Rusty.
>>>
>> Hi Rusty,
>>
>> Attached is the bad config file. (config-bad)
>> I have narrowed the changes you need to do to the config file in order to
>> reproduce this bug.
>> The base assumption is a 32-bit kernel and without modules support. Rest of
>> the
>> config file is pretty standard, IMO.
>> Then, its not enough to enable CONFIG_RANDOMIZE_BASE like I wrote in my
>> original
>> post. You need also to unset CONFIG_HIBERNATION.
>
> Indeed, thanks; your config breaks as reported. With CONFIG_HIBERNATION
> the kernel offset is 0, so we don't see this.
>
> Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
> section for weak symbols. These should not be relocated if already 0.
>
> Put this somewhere to test. It fails for x86_64, too:
>
> diff --git a/init/main.c b/init/main.c
> index 61b993767db5..c9e0195c792a 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>
> ftrace_init();
>
> + {
> + extern void __attribute__((weak)) nonexistent_fn(void);
> + printk("nonexistent_fn = %p\n", nonexistent_fn);
> + BUG_ON(nonexistent_fn != NULL);
> + }
> +
> /* Do the rest non-__init'ed, we're now alive */
> rest_init();
> }
Hm, I can't reproduce this on v3.19-rc4. My nonexistent_fn comes back
NULL regardless of CONFIG and kaslr on/off states I've tried. Could
this be a (yet another) linker bug? What was the toolchain used? I
built with gcc 4.8.2 and binutils 2.24.
-Kees
--
Kees Cook
Chrome OS Security
[PATCH v2] drm/panel: Add support for AUO b101ean01 panel
Hi hl,
On Thu, Jan 15, 2015 at 2:15 PM, huang lin wrote:
> The AUO b101ean01 panel is a 10.1" 1280x800 panel,
> which can be supported by the simple panel driver.
>
> Signed-off-by: huang lin
>
> ---
>
> Changes in v2:
> - changed panel timing
>
> drivers/gpu/drm/panel/panel-simple.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index e95385b..c02f0e6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -392,6 +392,29 @@ static const struct panel_desc auo_b116xw03 = {
> },
> };
>
> +static const struct drm_display_mode auo_b101ean01_mode = {
Perhaps you missed my last review where I suggested moving the
definitions for auo_b101ean01 under auo_b101aw03.
With that change, this patch is
Reviewed-by: Daniel Kurtz
> + .clock = 72500,
> + .hdisplay = 1280,
> + .hsync_start = 1280 + 147,
> + .hsync_end = 1280 + 147 + 32,
> + .htotal = 1280 + 147 + 32 + 21,
> + .vdisplay = 800,
> + .vsync_start = 800 + 4,
> + .vsync_end = 800 + 4 + 4,
> + .vtotal = 800 + 4 + 4 + 8,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc auo_b101ean01 = {
> + .modes = &auo_b101ean01_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> +};
> +
> static const struct drm_display_mode auo_b133xtn01_mode = {
> .clock = 69500,
> .hdisplay = 1366,
> @@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "auo,b101aw03",
> .data = &auo_b101aw03,
> }, {
> + .compatible = "auo,b101ean01",
> + .data = &auo_b101ean01,
> + }, {
> .compatible = "auo,b101xtn01",
> .data = &auo_b101xtn01,
> }, {
> --
> 1.9.1
>
[Bug 88464] booting with radeon.test=1 with radeon3850hd and lockdep validation causes lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=88464 --- Comment #1 from Arthur Marsh --- Created attachment 112304 --> https://bugs.freedesktop.org/attachment.cgi?id=112304&action=edit 20150116radeontest.txt full dmesg output when radeon.test.=1 -- 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/20150115/fb2574fa/attachment.html>
[Bug 88464] booting with radeon.test=1 with radeon3850hd and lockdep validation causes lock-up
https://bugs.freedesktop.org/show_bug.cgi?id=88464 Bug ID: 88464 Summary: booting with radeon.test=1 with radeon3850hd and lockdep validation causes lock-up Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: arthur.marsh at internode.on.net I tried booting with radeon.test=1 Full dmesg 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/20150115/0a72e7f9/attachment.html>
Softlockup on boot with Cape Verde XT on many kernels
On 15.01.2015 12:53, Federico wrote: > How about this? It seems at least related. > > https://github.com/alterapraxisptyltd/openatom/issues/1 > > Quote: > [linux] Infinite loop in pci_get_rom_size() > > This is one of those issues that you find when putting supposedly stable > code through unusual situations. I did expect any function in linux that > is not part of radeon.ko to not be rock solid. Turns out that's not > really the case. > > If we have a PCIR structure with a zero size length, the loop iterating > through those structure does not advance. It simply does "image += > readw(pds + 16) * 512;", but if that field is zero we're back analyzing > the same structure on the next loop. The way to get out of this loop is > to set bit 7 of the type field. That's what 'last_image' does. If that > bit is not set, with the above, that's an infinite loop. > > Luckily, it doesn't crash the kernel, but it hangs any driver that calls > the function under said circumstances. No more modprobe -r or unbinding. > Reboot is needed. No idea why a firmware blob here is treated as trusted > input. That could indeed explain it, does the attached patch help? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- next part -- A non-text attachment was scrubbed... Name: pci_get_rom_size.diff Type: text/x-patch Size: 845 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150115/ea8153f7/attachment.bin>
[Bug 88461] The computer sometimes freezes after waking up when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88461 --- Comment #2 from Andrew --- No. In this bug, the computer freezes when playing vdpau video but in bug 88459, he does not fall asleep if there is opened player with vdpau video. -- 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/20150115/9e987f87/attachment.html>
[Bug 83510] Graphical glitches in Unreal Engine 4
https://bugs.freedesktop.org/show_bug.cgi?id=83510 --- Comment #15 from Daniel Scharrer --- FWIW, Shooter Game, Realistic Rendering Demo and Light Room Interior Day Demo all look fine to me now with a Radeon HD 7950 and recent Mesa and LLVM snapshots. -- 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/20150115/d3a7de39/attachment.html>
[Bug 86663] [radeonsi] Black squares in Sanctum 2
https://bugs.freedesktop.org/show_bug.cgi?id=86663 Daniel Scharrer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Daniel Scharrer --- The Sanctum issue has been fixed with commit http://cgit.freedesktop.org/mesa/mesa/commit/?id=2150db4d5daad3781876254d2b440367afd756cd -- 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/20150115/2e2a5acb/attachment-0001.html>
drm/gma500: oaktrail lvds cleanup fixes
Fixes to allow removal of gma500_gfx module (after frame buffer
console unbind) when used with Atom E6xx gpu chipset.
The oaktrail_lvds_init() uses i2c_adap only to read edid
and therefore it should call i2c_put_adapter() after.
Added the missing call.
The psb_intel_lvds_destroy() is shared for multiple
chipsets cleanup, but there is defined ddc_bus member
in different lower level structures - in case of oaktrail
lvds it is gma_encoder->ddc_bus instead of lvds_priv->ddc_bus.
In case of oaktrail lvds the gma_encoder->ddc_bus was not destroyed.
This patch adds the missing call of psb_intel_i2c_destroy()
and avoids the NULL pointer dereference of lvds_priv which is not
used in case of oaktrail lvds.
Tested on SECO QuadMo747-E6xx-EXTREME Qseven platform.
Signed-off-by: Jan Safrata
Cc: Patrik Jakobsson
---
drivers/gpu/drm/gma500/oaktrail_lvds.c | 4 +++-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 83bbc27..be26846 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -362,8 +362,10 @@ void oaktrail_lvds_init(struct drm_device *dev,
edid = NULL;
mutex_lock(&dev->mode_config.mutex);
i2c_adap = i2c_get_adapter(dev_priv->ops->i2c_bus);
- if (i2c_adap)
+ if (i2c_adap) {
edid = drm_get_edid(connector, i2c_adap);
+ i2c_put_adapter(i2c_adap);
+ }
if (edid == NULL && dev_priv->lpc_gpio_base) {
oaktrail_lvds_i2c_init(encoder);
if (gma_encoder->ddc_bus != NULL) {
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index 88aad95..71bae07 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -561,8 +561,12 @@ void psb_intel_lvds_destroy(struct drm_connector
*connector)
struct gma_encoder *gma_encoder = gma_attached_encoder(connector);
struct psb_intel_lvds_priv *lvds_priv = gma_encoder->dev_priv;
- if (lvds_priv->ddc_bus)
+ if (lvds_priv && lvds_priv->ddc_bus)
psb_intel_i2c_destroy(lvds_priv->ddc_bus);
+ if (gma_encoder->ddc_bus) {
+ psb_intel_i2c_destroy(gma_encoder->ddc_bus);
+ gma_encoder->ddc_bus = NULL;
+ }
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
kfree(connector);
--
1.8.5.5
[PATCH] drm/gma500: add missing drm_irq_uninstall
psb_driver_unload did not call drm_irq_uninstall causing kernel oops in modprobe after rmmod gma500_gfx: BUG: unable to handle kernel paging request at f858cf08 IP: [] strcmp+0x13/0x30 *pdpt = 016ea001 *pde = 36c44067 *pte = Oops: [#1] SMP Modules linked in: gma500_gfx(+) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables eetis_ts ipv6 snd_hda_codec_cirrus option us] CPU: 0 PID: 3648 Comm: modprobe Tainted: G O 3.12.25-acs4+ #4 Hardware name: SECO 0866, BIOS 1.18 03/01/2012 task: f6d07440 ti: f6d54000 task.ti: f6d54000 EIP: 0060:[] EFLAGS: 00010082 CPU: 0 EIP is at strcmp+0x13/0x30 EAX: f851af67 EBX: f4565340 ECX: f6de8cdc EDX: f858cf08 ESI: f851af09 EDI: f858cf08 EBP: f6d55b58 ESP: f6d55b50 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: f858cf08 CR3: 36575000 CR4: 07e0 Stack: f6de8c80 f3913940 f6d55c08 c1071e73 f6d55b6c c1249d5f f6d55b84 f6d55b98 0282 f6de8cdc c15a9f66 00e9 00041f1d 00e9 c170c24c f6d55bb8 c106a42c f7af0b40 f6d07440 f7af31c0 Call Trace: [] register_handler_proc+0x83/0x110 [] ? sprintf+0x1f/0x30 [] ? print_prefix+0x5c/0xb0 [] ? msg_print_text+0xb9/0x170 [] ? wake_up_klogd+0x28/0x30 [] ? console_unlock+0x34d/0x460 [] __setup_irq+0x22c/0x470 [] ? psb_disable_pipestat+0xa0/0xa0 [gma500_gfx] [] request_threaded_irq+0x99/0x120 [] drm_irq_install+0xfc/0x230 [] ? psb_disable_pipestat+0xa0/0xa0 [gma500_gfx] [] gma_power_restore+0x80e/0xa90 [gma500_gfx] [] drm_get_pci_dev+0x102/0x2b0 [] gma_power_restore+0x31d/0xa90 [gma500_gfx] [] pci_device_probe+0x5f/0x90 [] driver_probe_device+0x59/0x200 [] ? pci_match_device+0x96/0xa0 [] __driver_attach+0x89/0x90 [] ? driver_probe_device+0x200/0x200 [] bus_for_each_dev+0x42/0x80 [] driver_attach+0x1a/0x20 [] ? driver_probe_device+0x200/0x200 [] bus_add_driver+0xcc/0x270 [] driver_register+0x55/0xe0 [] ? __wake_up+0x42/0x50 [] __pci_register_driver+0x2e/0x40 [] ? 0xf8424fff [] drm_pci_init+0x104/0x110 [] ? 0xf8424fff [] init_module+0x12/0x14 [gma500_gfx] [] do_one_initcall+0xd2/0x120 [] ? __vunmap+0x87/0xd0 [] load_module+0x1745/0x1f20 [] SyS_finit_module+0x75/0x80 [] sysenter_do_call+0x12/0x16 Code: ac aa 84 c0 75 f7 31 c0 aa 89 d8 8b 75 f8 8b 5d f4 8b 7d fc 89 ec 5d c3 55 8d 2c 24 8d 64 24 f8 89 75 f8 89 7d fc 89 c6 89 d7 ac 75 08 84 c0 75 f8 31 c0 eb 04 19 c EIP: [] strcmp+0x13/0x30 SS:ESP 0068:f6d55b50 CR2: f858cf08 ---[ end trace ec712b3b117c8e34 ]--- Signed-off-by: Jan Safrata Cc: Patrik Jakobsson --- drivers/gpu/drm/gma500/psb_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c index 92e7e57..b1b837b 100644 --- a/drivers/gpu/drm/gma500/psb_drv.c +++ b/drivers/gpu/drm/gma500/psb_drv.c @@ -170,6 +170,8 @@ static int psb_driver_unload(struct drm_device *dev) gma_backlight_exit(dev); psb_modeset_cleanup(dev); + drm_irq_uninstall(dev); + if (dev_priv->ops->chip_teardown) dev_priv->ops->chip_teardown(dev); -- 1.8.5.5
[Bug 88459] Сomputer is not in sleep mode when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88459 --- Comment #2 from Andrew --- I put the video on pause and try to enter the computer to sleep (not hibernate) - then the monitor turns off and the computer is not(only helps power off or reset). If I close the player, or it does not use vdpau then everything is fine. -- 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/20150115/4861325e/attachment.html>
[Bug 88461] The computer sometimes freezes after waking up when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88461 --- Comment #1 from Alex Deucher --- Is this a duplicate of bug 88459? -- 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/20150115/d32c00c0/attachment.html>
[Bug 88459] Сomputer is not in sleep mode when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88459 --- Comment #1 from Alex Deucher --- It's a little unclear what's happening. Are you saying the when playing back certain videos the display goes off? If so, you are probably seeing a GPU lockup. -- 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/20150115/deb841fd/attachment.html>
[PATCH v2] drm/panel: Add support for AUO b101ean01 panel
The AUO b101ean01 panel is a 10.1" 1280x800 panel,
which can be supported by the simple panel driver.
Signed-off-by: huang lin
---
Changes in v2:
- changed panel timing
drivers/gpu/drm/panel/panel-simple.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index e95385b..c02f0e6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -392,6 +392,29 @@ static const struct panel_desc auo_b116xw03 = {
},
};
+static const struct drm_display_mode auo_b101ean01_mode = {
+ .clock = 72500,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 147,
+ .hsync_end = 1280 + 147 + 32,
+ .htotal = 1280 + 147 + 32 + 21,
+ .vdisplay = 800,
+ .vsync_start = 800 + 4,
+ .vsync_end = 800 + 4 + 4,
+ .vtotal = 800 + 4 + 4 + 8,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_b101ean01 = {
+ .modes = &auo_b101ean01_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+};
+
static const struct drm_display_mode auo_b133xtn01_mode = {
.clock = 69500,
.hdisplay = 1366,
@@ -727,6 +750,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b101aw03",
.data = &auo_b101aw03,
}, {
+ .compatible = "auo,b101ean01",
+ .data = &auo_b101ean01,
+ }, {
.compatible = "auo,b101xtn01",
.data = &auo_b101xtn01,
}, {
--
1.9.1
[Bug 88461] The computer sometimes freezes after waking up when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88461 Bug ID: 88461 Summary: The computer sometimes freezes after waking up when playing vdpau accelerated video Product: Mesa Version: 10.4 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: maaniv at gmail.com Created attachment 112293 --> https://bugs.freedesktop.org/attachment.cgi?id=112293&action=edit dmesg log I use smplayer (mplayer gui frontend) to watching video. Linux 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux Radeon 7850 2GB -- 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/20150115/70696ac4/attachment.html>
[Bug 88459] Сomputer is not in sleep mode when playing vdpau accelerated video
https://bugs.freedesktop.org/show_bug.cgi?id=88459 Bug ID: 88459 Summary: Сomputer is not in sleep mode when playing vdpau accelerated video Product: Mesa Version: 10.4 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: maaniv at gmail.com Created attachment 112291 --> https://bugs.freedesktop.org/attachment.cgi?id=112291&action=edit dmesg log Monitor turns off and the computer is not. Only helps power off or reset. Linux 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux Radeon 7850 2GB -- 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/20150115/ac51b6a5/attachment.html>
[Bug 88458] The monitor turns off when playing starcraft 2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=88458 --- Comment #2 from Andrew --- Created attachment 112289 --> https://bugs.freedesktop.org/attachment.cgi?id=112289&action=edit dmesg log In this case, he was involved back -- 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/20150115/38ce87b2/attachment.html>
[PULL] drm-intel-fixes
Hi Dave, another round of fixes for v3.19. BR, Jani. The following changes since commit eaa27f34e91a14cdceed26ed6c6793ec1d186115: linux 3.19-rc4 (2015-01-11 12:44:53 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-01-15 for you to fetch changes up to 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9: drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES (2015-01-12 10:53:02 +0200) Chris Wilson (2): drm/i915: Ban Haswell from using RCS flips drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES Imre Deak (3): drm/i915: gen9: fix RPS interrupt routing to CPU vs. GT drm/i915: fix HW lockup due to missing RPS IRQ workaround on GEN6 drm/i915: vlv: sanitize RPS interrupt mask during GPU idling drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 20 ++-- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 14 +++--- 5 files changed, 24 insertions(+), 15 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[Bug 88458] The monitor turns off when playing starcraft 2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=88458 --- Comment #1 from Andrew --- After playing some seconds monitor is turned off (7 of 7 launches). Sometimes it is then turned back on, sometimes - no. Sometimes an image just hangs. Ctrl+alt+f1 do not work when hanged. Linux 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux Radeon 7850 2GB memory -- 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/20150115/e0d76eb8/attachment.html>
[PATCH 3/3] drm/amdkfd: Remove sync_with_hw() from amdkfd
This patch completely removes the sync_with_hw() because it was broken and
actually there is no point of using it.
This function was used to:
- Make sure that the submitted packet to the HIQ (which is a kernel queue) was
read by the CP. However, it was discovered that the method this function used
to do that (checking wptr == rptr) is not consistent with how the actual CP
firmware works in all cases.
- Make sure that the queue is empty before issuing the next packet. To achieve
that, the function blocked amdkfd from continuing until the recently
submitted packet was consumed. However, the acquire_packet_buffer() already
checks if there is enough room for a new packet so calling sync_with_hw() is
redundant.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 24
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h | 2 --
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 5 +
3 files changed, 1 insertion(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
index 9350714..5ffca94 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c
@@ -265,28 +265,6 @@ static void submit_packet(struct kernel_queue *kq)
kq->pending_wptr);
}
-static int sync_with_hw(struct kernel_queue *kq, unsigned long timeout_ms)
-{
- unsigned long org_timeout_ms;
-
- BUG_ON(!kq);
-
- org_timeout_ms = timeout_ms;
- timeout_ms += jiffies * 1000 / HZ;
- while (*kq->wptr_kernel != *kq->rptr_kernel) {
- if (time_after(jiffies * 1000 / HZ, timeout_ms)) {
- pr_err("kfd: kernel_queue %s timeout expired %lu\n",
- __func__, org_timeout_ms);
- pr_err("kfd: wptr: %d rptr: %d\n",
- *kq->wptr_kernel, *kq->rptr_kernel);
- return -ETIME;
- }
- schedule();
- }
-
- return 0;
-}
-
static void rollback_packet(struct kernel_queue *kq)
{
BUG_ON(!kq);
@@ -308,7 +286,6 @@ struct kernel_queue *kernel_queue_init(struct kfd_dev *dev,
kq->uninitialize = uninitialize;
kq->acquire_packet_buffer = acquire_packet_buffer;
kq->submit_packet = submit_packet;
- kq->sync_with_hw = sync_with_hw;
kq->rollback_packet = rollback_packet;
if (kq->initialize(kq, dev, type, KFD_KERNEL_QUEUE_SIZE) == false) {
@@ -345,7 +322,6 @@ static __attribute__((unused)) void test_kq(struct kfd_dev
*dev)
for (i = 0; i < 5; i++)
buffer[i] = kq->nop_packet;
kq->submit_packet(kq);
- kq->sync_with_hw(kq, 1000);
pr_debug("kfd: ending kernel queue test\n");
}
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h
b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h
index dcd2bdb..11bfd92d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h
@@ -38,8 +38,6 @@ struct kernel_queue {
unsigned int **buffer_ptr);
void(*submit_packet)(struct kernel_queue *kq);
- int (*sync_with_hw)(struct kernel_queue *kq,
- unsigned long timeout_ms);
void(*rollback_packet)(struct kernel_queue *kq);
/* data */
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
index 5ce9233..24acd46 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
@@ -379,7 +379,6 @@ int pm_send_set_resources(struct packet_manager *pm,
packet->queue_mask_hi = upper_32_bits(res->queue_mask);
pm->priv_queue->submit_packet(pm->priv_queue);
- pm->priv_queue->sync_with_hw(pm->priv_queue, KFD_HIQ_TIMEOUT);
mutex_unlock(&pm->lock);
@@ -416,7 +415,6 @@ int pm_send_runlist(struct packet_manager *pm, struct
list_head *dqm_queues)
goto fail_create_runlist;
pm->priv_queue->submit_packet(pm->priv_queue);
- pm->priv_queue->sync_with_hw(pm->priv_queue, KFD_HIQ_TIMEOUT);
mutex_unlock(&pm->lock);
@@ -463,7 +461,7 @@ int pm_send_query_status(struct packet_manager *pm,
uint64_t fence_address,
packet->data_lo = lower_32_bits((uint64_t)fence_value);
pm->priv_queue->submit_packet(pm->priv_queue);
- pm->priv_queue->sync_with_hw(pm->priv_queue, KFD_HIQ_TIMEOUT);
+
mutex_unlock(&pm->lock);
return 0;
@@ -541,7 +539,6 @@ int pm_send_unmap_queue(struct packet_manager *pm, enum
kfd_queue_type type,
};
pm->priv_queue->submit_packet(pm->priv_queue);
- pm->priv_queue->sync_with_hw(pm->priv_queue, KFD_HIQ_TIMEOUT);
mutex_unlock(&pm->lock);
return 0;
--
2.1.0
[PATCH 2/3] drm/amdkfd: Remove unused function busy_wait()
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
index 4c3828c..5e065bd 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
@@ -28,12 +28,6 @@
#include "cik_regs.h"
#include "../../radeon/cik_reg.h"
-inline void busy_wait(unsigned long ms)
-{
- while (time_before(jiffies, ms))
- cpu_relax();
-}
-
static inline struct cik_mqd *get_mqd(void *mqd)
{
return (struct cik_mqd *)mqd;
--
2.1.0
[PATCH 1/3] drm/amdkfd: Replace cpu_relax() with schedule() in DQM
In order not to occupy the current core and thus prevent the core from
servicing IOMMU PPR requests, this patch replaces the call in DQM to
cpu_relax() with a call to schedule().
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 102aaba..08cf5b3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "kfd_priv.h"
#include "kfd_device_queue_manager.h"
#include "kfd_mqd_manager.h"
@@ -827,7 +828,7 @@ static int fence_wait_timeout(unsigned int *fence_addr,
pr_err("kfd: qcm fence wait loop timeout expired\n");
return -ETIME;
}
- cpu_relax();
+ schedule();
}
return 0;
--
2.1.0
[PATCH 0/3] Fixes for kernel queue handling issues
This small patch-set fixes a corner-case bug in kernel queue handling, which was caused by using a function called sync_with_hw(). The patch-set removes this function, as it is not needed anymore. As a result, we need to replace cpu_relax() with schedule() in DQM, so this patch-set takes care of that as well. I would like this fix to be in 3.19 so please review. Thanks, Oded Oded Gabbay (3): drm/amdkfd: Replace cpu_relax() with schedule() in DQM drm/amdkfd: Remove unused function busy_wait() drm/amdkfd: Remove sync_with_hw() from amdkfd .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 ++- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 24 -- drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.h | 2 -- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 6 -- drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c| 5 + 5 files changed, 3 insertions(+), 37 deletions(-) -- 2.1.0
[Bug 88456] Brütal Legend lockup
https://bugs.freedesktop.org/show_bug.cgi?id=88456 Bug ID: 88456 Summary: Brütal Legend lockup Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: geecko.dev at free.fr When testing on my desktop PC about two weeks ago, with latest mesa-git and llvm-git, I was getting a GPU lockup after the intro, when beating up the three druids. Arch Linux, HD 7950 I tried without HyperZ and with the lowest visual settings but it doesn't change anything. Here's an apitrace that makes my computer hang: http://ge.tt/7RmQXf72/v/0?c (fullscreen 1920x1080) -- 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/20150115/f44ece8c/attachment.html>
Softlockup on boot with Cape Verde XT on many kernels
On 15.01.2015 11:10, Federico wrote: > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using > softlockup_panic=1. > > Quite similar, but slightly different. Hopefully, useful. > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png Looks like it hangs while reading the video BIOS ROM. If the integrated GPU is still enabled in the system BIOS setup, does disabling it avoid the problem? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
On Thu, Jan 15, 2015 at 02:04:02AM +, Jindal, Sonika wrote: > So, if we do the source and dst adjustments in userspace, the logic in > intel_check_sprite_plane will not hold good there. I'm not sure what adjustments you mean. Src says exactly which part of the FB you want to present to the user, rotation doesn't change that fact. Dst says exactly where on the screen you want the image to appear, again rotation doesn't change that fact. > That's how it gets right coordinates and w,h for sprite for 90 rotation. > I thought drm_rect_rotate and other functions are there to handle such > scenarios. They are there mostly to make sure clipping happens correctly. They aren't there to magically fix userspace bugs. The only magicy part is the relaxed scaling and the rounding of coordinates based on hardware limits, and that stuff only exists so that it's easier to write userspace code without having to know the limitations of the hardware. > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Wednesday, January 14, 2015 11:38 PM > To: Jindal, Sonika > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > drm_plane_helper_check_update > > On Wed, Jan 14, 2015 at 01:54:06PM +, Jindal, Sonika wrote: > > I think I am confused here.. > > Since sprite plane handles this scaling and rotation in kernel, I thought > > it should be taken care in driver for primary as well. > > Well, userspace still has to know how the src and dst coordinates relate to > each other. > > Src coordinates are based on the memory layout. So src x=0,y=0 is the first > pixel in memory. x=1,y=0 is the second pixel in memory etc. > > Dst coordinates are based on the display pipe. So dst x=0,y=0 is the first > pixel that gets pushed out by the pipe for each frame. x=1,y=0 is the second > pixel getting pushed out. > > Let's say we have a 4x2 FB and a display mode of 8x4. Then we want to use a > sprite plane to present the FB with 0 and 90 degree rotation, and we want to > position the sprite plane at coordinates 2,0 on the CRTC. > It should look something like this: > > rotation=0 > src: x1=0,y1=0,x2=4,y2=2 (w=4, h=2) > dst: x1=2,y1=0,x2=6,y2=2 (w=4, h=2) > FB:CRTC: > 0,0 0,0 >|abcd| | abcd | >|efgh| | efgh | > 4,2 || >|| > 8,4 > > rotation=90 > src=0,0 -> 4,2 (w=4, h=2) > dst=2,0 -> 4,4 (w=2, h=4) > FB:CRTC: > 0,0 0,0 >|abcd| | dh| >|efgh| | cg| > 4,2 | bf| >| ae| > 8,4 > > > >From the test, I don't really change the src sizes for primary as well as > > >sprite to take care of 90/270 rotation. > > Sounds a bit buggy then. > > > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > > Sent: Wednesday, January 14, 2015 5:14 PM > > To: Jindal, Sonika > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > > drm_plane_helper_check_update > > > > On Wed, Jan 14, 2015 at 09:49:36AM +, Jindal, Sonika wrote: > > > Since we do drm_rect_rotate with 90 rotation, the src->w changes to > > > src->h. > > > Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser > > > than the min_hscale (which is no_scaling by default), so it returns > > > -ERANGE. > > > > If you want no scaling then with 90/270 rotation then your src->w should be > > equal to dst->h. Then the calculated vscale will be 1.0. If it's not, then > > your test is passing in bad coordinates. > > > > > So, I think we _relaxed is the function which should be called to update > > > the destination size appropriately. > > > Please correct me if I am wrong. > > > > > > -Original Message- > > > From: Jindal, Sonika > > > Sent: Wednesday, January 14, 2015 3:06 PM > > > To: 'Ville Syrjälä' > > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > > Subject: RE: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > > > drm_plane_helper_check_update > > > > > > We do exactly like this for sprite plane (ie, rotate the rect, then check > > > scaling and adjust the size accordingly from > > > drm_rect_calc_hscale_relaxed) That's why I saw the need of this for > > > primary plane as well. > > > For sprite plane 90 rotation, intel_check_sprite_plane does the > > > adjustments and the rotated sizes are fine. But since we don't do any of > > > those stuff for primary the destination size doesn't come right, and I > > > get a little corrupted output after rotation. > > > With this change, the rotated plane is properly adjusted in the viewport. > > > So, I don't think it is a bug in test. > > > > > > -Original
[PATCH] drm/radeon: use rv515_ring_start on r5xx
This was accidently lost in 76a0df859def.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_asic.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 6e47662..f811ee1 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -333,6 +333,20 @@ static struct radeon_asic_ring r300_gfx_ring = {
.set_wptr = &r100_gfx_set_wptr,
};
+static struct radeon_asic_ring rv515_gfx_ring = {
+ .ib_execute = &r100_ring_ib_execute,
+ .emit_fence = &r300_fence_ring_emit,
+ .emit_semaphore = &r100_semaphore_ring_emit,
+ .cs_parse = &r300_cs_parse,
+ .ring_start = &rv515_ring_start,
+ .ring_test = &r100_ring_test,
+ .ib_test = &r100_ib_test,
+ .is_lockup = &r100_gpu_is_lockup,
+ .get_rptr = &r100_gfx_get_rptr,
+ .get_wptr = &r100_gfx_get_wptr,
+ .set_wptr = &r100_gfx_set_wptr,
+};
+
static struct radeon_asic r300_asic = {
.init = &r300_init,
.fini = &r300_fini,
@@ -744,7 +758,7 @@ static struct radeon_asic rv515_asic = {
.set_page = &rv370_pcie_gart_set_page,
},
.ring = {
- [RADEON_RING_TYPE_GFX_INDEX] = &r300_gfx_ring
+ [RADEON_RING_TYPE_GFX_INDEX] = &rv515_gfx_ring
},
.irq = {
.set = &rs600_irq_set,
@@ -810,7 +824,7 @@ static struct radeon_asic r520_asic = {
.set_page = &rv370_pcie_gart_set_page,
},
.ring = {
- [RADEON_RING_TYPE_GFX_INDEX] = &r300_gfx_ring
+ [RADEON_RING_TYPE_GFX_INDEX] = &rv515_gfx_ring
},
.irq = {
.set = &rs600_irq_set,
--
1.8.3.1
boot delay with drm_kms_helper.edid_firmware
On Wed, 14 Jan 2015, Robert Kuhn wrote: > thanks for the answer. I believe I got it. I did not know that there are > already some edids build into the kernel. What I did try to achieve is that > my edid placed in the file system (under /lib/firmware/edid/) is loaded on > boot. I named my special edid file also 1024x786.bin so I never noticed > that my file wasn't loaded. Instead the edid build into the kernel was > used. Got it. > > For testing I renamed my edid to myedid.bin. Now I got (of course): > [0.767201] pinctrl-single 44e10800.pinmux: pin 44e10854 already > requested by 44e10800.pinmux; cannot claim for gpio-leds.8 > [0.778895] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status > -22 > [0.786166] pinctrl-single 44e10800.pinmux: could not request pin 21 on > device pinctrl-single > [ 61.001555] [drm:edid_load] *ERROR* Requesting EDID firmware > "edid/myedid.bin" failed (err=-2) > > But there is the file: > debian at beaglebone:~$ ls -ls /lib/firmware/edid/ > total 4 > 4 -rw-r--r-- 1 debian debian 128 Feb 17 2014 myedid.bin Hmm, you have drm and drm_kms_helper built-in to the kernel. If you're using an initrd, I believe the firmware loader will look there instead of your rootfs. I am not sure if having the modules loadable but still in initrd helps, probably not. You may need to have the modules in rootfs or put the edid in initrd. It gets a bit tricky. > So with 3.8. its not possible to tell the kernel to load the buildin first? That seems to be the case. > Okay, then I will try the v3.18.x branch for Beaglebone. Good luck! > Thanks! No problem. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH] drm/radeon/rv515: Remove unused function
|
>>> - (6 << MS_Y1_SHIFT) |
>>> - (6 << MS_X2_SHIFT) |
>>> - (6 << MS_Y2_SHIFT) |
>>> - (6 << MSBD0_Y_SHIFT) |
>>> - (6 << MSBD0_X_SHIFT)));
>>> - radeon_ring_write(ring, PACKET0(GB_MSPOS1, 0));
>>> - radeon_ring_write(ring,
>>> - ((6 << MS_X3_SHIFT) |
>>> - (6 << MS_Y3_SHIFT) |
>>> - (6 << MS_X4_SHIFT) |
>>> - (6 << MS_Y4_SHIFT) |
>>> - (6 << MS_X5_SHIFT) |
>>> - (6 << MS_Y5_SHIFT) |
>>> - (6 << MSBD1_SHIFT)));
>>> - radeon_ring_write(ring, PACKET0(GA_ENHANCE, 0));
>>> - radeon_ring_write(ring, GA_DEADLOCK_CNTL | GA_FASTSYNC_CNTL);
>>> - radeon_ring_write(ring, PACKET0(GA_POLY_MODE, 0));
>>> - radeon_ring_write(ring, FRONT_PTYPE_TRIANGE | BACK_PTYPE_TRIANGE);
>>> - radeon_ring_write(ring, PACKET0(GA_ROUND_MODE, 0));
>>> - radeon_ring_write(ring, GEOMETRY_ROUND_NEAREST |
>>> COLOR_ROUND_NEAREST);
>>> - radeon_ring_write(ring, PACKET0(0x20C8, 0));
>>> - radeon_ring_write(ring, 0);
>>> - radeon_ring_unlock_commit(rdev, ring, false);
>>> -}
>>> -
>>> int rv515_mc_wait_for_idle(struct radeon_device *rdev)
>>> {
>>> unsigned i;
>>> --
>>> 1.7.10.4
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-use-rv515_ring_start-on-r5xx.patch
Type: text/x-patch
Size: 1854 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150115/bdd62ebb/attachment-0001.bin>
[PATCH] drm/radeon/rv515: Remove unused function
This one looks highly suspicious, i need to check, but i would think
that this function should be use !
On Wed, Jan 14, 2015 at 4:44 PM, Alex Deucher wrote:
> On Tue, Jan 13, 2015 at 1:55 PM, Rickard Strandqvist
> wrote:
>> Remove the function rv515_ring_start() that is not used anywhere.
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist > spectrumdigital.se>
>
> Applied. thanks!
>
> Alex
>
>> ---
>> drivers/gpu/drm/radeon/radeon_asic.h |1 -
>> drivers/gpu/drm/radeon/rv515.c | 68
>> --
>> 2 files changed, 69 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
>> b/drivers/gpu/drm/radeon/radeon_asic.h
>> index d8ace5b..52667b3 100644
>> --- a/drivers/gpu/drm/radeon/radeon_asic.h
>> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
>> @@ -280,7 +280,6 @@ int rv515_init(struct radeon_device *rdev);
>> void rv515_fini(struct radeon_device *rdev);
>> uint32_t rv515_mc_rreg(struct radeon_device *rdev, uint32_t reg);
>> void rv515_mc_wreg(struct radeon_device *rdev, uint32_t reg, uint32_t v);
>> -void rv515_ring_start(struct radeon_device *rdev, struct radeon_ring *ring);
>> void rv515_bandwidth_update(struct radeon_device *rdev);
>> int rv515_resume(struct radeon_device *rdev);
>> int rv515_suspend(struct radeon_device *rdev);
>> diff --git a/drivers/gpu/drm/radeon/rv515.c b/drivers/gpu/drm/radeon/rv515.c
>> index 8a477bf..cb966e6 100644
>> --- a/drivers/gpu/drm/radeon/rv515.c
>> +++ b/drivers/gpu/drm/radeon/rv515.c
>> @@ -59,74 +59,6 @@ void rv515_debugfs(struct radeon_device *rdev)
>> }
>> }
>>
>> -void rv515_ring_start(struct radeon_device *rdev, struct radeon_ring *ring)
>> -{
>> - int r;
>> -
>> - r = radeon_ring_lock(rdev, ring, 64);
>> - if (r) {
>> - return;
>> - }
>> - radeon_ring_write(ring, PACKET0(ISYNC_CNTL, 0));
>> - radeon_ring_write(ring,
>> - ISYNC_ANY2D_IDLE3D |
>> - ISYNC_ANY3D_IDLE2D |
>> - ISYNC_WAIT_IDLEGUI |
>> - ISYNC_CPSCRATCH_IDLEGUI);
>> - radeon_ring_write(ring, PACKET0(WAIT_UNTIL, 0));
>> - radeon_ring_write(ring, WAIT_2D_IDLECLEAN | WAIT_3D_IDLECLEAN);
>> - radeon_ring_write(ring, PACKET0(R300_DST_PIPE_CONFIG, 0));
>> - radeon_ring_write(ring, R300_PIPE_AUTO_CONFIG);
>> - radeon_ring_write(ring, PACKET0(GB_SELECT, 0));
>> - radeon_ring_write(ring, 0);
>> - radeon_ring_write(ring, PACKET0(GB_ENABLE, 0));
>> - radeon_ring_write(ring, 0);
>> - radeon_ring_write(ring, PACKET0(R500_SU_REG_DEST, 0));
>> - radeon_ring_write(ring, (1 << rdev->num_gb_pipes) - 1);
>> - radeon_ring_write(ring, PACKET0(VAP_INDEX_OFFSET, 0));
>> - radeon_ring_write(ring, 0);
>> - radeon_ring_write(ring, PACKET0(RB3D_DSTCACHE_CTLSTAT, 0));
>> - radeon_ring_write(ring, RB3D_DC_FLUSH | RB3D_DC_FREE);
>> - radeon_ring_write(ring, PACKET0(ZB_ZCACHE_CTLSTAT, 0));
>> - radeon_ring_write(ring, ZC_FLUSH | ZC_FREE);
>> - radeon_ring_write(ring, PACKET0(WAIT_UNTIL, 0));
>> - radeon_ring_write(ring, WAIT_2D_IDLECLEAN | WAIT_3D_IDLECLEAN);
>> - radeon_ring_write(ring, PACKET0(GB_AA_CONFIG, 0));
>> - radeon_ring_write(ring, 0);
>> - radeon_ring_write(ring, PACKET0(RB3D_DSTCACHE_CTLSTAT, 0));
>> - radeon_ring_write(ring, RB3D_DC_FLUSH | RB3D_DC_FREE);
>> - radeon_ring_write(ring, PACKET0(ZB_ZCACHE_CTLSTAT, 0));
>> - radeon_ring_write(ring, ZC_FLUSH | ZC_FREE);
>> - radeon_ring_write(ring, PACKET0(GB_MSPOS0, 0));
>> - radeon_ring_write(ring,
>> - ((6 << MS_X0_SHIFT) |
>> - (6 << MS_Y0_SHIFT) |
>> - (6 << MS_X1_SHIFT) |
>> - (6 << MS_Y1_SHIFT) |
>> - (6 << MS_X2_SHIFT) |
>> - (6 << MS_Y2_SHIFT) |
>> - (6 << MSBD0_Y_SHIFT) |
>> - (6 << MSBD0_X_SHIFT)));
>> - radeon_ring_write(ring, PACKET0(GB_MSPOS1, 0));
>> - radeon_ring_write(ring,
>> - ((6 << MS_X3_SHIFT) |
>> - (6 << MS_Y3_SHIFT) |
>> - (6 << MS_X4_SHIFT) |
>> - (6 << MS_Y4_SHIFT) |
>> - (6 << MS_X5_SHIFT) |
>> - (6 << MS_Y5_SHIFT) |
>> - (6 << MSBD1_SHIFT)));
>> - radeon_ring_write(ring, PACKET0(GA_ENHANCE, 0));
>> - radeon_ring_write(ring, GA_DEADLOCK_CNTL | GA_FASTSYNC_CNTL);
>> - radeon_ring_write(ring, PACKET0(GA_POLY_MODE, 0));
>> - radeon_ring_write(ring, FRONT_PTYPE_TRIANGE | BACK_PTYPE_TRIANGE);
>> - radeon_ring_write(ring, PACKET0(GA_ROUND_MODE, 0));
>> - radeon_ring_write(ring, GEOMETRY_ROUND_NEARE
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #231 from Marti Raudsepp --- (In reply to Liss from comment #230) > Looks like I have similar issue with Radeon 8850M. I already filled bug > 88364, but I'm not sure should I mark it as duplicate (In reply to Andrew from comment #229) > My dmesg output is similar to an attachments to this bug. Do I need to > create a new bug in this case? Please report all issues you have as separate bugs! This bug mixes together multiple issues and symptoms, so it's almost useless. -- 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/20150115/76f70e8b/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #230 from Liss --- Looks like I have similar issue with Radeon 8850M. I already filled bug 88364, but I'm not sure should I mark it as duplicate because I'm not sure that it is same problem. -- 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/20150115/4ae12854/attachment.html>
[PATCH 2/2] drm/msm/mdp5: Add hardware cursor support
On Wed, Jan 14, 2015 at 7:55 PM, Daniel Vetter wrote:
> On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote:
>> From: Beeresh Gopal
>>
>> This patch implements the hardware accelarated cursor
>> support for MDP5 platforms.
>>
>> Signed-off-by: Beeresh Gopal
>> Signed-off-by: Wentao Xu
>> Signed-off-by: Stephane Viau
>
> Imo implementing legacy cursor support instead of with universal planes
> makes no sense. Especially since msm is converted to atomic already, and
> you can't move the cursor with atomic when it's legacy only. See the
> cursor argument for the drm_crtc_init_with_planes function and how it's
> used in e.g. i915.
>
well, I'm still not 100% convinced about going through the whole
atomic mechanism for cursors.. in particular stuff that tries to
enable/disable the cursor at 1000fps, goes *really* badly when things
start waiting for vsync.
I'll probably try some experiments with it at some point, but at this
point something that works with x11 is a lot more interesting for me
(since every time I switch from mdp4 device to mdp5 device I forget to
disable hw cursor the first time I start x)
BR,
-R
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 164
>> +++
>> 1 file changed, 164 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> index f021f96..2021f09 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
>> @@ -24,6 +24,9 @@
>> #include "drm_crtc_helper.h"
>> #include "drm_flip_work.h"
>>
>> +#define CURSOR_WIDTH 64
>> +#define CURSOR_HEIGHT 64
>> +
>> #define SSPP_MAX (SSPP_RGB3 + 1) /* TODO: Add SSPP_MAX in mdp5.xml.h */
>>
>> struct mdp5_crtc {
>> @@ -47,8 +50,21 @@ struct mdp5_crtc {
>> #define PENDING_FLIP 0x2
>> atomic_t pending;
>>
>> + /* for unref'ing cursor bo's after scanout completes: */
>> + struct drm_flip_work unref_cursor_work;
>> +
>> struct mdp_irq vblank;
>> struct mdp_irq err;
>> +
>> + struct {
>> + /* protect REG_MDP5_LM_CURSOR* registers and cursor scanout_bo*/
>> + spinlock_t lock;
>> +
>> + /* current cursor being scanned out: */
>> + struct drm_gem_object *scanout_bo;
>> + uint32_t width;
>> + uint32_t height;
>> + } cursor;
>> };
>> #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
>>
>> @@ -129,11 +145,22 @@ static void complete_flip(struct drm_crtc *crtc,
>> struct drm_file *file)
>> }
>> }
>>
>> +static void unref_cursor_worker(struct drm_flip_work *work, void *val)
>> +{
>> + struct mdp5_crtc *mdp5_crtc =
>> + container_of(work, struct mdp5_crtc, unref_cursor_work);
>> + struct mdp5_kms *mdp5_kms = get_kms(&mdp5_crtc->base);
>> +
>> + msm_gem_put_iova(val, mdp5_kms->id);
>> + drm_gem_object_unreference_unlocked(val);
>> +}
>> +
>> static void mdp5_crtc_destroy(struct drm_crtc *crtc)
>> {
>> struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
>>
>> drm_crtc_cleanup(crtc);
>> + drm_flip_work_cleanup(&mdp5_crtc->unref_cursor_work);
>>
>> kfree(mdp5_crtc);
>> }
>> @@ -384,6 +411,132 @@ static int mdp5_crtc_set_property(struct drm_crtc
>> *crtc,
>> return -EINVAL;
>> }
>>
>> +static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
>> + struct drm_file *file, uint32_t handle,
>> + uint32_t width, uint32_t height)
>> +{
>> + struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
>> + struct drm_device *dev = crtc->dev;
>> + struct mdp5_kms *mdp5_kms = get_kms(crtc);
>> + struct drm_gem_object *cursor_bo, *old_bo;
>> + uint32_t blendcfg, cursor_addr, stride;
>> + int ret, bpp, lm;
>> + unsigned int depth;
>> + enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
>> + uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
>> + unsigned long flags;
>> +
>> + if ((width > CURSOR_WIDTH) || (height > CURSOR_HEIGHT)) {
>> + dev_err(dev->dev, "bad cursor size: %dx%d\n", width, height);
>> + return -EINVAL;
>> + }
>> +
>> + if (NULL == mdp5_crtc->ctl)
>> + return -EINVAL;
>> +
>> + if (!handle) {
>> + DBG("Cursor off");
>> + return mdp5_ctl_set_cursor(mdp5_crtc->ctl, false);
>> + }
>> +
>> + cursor_bo = drm_gem_object_lookup(dev, file, handle);
>> + if (!cursor_bo)
>> + return -ENOENT;
>> +
>> + ret = msm_gem_get_iova(cursor_bo, mdp5_kms->id, &cursor_addr);
>> + if (ret)
>> + return -EINVAL;
>> +
>> + lm = mdp5_crtc->lm;
>> + drm_fb_get_bpp_depth(DRM_FORMAT_ARGB, &depth, &bpp);
>> + stride = width * (bpp >> 3);
>> +
>> + spin_lock_irqsave(&mdp5_crtc->cursor.lock, flags);
>> + old_bo = mdp5_crtc->cursor.scanout_bo;
>> +
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
>> + MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_IMG_SIZE(lm),
>> + MDP5_LM_CURSOR_IMG_SIZE_SRC_H(height) |
>> + MDP5_LM_CURSOR_IMG_SIZE_SRC_W(width));
>> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_SIZE(lm),
>> + MDP5_LM_CURSOR_SIZE_ROI_H(height) |
>> + MDP
[Bug 88183] radeonsi: R9 280X hangs with SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=88183 --- Comment #6 from Michel Dänzer --- I can reproduce the hang with current Mesa Git master, but not with the Debian 10.3.2 packages. Can you confirm that and if so, can you bisect? Even with 10.3.2 though, there are GPUVM faults, looks like the CB writing past the end of DXT5 SRGBA textures: VM start=0x262F end=0x26346800 | Texture 512x512x1, 10 levels, 1 samples, dxt5_srgba [...] Jan 15 16:52:47 kaveri kernel: [ 208.982506] radeon :00:01.0: GPU fault detected: 146 0x09450014 Jan 15 16:52:47 kaveri kernel: [ 208.982511] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0002634A Jan 15 16:52:47 kaveri kernel: [ 208.982513] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0514 Jan 15 16:52:47 kaveri kernel: [ 208.982514] VM fault (0x04, vmid 2) at page 156490, write from 'CB0' (0x43423000) (0) Jan 15 16:52:47 kaveri kernel: [ 208.982519] radeon :00:01.0: GPU fault detected: 146 0x09050014 Jan 15 16:52:47 kaveri kernel: [ 208.982520] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00026347 Jan 15 16:52:47 kaveri kernel: [ 208.982521] radeon :00:01.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0514 Jan 15 16:52:47 kaveri kernel: [ 208.982522] VM fault (0x04, vmid 2) at page 156487, write from 'CB0' (0x43423000) (0) -- 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/20150115/c1ffde89/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #229 from Andrew --- My dmesg output is similar to an attachments to this bug. Do I need to create a new bug in this case? -- 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/20150115/0612a5bd/attachment.html>
[Bug 88301] Dota causes GPU fault and kernel hang
https://bugs.freedesktop.org/show_bug.cgi?id=88301 --- Comment #1 from Michel Dänzer --- Replaying this trace on my Kaveri, I get similar GPUVM faults, but no hangs. What are the symptoms of the hangs? -- 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/20150115/5c7df705/attachment.html>
[RFC PATCH v4 3/4] ipvr: user mode helper for ipvr drm driver
+ commenters of v1~v3 Thanks, Yao > -Original Message- > From: Sean V Kelley [mailto:seanvk at posteo.de] > Sent: Thursday, January 8, 2015 8:35 > To: Intel-gfx at lists.freedesktop.org > Cc: dri-devel at lists.freedesktop.org; Cheng, Yao; Sean V Kelley > Subject: [RFC PATCH v4 3/4] ipvr: user mode helper for ipvr drm driver > > From: Yao Cheng > > add usermode helper for the ipvr kernel driver. > test_ioctl: test kernel driver by directly ioctl > > v2: > take Emil's comments > - correctly align ipvr_drm.h > > v3: > take Daniel Vetter and Daniel Stone's comments, and implement PRIME > - correctly align ipvr_drm.h > - use __u32 family in ipvr_drm.h > - rip out explicit fence from libdrm_ipvr > - implemented PRIME support > - add relocation fixup implementation > > v4 > bug fixing and add stress test tool > - rename ipvr/test_ioctl.c to ipvr/test_ipvr.c > - implement parallel ioctl stress test in test_ipvr.c > - implement parallel libdrm stress test in test_ipvr.c > - update ipvr_drm.h to keep consistent with kernel change > - remove unused "buffer_ofs/alloc_size/ext_handle" from struct > drm_ipvr_bo > - remove unused arguments for some public functions > - fix a few foolish copy-paste bugs > - fix 32bit compiling issue > > Signed-off-by: Yao Cheng > Signed-off-by: Sean V Kelley > --- > Makefile.am|6 +- > Makefile.sources |1 + > configure.ac | 26 +- > include/drm/ipvr_drm.h | 259 +++ > ipvr/Makefile.am | 57 +++ > ipvr/Makefile.sources |5 + > ipvr/ipvr_bufmgr.h | 132 ++ > ipvr/ipvr_bufmgr_gem.c | 1188 > > ipvr/libdrm_ipvr.pc.in | 11 + > ipvr/test_ipvr.c | 919 + > 10 files changed, 2602 insertions(+), 2 deletions(-) > create mode 100644 include/drm/ipvr_drm.h > create mode 100644 ipvr/Makefile.am > create mode 100644 ipvr/Makefile.sources > create mode 100644 ipvr/ipvr_bufmgr.h > create mode 100644 ipvr/ipvr_bufmgr_gem.c > create mode 100644 ipvr/libdrm_ipvr.pc.in > create mode 100644 ipvr/test_ipvr.c > > diff --git a/Makefile.am b/Makefile.am > index 3cb516c..035d937 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -33,6 +33,10 @@ if HAVE_INTEL > INTEL_SUBDIR = intel > endif > > +if HAVE_IPVR > +IPVR_SUBDIR = ipvr > +endif > + > if HAVE_NOUVEAU > NOUVEAU_SUBDIR = nouveau > endif > @@ -57,7 +61,7 @@ if HAVE_TEGRA > TEGRA_SUBDIR = tegra > endif > > -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) > $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) > $(FREEDRENO_SUBDIR) $(TEGRA_SUBDIR) tests man > +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR) > $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) > $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) $(TEGRA_SUBDIR) tests man > > libdrm_la_LTLIBRARIES = libdrm.la > libdrm_ladir = $(libdir) > diff --git a/Makefile.sources b/Makefile.sources > index 566f7b5..819a0cb 100644 > --- a/Makefile.sources > +++ b/Makefile.sources > @@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \ > include/drm/drm_mode.h \ > include/drm/drm_sarea.h \ > include/drm/i915_drm.h \ > + include/drm/ipvr_drm.h \ > include/drm/mach64_drm.h \ > include/drm/mga_drm.h \ > include/drm/nouveau_drm.h \ > diff --git a/configure.ac b/configure.ac > index c88a1c5..9fea4db 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel, > [Enable support for intel's KMS API (default: auto)]), > [INTEL=$enableval], [INTEL=auto]) > > +AC_ARG_ENABLE(ipvr, > + AS_HELP_STRING([--disable-ipvr], > + [Enable support for valeyview's IPVR hardware decode (default: > auto)]), > + [IPVR=$enableval], [IPVR=auto]) > + > AC_ARG_ENABLE(radeon, > AS_HELP_STRING([--disable-radeon], > [Enable support for radeon's KMS API (default: auto)]), > @@ -209,7 +214,7 @@ if test "x$drm_cv_atomic_primitives" = "xlibatomic- > ops"; then > AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have > libatomic-ops-dev installed]) > fi > > -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != > "xno"; then > +if test "x$INTEL" != "xno" -o "x$IPVR" != "xno" -o "x$RADEON" != "xno" -o > "x$NOUVEAU" != "xno"; then > if test "x$drm_cv_atomic_primitives" = "xnone"; then > if test "x$INTEL" != "xauto"; then > if test "x$INTEL" != "xno"; then > @@ -219,6 +224,14 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o > "x$NOUVEAU" != "xno"; then > AC_MSG_WARN([Disabling libdrm_intel. It depends > on atomic operations, which were not found for your compiler/cpu. Try > compiling with -march=native, or install the libatomics-op-dev package.]) > INTEL=no > fi > + if test "x$IPVR"
[RFC PATCH V4 1/4] drm/i915: add i915_ved.c to setup bridge for VED
+ commenters of v1~v3
Thanks,
Yao
> -Original Message-
> From: Sean V Kelley [mailto:seanvk at posteo.de]
> Sent: Thursday, January 8, 2015 8:35
> To: Intel-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org; Cheng, Yao; Sean V Kelley
> Subject: [RFC PATCH V4 1/4] drm/i915: add i915_ved.c to setup bridge for
> VED
>
> From: Yao Cheng
>
> Setup minimum required resources during i915_driver_load:
> 1. Create a platform device to share MMIO/IRQ resources 2. Make the
> platform device child of i915 device for runtime PM.
> 3. Create IRQ chip to forward the VED irqs.
> VED driver (a standalone drm driver) probes the VED device and creates a
> new dri card on install.
> Currently only supports VED on valleyview.
> Kerneldoc is updated for i915_ved.c.
>
> v2:
> take Daniel & Jani's comments
> - extract change to new file i915_ved.c
> - add kerneldoc
> - change 'ipvr-ved' to 'ipvr-vlv-ved' for extensibility
> - unregister platdev before irq_free_desc
> - add WARN_ON(!intel_irqs_enabled) in irq init code
> - remove unnecessary trace point
> - remove unnecessary BUG_ON
>
> v3:
> take Ville's comments and VED PRIME support
> - add HAS_VED() check
> - add ved struct to make code neat
> - no need to check platform in vlv_irq_handler
> - i915_reg.h update
> - no need to kmalloc for small amount of resource
> - remove unnecessary REG resource
> - follow vlv_display_irqs_install() to implement VED mask/unmask
> - workaround nommu_map_sg issue by set dma_mask to support
> VED PRIME.
>
> v4:
> take Bob's comments
> - add more detail on the use-after-free issue description
> - mask VED irq before removing the child device
>
> Signed-off-by: Yao Cheng
> Signed-off-by: Sean V Kelley
> ---
> Documentation/DocBook/drm.tmpl | 5 +
> drivers/gpu/drm/i915/Makefile | 3 +
> drivers/gpu/drm/i915/i915_dma.c | 11 ++ drivers/gpu/drm/i915/i915_drv.h
> | 12 ++
> drivers/gpu/drm/i915/i915_irq.c | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 4 +
> drivers/gpu/drm/i915/i915_ved.c | 270
>
> 7 files changed, 307 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/i915_ved.c
>
> diff --git a/Documentation/DocBook/drm.tmpl
> b/Documentation/DocBook/drm.tmpl index 56e2a9b..9db989c 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3867,6 +3867,11 @@ int
> num_ioctls; !Fdrivers/gpu/drm/i915/i915_irq.c
> intel_runtime_pm_disable_interrupts
> !Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
>
> +
> +VED video core integration
> +!Pdrivers/gpu/drm/i915/i915_ved.c VED video core integration
> +!Idrivers/gpu/drm/i915/i915_ved.c
> +
>
>
>Display Hardware Handling diff --git
> a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index
> e4083e4..7d0bbfa 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -84,6 +84,9 @@ i915-y += dvo_ch7017.o \ i915-y += i915_dma.o \
> i915_ums.o
>
> +# VED for VLV
> +i915-y += i915_ved.o
> +
> obj-$(CONFIG_DRM_I915) += i915.o
>
> CFLAGS_i915_trace_points.o := -I$(src)
> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> b/drivers/gpu/drm/i915/i915_dma.c index 887d88f..cd96618 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -828,6 +828,13 @@ int i915_driver_load(struct drm_device *dev,
> unsigned long flags)
> if (IS_GEN5(dev))
> intel_gpu_ips_init(dev_priv);
>
> + if (HAS_VED(dev)) {
> + ret = vlv_setup_ved(dev);
> + if (ret < 0) {
> + DRM_ERROR("failed to setup VED bridge: %d\n", ret);
> + }
> + }
> +
> intel_runtime_pm_enable(dev_priv);
>
> return 0;
> @@ -870,6 +877,10 @@ int i915_driver_unload(struct drm_device *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
> int ret;
>
> + if (HAS_VED(dev)) {
> + vlv_teardown_ved(dev);
> + }
> +
> ret = i915_gem_suspend(dev);
> if (ret) {
> DRM_ERROR("failed to idle hardware: %d\n", ret); diff --git
> a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 502a01b..aa39d47 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1773,6 +1773,12 @@ struct drm_i915_private {
>
> uint32_t bios_vgacntr;
>
> + /* necessary resource sharing with ved driver. */
> + struct {
> + struct platform_device *platdev;
> + int irq;
> + } ved;
> +
> /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> away */
> struct {
> int (*do_execbuf)(struct drm_device *dev, struct drm_file
> *file, @@ -2305,6 +2311,7 @@ struct drm_i915_cmd_table {
>IS_BROADWEL
[RFC PATCH v4 0/4] drm driver for VED in Intel GPU
+ commenters of v1~v3 Thanks, Yao > -Original Message- > From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf > Of Sean V Kelley > Sent: Thursday, January 8, 2015 8:35 > To: Intel-gfx at lists.freedesktop.org > Cc: dri-devel at lists.freedesktop.org > Subject: [RFC PATCH v4 0/4] drm driver for VED in Intel GPU > > > drm/ipvr is a new GEM driver for VED (PowerVR's VPU integrated in Intel > GPU), which extends video capability. > A new Kconfig added for building ipvr driver: > > CONFIG_DRM_IPVR: Build option for ipvr module > > The driver name "ipvr" means the PowerVR's core wrapped by Intel. The > PowerVR VPUs are also integrated by non-i915 platforms such as GMA500, so > we keep ipvr driver and i915 driver separated and independent to each other. > To achieve this we do the minimum change in i915: i915_ved.c added for > setting up the bridge between VED and i915, kerneldoc also updated. > > User mode drm helper "libdrm_ipvr.so" and simple ioctl/execute test is > included. > > one test script "drv_module_reload" in i-g-t also updated to support ipvr > loading and unloading. Due to restriction in Linux platform device model, we > have to manually unload ipvr before unloading i915. > > Yao Cheng (4): > [1/4] drm/i915: add i915_ved.c to setup bridge for VED [2/4] drm/ipvr: drm > driver for VED [3/4] libdrm/ipvr: user mode helper for ipvr drm driver [4/4] > i- > g-t: tests/drv_module_reload: add ipvr support > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v4 4/4] tests/drv_module_reload: add ipvr support
+ commenters on v1~v3 When locking issue resolved, this patch can be removed. Thanks, Yao > -Original Message- > From: Sean V Kelley [mailto:seanvk at posteo.de] > Sent: Thursday, January 8, 2015 8:35 > To: Intel-gfx at lists.freedesktop.org > Cc: dri-devel at lists.freedesktop.org; Cheng, Yao; Sean V Kelley > Subject: [RFC PATCH v4 4/4] tests/drv_module_reload: add ipvr support > > From: Yao Cheng > > on vlv, if ipvr is installed, it need be manually unloaded before i915, > otherwise user might run into use-after-free issue. > > v2: > added this patch per Daniel's comment > > v3: > no change > > Signed-off-by: Yao Cheng > Signed-off-by: Sean V Kelley > --- > tests/drv_module_reload | 16 > 1 file changed, 16 insertions(+) > > diff --git a/tests/drv_module_reload b/tests/drv_module_reload index > 5cbff89..82c67bd 100755 > --- a/tests/drv_module_reload > +++ b/tests/drv_module_reload > @@ -24,6 +24,14 @@ rmmod snd_hda_intel &> /dev/null > > #ignore errors in ips - gen5 only > rmmod intel_ips &> /dev/null > + > +# vlv only for now: > +# due to platform device model limitation, need unload ipvr manually if > +lsmod | grep ipvr &> /dev/null ; then > + echo Need manually unload ipvr.ko. > + rmmod ipvr > +fi > + > rmmod i915 > #ignore errors in intel-gtt, often built-in rmmod intel-gtt &> /dev/null @@ > - > 31,6 +39,11 @@ rmmod intel-gtt &> /dev/null rmmod drm_kms_helper &> > /dev/null rmmod drm &> /dev/null > > +if lsmod | grep ipvr &> /dev/null ; then > + echo WARNING: ipvr.ko still loaded! > + exit 1 > +fi > + > if lsmod | grep i915 &> /dev/null ; then > echo WARNING: i915.ko still loaded! > exit 1 > @@ -41,6 +54,9 @@ fi > modprobe i915 > echo 1 > /sys/class/vtconsole/vtcon1/bind > > +# for vlv, load VED driver > +modprobe ipvr > + > modprobe snd_hda_intel > > # try to run something > -- > 2.1.0
[Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update
So, if we do the source and dst adjustments in userspace, the logic in intel_check_sprite_plane will not hold good there. That's how it gets right coordinates and w,h for sprite for 90 rotation. I thought drm_rect_rotate and other functions are there to handle such scenarios. -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Wednesday, January 14, 2015 11:38 PM To: Jindal, Sonika Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to drm_plane_helper_check_update On Wed, Jan 14, 2015 at 01:54:06PM +, Jindal, Sonika wrote: > I think I am confused here.. > Since sprite plane handles this scaling and rotation in kernel, I thought it > should be taken care in driver for primary as well. Well, userspace still has to know how the src and dst coordinates relate to each other. Src coordinates are based on the memory layout. So src x=0,y=0 is the first pixel in memory. x=1,y=0 is the second pixel in memory etc. Dst coordinates are based on the display pipe. So dst x=0,y=0 is the first pixel that gets pushed out by the pipe for each frame. x=1,y=0 is the second pixel getting pushed out. Let's say we have a 4x2 FB and a display mode of 8x4. Then we want to use a sprite plane to present the FB with 0 and 90 degree rotation, and we want to position the sprite plane at coordinates 2,0 on the CRTC. It should look something like this: rotation=0 src: x1=0,y1=0,x2=4,y2=2 (w=4, h=2) dst: x1=2,y1=0,x2=6,y2=2 (w=4, h=2) FB:CRTC: 0,0 0,0 |abcd| | abcd | |efgh| | efgh | 4,2 || || 8,4 rotation=90 src=0,0 -> 4,2 (w=4, h=2) dst=2,0 -> 4,4 (w=2, h=4) FB:CRTC: 0,0 0,0 |abcd| | dh| |efgh| | cg| 4,2 | bf| | ae| 8,4 > >From the test, I don't really change the src sizes for primary as well as > >sprite to take care of 90/270 rotation. Sounds a bit buggy then. > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Wednesday, January 14, 2015 5:14 PM > To: Jindal, Sonika > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > drm_plane_helper_check_update > > On Wed, Jan 14, 2015 at 09:49:36AM +, Jindal, Sonika wrote: > > Since we do drm_rect_rotate with 90 rotation, the src->w changes to src->h. > > Now, when we call drm_rect_calc_hscale, the hscale calculated is lesser > > than the min_hscale (which is no_scaling by default), so it returns -ERANGE. > > If you want no scaling then with 90/270 rotation then your src->w should be > equal to dst->h. Then the calculated vscale will be 1.0. If it's not, then > your test is passing in bad coordinates. > > > So, I think we _relaxed is the function which should be called to update > > the destination size appropriately. > > Please correct me if I am wrong. > > > > -Original Message- > > From: Jindal, Sonika > > Sent: Wednesday, January 14, 2015 3:06 PM > > To: 'Ville Syrjälä' > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > Subject: RE: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > > drm_plane_helper_check_update > > > > We do exactly like this for sprite plane (ie, rotate the rect, then check > > scaling and adjust the size accordingly from drm_rect_calc_hscale_relaxed) > > That's why I saw the need of this for primary plane as well. > > For sprite plane 90 rotation, intel_check_sprite_plane does the adjustments > > and the rotated sizes are fine. But since we don't do any of those stuff > > for primary the destination size doesn't come right, and I get a little > > corrupted output after rotation. > > With this change, the rotated plane is properly adjusted in the viewport. > > So, I don't think it is a bug in test. > > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > > Sent: Wednesday, January 14, 2015 2:58 PM > > To: Jindal, Sonika > > Cc: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 1/2] drm: Adding rotation to > > drm_plane_helper_check_update > > > > On Wed, Jan 14, 2015 at 10:05:53AM +0530, sonika wrote: > > > > > > On Tuesday 13 January 2015 07:02 PM, Ville Syrjälä wrote: > > > > On Tue, Jan 13, 2015 at 06:03:39PM +0530, Sonika Jindal wrote: > > > >> Taking rotation into account while checking the plane and > > > >> adjusting the sizes accordingly. > > > >> > > > >> Signed-off-by: Sonika Jindal > > > >> --- > > > >> drivers/gpu/drm/drm_plane_helper.c | 79 > > > >> ++-- > > > >> include/drm/drm_plane_helper.h |3 +- > > > >> 2 files changed,
[PATCH 2/2] drm/msm/mdp5: Add hardware cursor support
On Tue, Jan 13, 2015 at 05:18:04PM -0500, Stephane Viau wrote:
> From: Beeresh Gopal
>
> This patch implements the hardware accelarated cursor
> support for MDP5 platforms.
>
> Signed-off-by: Beeresh Gopal
> Signed-off-by: Wentao Xu
> Signed-off-by: Stephane Viau
Imo implementing legacy cursor support instead of with universal planes
makes no sense. Especially since msm is converted to atomic already, and
you can't move the cursor with atomic when it's legacy only. See the
cursor argument for the drm_crtc_init_with_planes function and how it's
used in e.g. i915.
Cheers, Daniel
> ---
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 164
> +++
> 1 file changed, 164 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> index f021f96..2021f09 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
> @@ -24,6 +24,9 @@
> #include "drm_crtc_helper.h"
> #include "drm_flip_work.h"
>
> +#define CURSOR_WIDTH 64
> +#define CURSOR_HEIGHT 64
> +
> #define SSPP_MAX (SSPP_RGB3 + 1) /* TODO: Add SSPP_MAX in mdp5.xml.h */
>
> struct mdp5_crtc {
> @@ -47,8 +50,21 @@ struct mdp5_crtc {
> #define PENDING_FLIP 0x2
> atomic_t pending;
>
> + /* for unref'ing cursor bo's after scanout completes: */
> + struct drm_flip_work unref_cursor_work;
> +
> struct mdp_irq vblank;
> struct mdp_irq err;
> +
> + struct {
> + /* protect REG_MDP5_LM_CURSOR* registers and cursor scanout_bo*/
> + spinlock_t lock;
> +
> + /* current cursor being scanned out: */
> + struct drm_gem_object *scanout_bo;
> + uint32_t width;
> + uint32_t height;
> + } cursor;
> };
> #define to_mdp5_crtc(x) container_of(x, struct mdp5_crtc, base)
>
> @@ -129,11 +145,22 @@ static void complete_flip(struct drm_crtc *crtc, struct
> drm_file *file)
> }
> }
>
> +static void unref_cursor_worker(struct drm_flip_work *work, void *val)
> +{
> + struct mdp5_crtc *mdp5_crtc =
> + container_of(work, struct mdp5_crtc, unref_cursor_work);
> + struct mdp5_kms *mdp5_kms = get_kms(&mdp5_crtc->base);
> +
> + msm_gem_put_iova(val, mdp5_kms->id);
> + drm_gem_object_unreference_unlocked(val);
> +}
> +
> static void mdp5_crtc_destroy(struct drm_crtc *crtc)
> {
> struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
>
> drm_crtc_cleanup(crtc);
> + drm_flip_work_cleanup(&mdp5_crtc->unref_cursor_work);
>
> kfree(mdp5_crtc);
> }
> @@ -384,6 +411,132 @@ static int mdp5_crtc_set_property(struct drm_crtc *crtc,
> return -EINVAL;
> }
>
> +static int mdp5_crtc_cursor_set(struct drm_crtc *crtc,
> + struct drm_file *file, uint32_t handle,
> + uint32_t width, uint32_t height)
> +{
> + struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
> + struct drm_device *dev = crtc->dev;
> + struct mdp5_kms *mdp5_kms = get_kms(crtc);
> + struct drm_gem_object *cursor_bo, *old_bo;
> + uint32_t blendcfg, cursor_addr, stride;
> + int ret, bpp, lm;
> + unsigned int depth;
> + enum mdp5_cursor_alpha cur_alpha = CURSOR_ALPHA_PER_PIXEL;
> + uint32_t flush_mask = mdp_ctl_flush_mask_cursor(0);
> + unsigned long flags;
> +
> + if ((width > CURSOR_WIDTH) || (height > CURSOR_HEIGHT)) {
> + dev_err(dev->dev, "bad cursor size: %dx%d\n", width, height);
> + return -EINVAL;
> + }
> +
> + if (NULL == mdp5_crtc->ctl)
> + return -EINVAL;
> +
> + if (!handle) {
> + DBG("Cursor off");
> + return mdp5_ctl_set_cursor(mdp5_crtc->ctl, false);
> + }
> +
> + cursor_bo = drm_gem_object_lookup(dev, file, handle);
> + if (!cursor_bo)
> + return -ENOENT;
> +
> + ret = msm_gem_get_iova(cursor_bo, mdp5_kms->id, &cursor_addr);
> + if (ret)
> + return -EINVAL;
> +
> + lm = mdp5_crtc->lm;
> + drm_fb_get_bpp_depth(DRM_FORMAT_ARGB, &depth, &bpp);
> + stride = width * (bpp >> 3);
> +
> + spin_lock_irqsave(&mdp5_crtc->cursor.lock, flags);
> + old_bo = mdp5_crtc->cursor.scanout_bo;
> +
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_STRIDE(lm), stride);
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_FORMAT(lm),
> + MDP5_LM_CURSOR_FORMAT_FORMAT(CURSOR_FMT_ARGB));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_IMG_SIZE(lm),
> + MDP5_LM_CURSOR_IMG_SIZE_SRC_H(height) |
> + MDP5_LM_CURSOR_IMG_SIZE_SRC_W(width));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_SIZE(lm),
> + MDP5_LM_CURSOR_SIZE_ROI_H(height) |
> + MDP5_LM_CURSOR_SIZE_ROI_W(width));
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BASE_ADDR(lm), cursor_addr);
> +
> +
> + blendcfg = MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_EN;
> + blendcfg |= MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_TRANSP_EN;
> + blendcfg |= MDP5_LM_CURSOR_BLEND_CONFIG_BLEND_ALPHA_SEL(cur_alpha);
> + mdp5_write(mdp5_kms, REG_MDP5_LM_CURSOR_BLEND_CONFIG(lm), blendcfg);
> +
> + mdp5_crtc->cursor.scanout_bo = cursor_bo;
> + mdp5_crtc->cursor.width = width;
> + mdp5_crtc->cursor.height = height;
> + spin_unlock_irqrestore(&mdp5_crtc->cursor.lock, flags);
> +
> + ret = mdp5_ctl_set_cursor(mdp5_crtc->ctl, true);
> + if (ret)
> + goto end;
> +
> + flush_mask |= mdp5_ctl_get_flush(mdp5_crtc->ctl
[Bug 88408] Black screen in Nuclear Dawn
https://bugs.freedesktop.org/show_bug.cgi?id=88408 --- Comment #2 from Michel Dänzer --- Can you create an apitrace which reproduces the problem? -- 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/20150115/35a101f8/attachment-0001.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #228 from Michel Dänzer --- (In reply to Andrew from comment #227) > The monitor switches repeatedly: no signal/black screen/no signal/black > screen/... In wine starcraft 2 with gallium nine 100% repeatability(7 of 7 > launches). That's not a random crash but a reproducible one, probably a Mesa bug. Please file a separate report for that. -- 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/20150115/fe1468e2/attachment.html>
Softlockup on boot with Cape Verde XT on many kernels
How about this? It seems at least related. https://github.com/alterapraxisptyltd/openatom/issues/1 Quote: [linux] Infinite loop in pci_get_rom_size() This is one of those issues that you find when putting supposedly stable code through unusual situations. I did expect any function in linux that is not part of radeon.ko to not be rock solid. Turns out that's not really the case. If we have a PCIR structure with a zero size length, the loop iterating through those structure does not advance. It simply does "image += readw(pds + 16) * 512;", but if that field is zero we're back analyzing the same structure on the next loop. The way to get out of this loop is to set bit 7 of the type field. That's what 'last_image' does. If that bit is not set, with the above, that's an infinite loop. Luckily, it doesn't crash the kernel, but it hangs any driver that calls the function under said circumstances. No more modprobe -r or unbinding. Reboot is needed. No idea why a firmware blob here is treated as trusted input. 2015-01-15 0:14 GMT-03:00 Federico : > Also just tried *enabling* the IGP and keeping PEG as the primary > graphics. Video output stayed on the discrete card output and the same > stack trace happened when booting without nomodeset. So now I'm back to > setting it as disabled as it had been before. > > > 2015-01-14 23:59 GMT-03:00 Federico : > > AFAIK this BIOS requires me to disable IGP to even use the discrete >> graphics. At least that's the first thing I had to do when I first >> installed the card and every time I wanted to change the monitor connection. >> Here's how "disabled" it is: >> >> >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298792/+files/20150114_234953.png >> >> >> 2015-01-14 23:46 GMT-03:00 Michel Dänzer : >> >> On 15.01.2015 11:10, Federico wrote: >>> > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using >>> > softlockup_panic=1. >>> > >>> > Quite similar, but slightly different. Hopefully, useful. >>> > >>> > >>> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png >>> >>> Looks like it hangs while reading the video BIOS ROM. >>> >>> If the integrated GPU is still enabled in the system BIOS setup, does >>> disabling it avoid the problem? >>> >>> >>> -- >>> Earthling Michel Dänzer | http://www.amd.com >>> Libre software enthusiast | Mesa and X developer >>> >> >> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150115/765596e3/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #227 from Andrew --- The monitor switches repeatedly: no signal/black screen/no signal/black screen/... In wine starcraft 2 with gallium nine 100% repeatability(7 of 7 launches). Sorry for my English. -- 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/20150115/13ab7ddf/attachment.html>
Softlockup on boot with Cape Verde XT on many kernels
Also just tried *enabling* the IGP and keeping PEG as the primary graphics. Video output stayed on the discrete card output and the same stack trace happened when booting without nomodeset. So now I'm back to setting it as disabled as it had been before. 2015-01-14 23:59 GMT-03:00 Federico : > AFAIK this BIOS requires me to disable IGP to even use the discrete > graphics. At least that's the first thing I had to do when I first > installed the card and every time I wanted to change the monitor connection. > Here's how "disabled" it is: > > > https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298792/+files/20150114_234953.png > > > 2015-01-14 23:46 GMT-03:00 Michel Dänzer : > > On 15.01.2015 11:10, Federico wrote: >> > Here's the 3.18 32-bits 60 lines per screen stack trace. Always using >> > softlockup_panic=1. >> > >> > Quite similar, but slightly different. Hopefully, useful. >> > >> > >> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1386973/+attachment/4298769/+files/20150114_230142.png >> >> Looks like it hangs while reading the video BIOS ROM. >> >> If the integrated GPU is still enabled in the system BIOS setup, does >> disabling it avoid the problem? >> >> >> -- >> Earthling Michel Dänzer | http://www.amd.com >> Libre software enthusiast | Mesa and X developer >> > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150115/18b55f86/attachment.html>
[Bug 87796] radeonsi 120Hz graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=87796 --- Comment #16 from Clésio Luiz --- I didn't compiled the driver myself, got it from a repository. I'm afraid that applying a patch and compile the driver is out of my knowledge... But I'm more than happy to follow instructions. -- 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/20150115/df2c9c6f/attachment-0001.html>
