[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 saadnaji89 at gmail.com changed: What|Removed |Added CC||saadnaji89 at gmail.com --- Comment #51 from saadnaji89 at gmail.com --- Hello, I am runnig Manjaro (Arch based distro 64 bit) with Kernel 3.13.5 as right now and I am having the same error except that I am geting repetitive blocks in the kernel log like this ever certain amount of time: 03/02/14 06:59:12 PM[drm] ring test on 0 succeeded in 2 usecs 03/02/14 06:59:12 PM[drm] ring test on 1 succeeded in 1 usecs 03/02/14 06:59:12 PM[drm] ring test on 2 succeeded in 1 usecs 03/02/14 06:59:12 PM[drm] ring test on 3 succeeded in 2 usecs 03/02/14 06:59:12 PM[drm] ring test on 4 succeeded in 1 usecs 03/02/14 06:59:12 PM[drm] ring test on 5 succeeded in 2 usecs 03/02/14 06:59:12 PM[drm] UVD initialized successfully. 03/02/14 06:59:12 PM[drm] Enabling audio 0 support 03/02/14 06:59:12 PM[drm] Enabling audio 1 support 03/02/14 06:59:12 PM[drm] Enabling audio 2 support 03/02/14 06:59:12 PM[drm] Enabling audio 3 support 03/02/14 06:59:12 PM[drm] Enabling audio 4 support 03/02/14 06:59:12 PM[drm] Enabling audio 5 support 03/02/14 06:59:12 PM[drm] ib test on ring 0 succeeded in 0 usecs 03/02/14 06:59:12 PM[drm] ib test on ring 1 succeeded in 0 usecs 03/02/14 06:59:12 PM[drm] ib test on ring 2 succeeded in 0 usecs 03/02/14 06:59:12 PM[drm] ib test on ring 3 succeeded in 0 usecs 03/02/14 06:59:12 PM[drm] ib test on ring 4 succeeded in 0 usecs 03/02/14 06:59:12 PM[drm] ib test on ring 5 succeeded 03/02/14 06:59:48 PM[drm] Disabling audio 0 support 03/02/14 06:59:48 PM[drm] Disabling audio 1 support 03/02/14 06:59:48 PM[drm] Disabling audio 2 support 03/02/14 06:59:48 PM[drm] Disabling audio 3 support 03/02/14 06:59:48 PM[drm] Disabling audio 4 support 03/02/14 06:59:48 PM[drm] Disabling audio 5 support and this is causing freeze for my laptop for 2-3 seconds, as well as causing the temperature of the gpu to raise up by 10 C . This bug was not present in prior 3.13 kernel -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #52 from saadnaji89 at gmail.com --- Created attachment 127801 --> https://bugzilla.kernel.org/attachment.cgi?id=127801&action=edit kenrel log -- You are receiving this mail because: You are watching the assignee of the bug.
Are you ready to see her satisfied today?
Keep your gf contented this night http://isthmus.mwuylppp.net/
[Bug 74712] libkms not enabled on DragonFly
https://bugs.freedesktop.org/show_bug.cgi?id=74712 Francois Tigeot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Francois Tigeot --- Patch pushed to libdrm -- 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/20140303/2e4cabfc/attachment.html>
[Bug 71461] New: monitor doesn't get detected after boot
https://bugzilla.kernel.org/show_bug.cgi?id=71461 Bug ID: 71461 Summary: monitor doesn't get detected after boot Product: Drivers Version: 2.5 Kernel Version: 3.13.5 Hardware: All 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: tom.ty89 at gmail.com Regression: No My card is Radeon HD5850. The result might varies between different boot. Either the screens would not be detected at all or they seem to be detected with a non-optimal resolution (in console, while gdm shows a broken screen) If a monitor is connected before boot, others can get detected correctly afterwards. If only one monitor is connected, turning it off can make the signal lost. Reboot or suspend/resume (after turning it on again) can bring the signal back. (Yet dpms would cause no problem at all) The only way to reproduce the problem if DVI is involved is to disconnect it physically, otherwise only powering off the monitor is required. My guess is DVI detects display with a different mechanism. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #53 from Michel D?nzer --- (In reply to saadnaji89 from comment #51) > I am runnig Manjaro (Arch based distro 64 bit) with Kernel 3.13.5 as right > now and I am having the same error except that I am geting repetitive blocks > in the kernel log like this ever certain amount of time: See comment #35. > and this is causing freeze for my laptop for 2-3 seconds, as well as causing > the temperature of the gpu to raise up by 10 C . You probably need my Mesa patch to prevent the GPU from powering up needlessly: https://bugzilla.kernel.org/attachment.cgi?id=126011 -- You are receiving this mail because: You are watching the assignee of the bug.
i915 - Corruption on boot for 3.13.x
On Fri, 28 Feb 2014, Matthew Thode wrote: > Hardware is a T520 with a i5-2520M (intel only). > > Booting via uefi stub, kernel config is attached. > > This is broken on 3.13.x the video shows hardened kernel being booted, > but I've tested kernel.org sources as well with the same effect. > > I can boot, login and shutdown, etc; just graphics is broken. > > https://www.youtube.com/watch?v=yxDyvyJTrXs > > Think that's it, let me know if there's more info I can get you. Hi Matthew, thanks for the report. Please file a bug on DRM/Intel component at [1]. Just because my gut feeling says this will be better tracked there than by cluttering the list... On the bug, please indicate: Did this use to work? Which kernel version? Please disable i915.ko and see if there's still corruption in the fb. It's hard to see from the video whether the corruption starts before i915 gets loaded. Please attach dmesg from early boot with drm.debug=0xe module parameter set. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI -- Jani Nikula, Intel Open Source Technology Center
[Bug 75699] New: mplayer crashes
https://bugs.freedesktop.org/show_bug.cgi?id=75699 Priority: medium Bug ID: 75699 Assignee: dri-devel at lists.freedesktop.org Summary: mplayer crashes Severity: normal Classification: Unclassified OS: Linux (All) Reporter: slash at ac.auone-net.jp Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 95013 --> https://bugs.freedesktop.org/attachment.cgi?id=95013&action=edit backtrace If I play any file with mplayer -vo vdpau -vf flip, it crashes with sigsegv instantly. -- 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/20140303/5756f235/attachment.html>
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #5 from Michel D?nzer --- Please try getting more information about the leak(s) with valgrind --leak-check=full. -- 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/20140303/fb369357/attachment.html>
[PATCH 00/11] SimpleDRM & Sysfb
Hi On Mon, Mar 3, 2014 at 11:12 AM, Tomi Valkeinen wrote: > Hi, > > On 23/01/14 16:14, David Herrmann wrote: >> Hi >> >> Another round of SimpleDRM patches. I somehow lost track of the last ones >> and as >> this is a major rewrite, I'll just start at v1 again. >> >> Some comments up-front: >> >> - @Ingo: Patch #1 and #2 are unchanged from the previous ML discussions. I >>included them in this series as the other patches depend on them. Could >> you >>pick them up for the x86 tree? The other 9 patches won't make it in 3.14 >> so >>no reason to put them through the DRM tree. >>All mentioned issues should be addressed. If there's still sth missing, >>please let me know. >> >> - The DRM patches depend on my "DRM Anonymous Inode" patches. But it should >> be >>trivial to apply them on drm-next (I think only one line needs to be >> changed: >>i_mapping => dev_mapping). >> >> - I tested the SimpleDRM fbdev fallback with linux-console+Xorg and it works >>fine. The DRM backend is only tested with some DRM tests I have locally. I >>have no idea how to make Xorg pick up a specific /dev/dri/card0 card. It >>always tells me "no screens found" (as the underlying device is not >> marked as >>boot_vga..). If someone knows how to tell Xorg to use card0, I'd gladly >> test >>this. But I'm no longer used to writing xorg.confs.. >> >> >> This series introduces two new concepts: sysfb and SimpleDRM >> Sysfb is just a generalization of the x86-sysfb concept. It allows to >> register >> firmware-framebuffers with the system as platform-devices. This way, drivers >> can >> properly bind to these devices and we prevent multiple drivers from accessing >> the same firmware-framebuffer. >> Sysfb also provides hooks to get a safe handover to real hw-drivers (like >> i915). >> Please see the "video: sysfb: add generic firmware-fb interface" patch for a >> thorough description of the API. This patch also adds a rather verbose >> documentation of all known firmware-fb facilities. >> >> As second part, this series introduces SimpleDRM. It's a very basic DRM >> driver >> that can replace efifb, vesafb, simplefb and friends. It's 100% compatible to >> the "udl" DRM driver, so user-space like xf86-video-modesetting can pick >> them up >> just fine. User-space that cannot deal with drmModeDirtyFB() (like weston and >> friends) currently cannot use SimpleDRM. However, that's also true for all >> other >> DRM drivers which provide shadow framebuffers. We could provide something >> like >> FB-DEFIO, but that's just useless overhead to paper of lazy user-space. >> >> I have tested this with all hardware that I have at home, with a lot >> hand-over >> combinations (with/without SYSFB, with efifb/vesafb/simplefb, with SimpleDRM, >> ...) and all worked great so far. > > What's the status with this one? Headed for 3.15? > > Are the SimpleDRM and sysfb linked somehow? (I.e. do they need to be in > the same series?) > > And jfyi, the drivers/video/ changes will conflict with the > drivers/video/ directory reorganization series, which may be merged for > 3.15. If simpledrm is included, then the series needs to be applied as a whole. As Dave considered merging this for 3.15, I'd appreciate it if you could ACK the fbdev related patches (they're really small!): fbdev: efifb: add dev->remove() callback fbdev: vesafb: add dev->remove() callback Thanks David
[PATCH 00/11] SimpleDRM & Sysfb
Hi On Mon, Mar 3, 2014 at 11:45 AM, Tomi Valkeinen wrote: > On 03/03/14 12:29, David Herrmann wrote: > >>> What's the status with this one? Headed for 3.15? >>> >>> Are the SimpleDRM and sysfb linked somehow? (I.e. do they need to be in >>> the same series?) >>> >>> And jfyi, the drivers/video/ changes will conflict with the >>> drivers/video/ directory reorganization series, which may be merged for >>> 3.15. >> >> If simpledrm is included, then the series needs to be applied as a >> whole. As Dave considered merging this for 3.15, I'd appreciate it if >> you could ACK the fbdev related patches (they're really small!): >> fbdev: efifb: add dev->remove() callback >> fbdev: vesafb: add dev->remove() callback > > Those look fine. > > I'm not familiar with x86 fb, so I can't comment much to the series, but > what worries me more is the "[PATCH 06/11] video: sysfb: add generic > firmware-fb interface", which adds new stuff into drivers/video/. No > problem as such, but as said, it'll conflict with the fbdev reorg patches. > > So, presuming nobody shoots down the fbdev reorg series, I'd like to > have all fbdev patches going through the fbdev tree for 3.15, so that I > can handle the (possibly messy) conflicts. > > What do you think, would it be possible to keep the sysfb stuff in > arch/x86, and still be able to do the rest of the stuff here? And then > move the sysfs from arch/x86 to drivers/video later? I don't think there's any need for that. Linus does conflict resolution all day long, so a short hint in Dave's pull-request (plus an example merge) should be enough. Same is true for -next, I think. And this is really just a mechanical thing, nothing hard to do. But of course, it's your decision. However, keeping the code in x86 is the wrong thing to do. As discussed with Ingo, the patch that extends x86/sysfb is only provided for easier backporting. The followup patch immediately removes it again and adds proper video/sysfb. I'd dislike splitting these just to avoid merge conflicts. I can also maintain a merge-fixup branch in my tree, if anyone wants that. Thanks for your reviews of the fbdev stuff! David
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #6 from Chris Rankin --- (In reply to comment #5) > Please try getting more information about the leak(s) with valgrind > --leak-check=full. Do I need to do anything "special" to valgrind WoW.exe, seeing as it must be invoked using wine? -- 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/20140303/c710729c/attachment.html>
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 Tom Yan changed: What|Removed |Added Summary|monitor doesn't get |monitor doesn't get |detected after boot |detected after boot or ||disconnection -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #1 from Tom Yan --- The card has 4 connectors: 1 HDMI, 1 DisplayPort and 2 DVI -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon: remove struct radeon_bo_list
From: Christian K?nig
Just move all fields into radeon_cs_reloc, removing unused/duplicated fields.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/evergreen_cs.c | 210 -
drivers/gpu/drm/radeon/r100.c | 40 +++
drivers/gpu/drm/radeon/r200.c | 20 ++--
drivers/gpu/drm/radeon/r300.c | 32 ++---
drivers/gpu/drm/radeon/r600_cs.c | 110 -
drivers/gpu/drm/radeon/radeon.h| 24 ++--
drivers/gpu/drm/radeon/radeon_cs.c | 23 ++--
drivers/gpu/drm/radeon/radeon_object.c | 4 +-
drivers/gpu/drm/radeon/radeon_uvd.c| 2 +-
drivers/gpu/drm/radeon/radeon_vce.c| 2 +-
drivers/gpu/drm/radeon/radeon_vm.c | 22 ++--
11 files changed, 244 insertions(+), 245 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index c7cac07..5c8b358 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -1165,7 +1165,7 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser
*p, u32 reg, u32 idx)
"0x%04X\n", reg);
return -EINVAL;
}
- ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+ ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
break;
case DB_DEPTH_CONTROL:
track->db_depth_control = radeon_get_ib_value(p, idx);
@@ -1196,12 +1196,12 @@ static int evergreen_cs_check_reg(struct
radeon_cs_parser *p, u32 reg, u32 idx)
}
ib[idx] &= ~Z_ARRAY_MODE(0xf);
track->db_z_info &= ~Z_ARRAY_MODE(0xf);
- ib[idx] |=
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
- track->db_z_info |=
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
- if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
+ ib[idx] |=
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->tiling_flags));
+ track->db_z_info |=
Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->tiling_flags));
+ if (reloc->tiling_flags & RADEON_TILING_MACRO) {
unsigned bankw, bankh, mtaspect, tile_split;
-
evergreen_tiling_fields(reloc->lobj.tiling_flags,
+ evergreen_tiling_fields(reloc->tiling_flags,
&bankw, &bankh,
&mtaspect,
&tile_split);
ib[idx] |=
DB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
@@ -1237,7 +1237,7 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser
*p, u32 reg, u32 idx)
return -EINVAL;
}
track->db_z_read_offset = radeon_get_ib_value(p, idx);
- ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+ ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
track->db_z_read_bo = reloc->robj;
track->db_dirty = true;
break;
@@ -1249,7 +1249,7 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser
*p, u32 reg, u32 idx)
return -EINVAL;
}
track->db_z_write_offset = radeon_get_ib_value(p, idx);
- ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+ ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
track->db_z_write_bo = reloc->robj;
track->db_dirty = true;
break;
@@ -1261,7 +1261,7 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser
*p, u32 reg, u32 idx)
return -EINVAL;
}
track->db_s_read_offset = radeon_get_ib_value(p, idx);
- ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+ ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
track->db_s_read_bo = reloc->robj;
track->db_dirty = true;
break;
@@ -1273,7 +1273,7 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser
*p, u32 reg, u32 idx)
return -EINVAL;
}
track->db_s_write_offset = radeon_get_ib_value(p, idx);
- ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
+ ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
track->db_s_write_bo = reloc->robj;
track->db_dirty = true;
break;
@@ -1297,7 +1297,7 @@ static int evergreen_cs_check_reg(struct radeon_cs_parser
*p, u32 reg, u32 idx)
}
tmp = (reg - VGT_STRMOUT_BUFFER_BASE_0) / 16;
[RFC PATCH 0/3] drm/exynos: more cleanup with super device support
This patch series cleans up exynos drm framework and kms sub drivers using the component framework[1]. This is based on top of below Andrezej's patch series[2]. And you can find git repository related to this patch series below, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo We have patch sets not posted yet and these patch sets will be posted by Andrezej Hajda and Tomasz Stanislawski soon. So this cleanup series would be rebased on top of them again. This post is just for RFC. Thanks, Inki Dae [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html [2] http://comments.gmane.org/gmane.linux.kernel.samsung-soc/27044 Inki Dae (3): drm/exynos: fix unnecessary resource cleanup drm/exynos: add super device support drm/exynos: register platform driver at each kms sub drivers drivers/gpu/drm/exynos/exynos_dp_core.c | 46 -- drivers/gpu/drm/exynos/exynos_drm_core.c | 204 +-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 ++ drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 + drivers/gpu/drm/exynos/exynos_drm_drv.c | 266 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 57 ++- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 49 -- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 49 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 61 +-- drivers/gpu/drm/exynos/exynos_hdmi.c | 47 -- drivers/gpu/drm/exynos/exynos_mixer.c| 55 -- 11 files changed, 376 insertions(+), 479 deletions(-) -- 1.7.9.5
[RFC PATCH 1/3] drm/exynos: fix unnecessary resource cleanup
This patch removes unnecessary drm_mode_config_cleanup call.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cba25b1..de010b1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -66,7 +66,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
ret = drm_create_iommu_mapping(dev);
if (ret < 0) {
DRM_ERROR("failed to create iommu mapping.\n");
- goto err_crtc;
+ goto err_free_private;
}
drm_mode_config_init(dev);
@@ -124,8 +124,7 @@ err_manager_cleanup:
err_mode_config_cleanup:
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);
-err_crtc:
- drm_mode_config_cleanup(dev);
+err_free_private:
kfree(private);
return ret;
--
1.7.9.5
[RFC PATCH 2/3] drm/exynos: add super device support
This patch adds super device support to bind sub drivers
using device tree.
For this, we should add a super device node to each machine dt files
like below example,
exynos-drm {
crtcs = <&fimd>;
connectors = <&dsi>;
};
crtcs propery can declare crtc device nodes, fimd and mixer.
And connectors propery can declare connector device nodes, MIPI-DSI,
eDP, and HDMI.
With this patch, we can resolve the probing order issue without
some lists. So this patch also removes unnecessary lists and
stuff related to these lists.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 45 ---
drivers/gpu/drm/exynos/exynos_drm_core.c | 204 +
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 17 +++
drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 209 --
drivers/gpu/drm/exynos/exynos_drm_drv.h | 57 +++-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 48 ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 48 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 61 +++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 46 ---
drivers/gpu/drm/exynos/exynos_mixer.c| 54 ++--
11 files changed, 374 insertions(+), 419 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index a59bca9..cb9aa58 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
};
-static int exynos_dp_initialize(struct exynos_drm_display *display,
- struct drm_device *drm_dev)
-{
- struct exynos_dp_device *dp = display->ctx;
-
- dp->drm_dev = drm_dev;
-
- return 0;
-}
-
static bool find_bridge(const char *compat, struct bridge_init *bridge)
{
bridge->client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display
*display, int mode)
}
static struct exynos_drm_display_ops exynos_dp_display_ops = {
- .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
};
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct
exynos_dp_device *dp)
return 0;
}
-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void
*data)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct drm_device *drm_dev = data;
struct resource *res;
struct exynos_dp_device *dp;
@@ -1293,21 +1285,40 @@ static int exynos_dp_probe(struct platform_device *pdev)
}
disable_irq(dp->irq);
+ dp->drm_dev = drm_dev;
exynos_dp_display.ctx = dp;
platform_set_drvdata(pdev, &exynos_dp_display);
- exynos_drm_display_register(&exynos_dp_display);
- return 0;
+ return exynos_drm_create_enc_conn(drm_dev, &exynos_dp_display);
}
-static int exynos_dp_remove(struct platform_device *pdev)
+static void exynos_dp_unbind(struct device *dev, struct device *master,
+ void *data)
{
- struct exynos_drm_display *display = platform_get_drvdata(pdev);
+ struct exynos_drm_display *display = dev_get_drvdata(dev);
+ struct exynos_dp_device *dp = display->ctx;
+ struct drm_encoder *encoder = dp->encoder;
exynos_dp_dpms(display, DRM_MODE_DPMS_OFF);
- exynos_drm_display_unregister(&exynos_dp_display);
+ encoder->funcs->destroy(encoder);
+ drm_connector_cleanup(&dp->connector);
+}
+
+static const struct component_ops exynos_dp_ops = {
+ .bind = exynos_dp_bind,
+ .unbind = exynos_dp_unbind,
+};
+
+static int exynos_dp_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &exynos_dp_ops);
+}
+
+static int exynos_dp_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &exynos_dp_ops);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 0e9e06c..a0a467f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -19,21 +19,19 @@
#include "exynos_drm_fbdev.h"
static LIST_HEAD(exynos_drm_subdrv_list);
-static LIST_HEAD(exynos_drm_manager_list);
-static LIST_HEAD(exynos_drm_display_list);
-static int exynos_drm_create_enc_conn(struct drm_device *dev,
+int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display)
{
struct drm_encoder *encoder;
- struct exynos_drm_manager *manager;
[RFC PATCH 3/3] drm/exynos: register platform driver at each kms sub drivers
This patch removes platform_driver_register() calls from
exynos_drm_drv module, and call module_platform_driver()
at each kms sub drivers instead.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_dp_core.c |1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 62 --
drivers/gpu/drm/exynos/exynos_drm_dsi.c |1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c |1 +
drivers/gpu/drm/exynos/exynos_hdmi.c |1 +
drivers/gpu/drm/exynos/exynos_mixer.c|1 +
6 files changed, 5 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index cb9aa58..bf4996f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1362,6 +1362,7 @@ struct platform_driver dp_driver = {
.of_match_table = exynos_dp_match,
},
};
+module_platform_driver(dp_driver);
MODULE_AUTHOR("Jingoo Han ");
MODULE_DESCRIPTION("Samsung SoC DP Driver");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 9156a73..2f88bc5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -468,33 +468,6 @@ static int exynos_drm_platform_probe(struct
platform_device *pdev)
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
-#ifdef CONFIG_DRM_EXYNOS_DP
- ret = platform_driver_register(&dp_driver);
- if (ret < 0)
- goto out_dp;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
- ret = platform_driver_register(&dsi_driver);
- if (ret < 0)
- goto out_dsi;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
- ret = platform_driver_register(&fimd_driver);
- if (ret < 0)
- goto out_fimd;
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_HDMI
- ret = platform_driver_register(&hdmi_driver);
- if (ret < 0)
- goto out_hdmi;
- ret = platform_driver_register(&mixer_driver);
- if (ret < 0)
- goto out_mixer;
-#endif
-
#ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(&g2d_driver);
if (ret < 0)
@@ -564,25 +537,6 @@ out_fimc:
out_g2d:
#endif
-#ifdef CONFIG_DRM_EXYNOS_HDMI
- platform_driver_unregister(&mixer_driver);
-out_mixer:
- platform_driver_unregister(&hdmi_driver);
-out_hdmi:
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
- platform_driver_unregister(&fimd_driver);
-out_fimd:
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DSI
- platform_driver_unregister(&dsi_driver);
-out_dsi:
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DP
- platform_driver_unregister(&dp_driver);
-out_dp:
-#endif
return ret;
}
@@ -609,22 +563,6 @@ static int exynos_drm_platform_remove(struct
platform_device *pdev)
platform_driver_unregister(&g2d_driver);
#endif
-#ifdef CONFIG_DRM_EXYNOS_HDMI
- platform_driver_unregister(&mixer_driver);
- platform_driver_unregister(&hdmi_driver);
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_FIMD
- platform_driver_unregister(&fimd_driver);
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DSI
- platform_driver_unregister(&dsi_driver);
-#endif
-
-#ifdef CONFIG_DRM_EXYNOS_DP
- platform_driver_unregister(&dp_driver);
-#endif
component_master_del(&pdev->dev, &exynos_drm_ops);
return 0;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 89e8585..a54149c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1413,6 +1413,7 @@ struct platform_driver dsi_driver = {
.of_match_table = exynos_dsi_of_match,
},
};
+module_platform_driver(dsi_driver);
MODULE_AUTHOR("Tomasz Figa ");
MODULE_AUTHOR("Andrzej Hajda ");
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 8d41288..ea73d5a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -974,3 +974,4 @@ struct platform_driver fimd_driver = {
.of_match_table = fimd_driver_dt_match,
},
};
+module_platform_driver(fimd_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 712ce2d..12fdf55 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2108,3 +2108,4 @@ struct platform_driver hdmi_driver = {
.of_match_table = hdmi_match_types,
},
};
+module_platform_driver(hdmi_driver);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d46a262..12ef887 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1292,3 +1292,4 @@ struct platform_driver mixer_driver = {
.remove = mixer_remove,
.id_table = mixer_drive
[Bug 31230] [RADEON:KMS:RV250:RESUME] corrupted screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=31230 --- Comment #4 from dplasa --- Here'a some images of my corrupted screen: http://pl.vc/26q6c http://pl.vc/2k7t5 http://pl.vc/4zpqm -- 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/20140303/9289d79f/attachment.html>
Intel HD Graphics 4000 - hard lockups
On Sat, 01 Mar 2014, Daniel Kasak wrote: > Hi all. > > I've had quite a decent run with stability on my laptop, until recently. > I've been running realtime kernels for audio work, and up to 3.10.6-rt3, > it's been rock solid. After this, something has gone horribly wrong. I get > hard lockups from anything later I've built ( 3.12.10-rt15 and 3.12.11-rt17 > ). Sometimes it won't lock up right away, but will pause for a long period, > and when it starts responding again ( dropping to console, and back into X > will sometimes free it ) shows a bunch of 'stuck in render loop' / 'render > ring' ... or something ... kind of errors. I have followed instructions to > get more info on this if someone wants it. > > Chrome seems to trigger lockups more than other things. I run a 3D > composited desktop ( Enlightenment-0.19 dev builds ), but I've tried with > Gnome-3.10 and this also gives lockups. I currently have mesa-10.0.3. > > What can I do to try to debug this? Often, the magic sysrq keys don't > respond, but *occasionally* I can at least do an emergency sync. > > Switching back to 3.10.6-rt3 makes things *rock* solid, but for various > reasons, I'd like to get to at least 3.12.x ( other driver issues ). > > What's the state of Intel DRM drivers in the kernel? Should I be avoiding > building from the kernel, and using a git branch? Are there known issues > with the realtime patches? > > Any help appreciated. I think the first step would be to try vanilla non-rt kernels, maybe a kernel matching what you've tried, or the latest v3.13 or v3.14-rc's. It will be easier to proceed from there depending on the outcome. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #7 from Nick Tenney --- I found this helpful for setting up wine and valgrind together: http://wiki.winehq.org/Wine_and_Valgrind You may need to recompile wine after installing valgrind, as mentioned in the wiki. For a similar issue in Diablo III, I could not get the game to run with valgrind, so I used apitrace to record a session and ran valgrind on the trace (after much help from Michel and Ilia). Hope this helps. Oh, make sure to compile Mesa with debug symbols or you'll need to repeat the whole process. I forgot that the first time 'round. -- 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/20140303/f49edecf/attachment.html>
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #8 from Chris Rankin --- (In reply to comment #7) > You may need to recompile wine after installing valgrind, as mentioned in > the wiki. There is no "re"-compile of wine - it either works with Fedora's debuginfo package or it doesn't. -- 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/20140303/490162f1/attachment.html>
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- Please attach your xorg log and dmesg output in the working and non-working cases. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75719] New: mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 Priority: medium Bug ID: 75719 Assignee: dri-devel at lists.freedesktop.org Summary: mplayer -vo gl consume more CPU on r200 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: smoki00790 at gmail.com Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI OS is current Debian Sid 32bit, card 1002:5960... So this is on r200 i spotted playing any video file vith gl render (but also many videos in games are also affected), bisecting says it started with this code in ttm: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=a095c60bd06f204c98527aafd5fda6ef42b53eb5 And it performs the same also in 3.14-rc5 kernel :). It consume cca 40% or more CPU power after that commit... that *more* depends on video file and if it is in game or playing video file with mplayer -vo gl. Mesa version seems doesn't metter i tried 9.2 git, 10.0 git, 10.1 git and current git master. -- 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/20140303/fa82ffe8/attachment.html>
[PATCH] drm/radeon: remove struct radeon_bo_list
On Mon, Mar 3, 2014 at 8:10 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Just move all fields into radeon_cs_reloc, removing unused/duplicated fields.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 210
> -
> drivers/gpu/drm/radeon/r100.c | 40 +++
> drivers/gpu/drm/radeon/r200.c | 20 ++--
> drivers/gpu/drm/radeon/r300.c | 32 ++---
> drivers/gpu/drm/radeon/r600_cs.c | 110 -
> drivers/gpu/drm/radeon/radeon.h| 24 ++--
> drivers/gpu/drm/radeon/radeon_cs.c | 23 ++--
> drivers/gpu/drm/radeon/radeon_object.c | 4 +-
> drivers/gpu/drm/radeon/radeon_uvd.c| 2 +-
> drivers/gpu/drm/radeon/radeon_vce.c| 2 +-
> drivers/gpu/drm/radeon/radeon_vm.c | 22 ++--
> 11 files changed, 244 insertions(+), 245 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
> b/drivers/gpu/drm/radeon/evergreen_cs.c
> index c7cac07..5c8b358 100644
> --- a/drivers/gpu/drm/radeon/evergreen_cs.c
> +++ b/drivers/gpu/drm/radeon/evergreen_cs.c
> @@ -1165,7 +1165,7 @@ static int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u32 idx)
> "0x%04X\n", reg);
> return -EINVAL;
> }
> - ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> + ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> break;
> case DB_DEPTH_CONTROL:
> track->db_depth_control = radeon_get_ib_value(p, idx);
> @@ -1196,12 +1196,12 @@ static int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u32 idx)
> }
> ib[idx] &= ~Z_ARRAY_MODE(0xf);
> track->db_z_info &= ~Z_ARRAY_MODE(0xf);
> - ib[idx] |=
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
> - track->db_z_info |=
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->lobj.tiling_flags));
> - if (reloc->lobj.tiling_flags & RADEON_TILING_MACRO) {
> + ib[idx] |=
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->tiling_flags));
> + track->db_z_info |=
> Z_ARRAY_MODE(evergreen_cs_get_aray_mode(reloc->tiling_flags));
> + if (reloc->tiling_flags & RADEON_TILING_MACRO) {
> unsigned bankw, bankh, mtaspect, tile_split;
>
> -
> evergreen_tiling_fields(reloc->lobj.tiling_flags,
> + evergreen_tiling_fields(reloc->tiling_flags,
> &bankw, &bankh,
> &mtaspect,
> &tile_split);
> ib[idx] |=
> DB_NUM_BANKS(evergreen_cs_get_num_banks(track->nbanks));
> @@ -1237,7 +1237,7 @@ static int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u32 idx)
> return -EINVAL;
> }
> track->db_z_read_offset = radeon_get_ib_value(p, idx);
> - ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> + ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> track->db_z_read_bo = reloc->robj;
> track->db_dirty = true;
> break;
> @@ -1249,7 +1249,7 @@ static int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u32 idx)
> return -EINVAL;
> }
> track->db_z_write_offset = radeon_get_ib_value(p, idx);
> - ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> + ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> track->db_z_write_bo = reloc->robj;
> track->db_dirty = true;
> break;
> @@ -1261,7 +1261,7 @@ static int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u32 idx)
> return -EINVAL;
> }
> track->db_s_read_offset = radeon_get_ib_value(p, idx);
> - ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> + ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> track->db_s_read_bo = reloc->robj;
> track->db_dirty = true;
> break;
> @@ -1273,7 +1273,7 @@ static int evergreen_cs_check_reg(struct
> radeon_cs_parser *p, u32 reg, u32 idx)
> return -EINVAL;
> }
> track->db_s_write_offset = radeon_get_ib_value(p, idx);
> - ib[idx] += (u32)((reloc->lobj.gpu_offset >> 8) & 0x);
> + ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
> track->d
[Bug 75491] Radeon HD7750 no Monitors connected
https://bugs.freedesktop.org/show_bug.cgi?id=75491 --- Comment #8 from Eric Gr?ttefien --- > Maybe they are too cheap and don't properly connect the ddc wires or pull > the right pins down. I've open one cable you seem be right. DDC alias AUX CH+/- seems not to be connected. Cable Adaptor Detect alias Config 1 I' have still to check. They are passive ones using a NPX/Phillips PTN3361B level shifter. I will fix the cable and report back. Thank you very much for the hint. -- 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/20140303/f2f66eb8/attachment.html>
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #3 from Tom Yan --- Created attachment 127881 --> https://bugzilla.kernel.org/attachment.cgi?id=127881&action=edit dmesg (monitor off when boot, not work when turn on afterwards) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #4 from Tom Yan --- Created attachment 127891 --> https://bugzilla.kernel.org/attachment.cgi?id=127891&action=edit dmesg (monitor on when boot, working before off) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #5 from Tom Yan --- Created attachment 127901 --> https://bugzilla.kernel.org/attachment.cgi?id=127901&action=edit dmesg (monitor on when boot, turn off afterwards) `diff on_at_start off_afterwards` 858a859 > [ 49.713776] pci_pm_runtime_suspend(): > radeon_pmops_runtime_suspend+0x0/0xa0 [radeon] returns -22 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #6 from Tom Yan --- Created attachment 127911 --> https://bugzilla.kernel.org/attachment.cgi?id=127911&action=edit Xorg.0.log Maybe it's because I have some misconcept about xorg log, it doesn't seem to vary between cases. Anyway this issue doesn't seem to be related to X a lot. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #7 from Tom Yan --- All the above outputs were captured when only DisplayPort is connected. Similar sympton were observed with HDMI. Also, sometimes toggling others connectors afterwards makes it work again. Like if HDMI is plugged in and out after DisplayPort/DVI is gone, all displays work again. And the two DVI seems to "interact" with HDMI and DisplayPort differently. But those cases are inconsistent, so I can't describe in details or capture logs. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #8 from Tom Yan --- By "with HDMI" I mean only HDMI is connected. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/4] drm: Add support for CRTC primary planes
On Thu, Feb 27, 2014 at 02:14:40PM -0800, Matt Roper wrote:
> Allow drivers to provide a drm_plane structure corresponding to a CRTC's
> primary plane. These planes will be included in the plane list for any
> clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit.
>
> Signed-off-by: Matt Roper
Two small notes here and comments inside:
- In term of new API enabling and to make the tree bisectable, one needs
to 1/ do the preparation work 2/ enable the API. In this case, I would
split up the patch to make the ioctl bits independent and the last
patch of the series.
- I don't see a point in introducing the complexity to enable sprite and
cursor planes independently from each other. So before enabling the
new setcap() ioctl, could we also expose the cursor planes and call
the capability "universal planes" or similar?
--
Damien
> ---
> drivers/gpu/drm/drm_crtc.c | 168
> ++--
> drivers/gpu/drm/drm_ioctl.c | 5 ++
> include/drm/drmP.h | 2 +
> include/drm/drm_crtc.h | 11 +++
> include/uapi/drm/drm.h | 8 +++
> 5 files changed, 189 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 35ea15d..21c6d4b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -274,6 +274,74 @@ const char *drm_get_connector_status_name(enum
> drm_connector_status status)
> }
> EXPORT_SYMBOL(drm_get_connector_status_name);
>
> +/*
> + * Default set of pixel formats supported by primary planes. This matches
> the
> + * set of formats accepted by the traditional modesetting interfaces; drivers
> + * need only provide their own format list if it differs from the default.
> + */
> +static const uint32_t default_primary_plane_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_RGB332,
> + DRM_FORMAT_BGR233,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGBX,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGBX5551,
> + DRM_FORMAT_BGRX5551,
> + DRM_FORMAT_ARGB1555,
> + DRM_FORMAT_ABGR1555,
> + DRM_FORMAT_RGBA5551,
> + DRM_FORMAT_BGRA5551,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGBX,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_RGBX1010102,
> + DRM_FORMAT_BGRX1010102,
> + DRM_FORMAT_ARGB2101010,
> + DRM_FORMAT_ABGR2101010,
> + DRM_FORMAT_RGBA1010102,
> + DRM_FORMAT_BGRA1010102,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_AYUV,
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_NV21,
> + DRM_FORMAT_NV16,
> + DRM_FORMAT_NV61,
> + DRM_FORMAT_NV24,
> + DRM_FORMAT_NV42,
> + DRM_FORMAT_YUV410,
> + DRM_FORMAT_YVU410,
> + DRM_FORMAT_YUV411,
> + DRM_FORMAT_YVU411,
> + DRM_FORMAT_YUV420,
> + DRM_FORMAT_YVU420,
> + DRM_FORMAT_YUV422,
> + DRM_FORMAT_YVU422,
> + DRM_FORMAT_YUV444,
> + DRM_FORMAT_YVU444,
> +};
> +
> /**
> * drm_get_subpixel_order_name - return a string for a given subpixel enum
> * @order: enum of subpixel_order
> @@ -921,7 +989,7 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> EXPORT_SYMBOL(drm_encoder_cleanup);
>
> /**
> - * drm_plane_init - Initialise a new plane object
> + * drm_plane_init - Initialise a new sprite plane object
> * @dev: DRM device
> * @plane: plane object to init
> * @possible_crtcs: bitmask of possible CRTCs
> @@ -930,7 +998,9 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
> * @format_count: number of elements in @formats
> * @priv: plane is private (hidden from userspace)?
> *
> - * Inits a new object created as base part of a driver plane object.
> + * Inits a new object created as base part of a driver plane object. This
> + * function should only be called for traditional sprite/overlay planes.
> + * Primary planes should be initialized via @drm_plane_set_primary.
> *
> * RETURNS:
> * Zero on success, error code on failure.
> @@ -984,6 +1054,74 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
> EXPORT_SYMBOL(drm_plane_init);
>
> /**
> + * drm_plane_set_primary - Supply a primary plane for a CRTC
> + * @dev DRM device
> + * @plane: plane object representing the primary plane
> + * @crtc: CRTC this plane is associated with
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (%DRM_FORMAT_*). If NULL, the
> + * default
[PATCH 2/4] drm: Add plane type property
On Thu, Feb 27, 2014 at 11:03:07PM -0500, Rob Clark wrote: > >> > @@ -1114,6 +1126,10 @@ int drm_plane_set_primary(struct drm_device *dev, > >> > struct drm_plane *plane, > >> > >> > >> fwiw, this comment probably belongs in #1/4 but: > >> > >> you probably don't need to introduce drm_plane_set_primary().. > >> instead you could just rename the 'bool priv' to 'bool prim'. I think > >> there are just three drivers using primary planes.. I'm not 100% sure > >> about exynos, but both omap and msm, the private plane == primary > >> plane. At least it was the intention to morph that into primary > >> planes. > > > > I'd like to handle cursors with this eventually as well, so I'm not sure > > whether just changing the meaning of priv by itself will get us > > everything we need. It seems like we probably need to provide a whole > > lot more information about the capabilities and limitations of each > > plane at drm_plane_init() and then expose those all as plane > > properties so that userspace knows what it can and can't do. In theory > > we could expose cursor planes exactly the same way we expose > > "traditional" planes today as long as we made sufficient plane > > properties available to userspace to describe the min/max size > > limitations and such. > > We could also just go the opposite direction, ie. keep _set_primary() > and drop the 'priv' arg.. I don't really mind too much either way, but > the 'private' plane stuff was intended to eventually be exposed to > userspace.. so if we call it primary now (which is a much better > name, IMO), we should clean out the remaining references to 'private'. Ah, I had the same comment in patch 1/4. Why not have drm_init_plane() take the type of plane as the last argument then? (instead of bool primary, just the plane_type enum, primary, "sprite", cursor). -- Damien
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #9 from Tom Yan --- Created attachment 127921 --> https://bugzilla.kernel.org/attachment.cgi?id=127921&action=edit xorg log when not working Sorry I was doing stupid thing. Here is the xorg log captured after I turn the monitor off and on and `systemctl restart gdm` -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #1 from smoki --- Created attachment 95043 --> https://bugs.freedesktop.org/attachment.cgi?id=95043&action=edit dmesg -- 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/20140303/5a70db72/attachment.html>
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #2 from smoki --- Created attachment 95046 --> https://bugs.freedesktop.org/attachment.cgi?id=95046&action=edit glxinfo -- 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/20140303/5d256ffa/attachment.html>
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #3 from smoki --- Created attachment 95047 --> https://bugs.freedesktop.org/attachment.cgi?id=95047&action=edit Xorg.0.log -- 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/20140303/923cadfb/attachment.html>
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #4 from smoki --- Disable or enable ColorTiling doesn't help it is the same plus 40% CPU usage. In both cases even it used more CPU for gl video playback it is not smooth anymore. -- 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/20140303/f39cf65f/attachment.html>
[Bug 71461] monitor doesn't get detected after boot or disconnection
https://bugzilla.kernel.org/show_bug.cgi?id=71461 --- Comment #10 from Tom Yan --- Switching modes with xrandr can also bring back display. -- You are receiving this mail because: You are watching the assignee of the bug.
[PULL] drm-intel-next
Hi Dave, drm-intel-next-2014-02-14: - Fix the execbuf rebind performance regression due to topic/ppgtt (Chris). - Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre). - Try to preserve the firmware modeset config on driver load. And a bit of prep work for smooth takeover of the fb contents (Jesse). - Prep cleanup for larger gtt address spaces on bdw (Ben). - Improve our vblank_wait code to make hsw modesets faster (Paulo). - Display debugfs file (Jesse). - DRRS prep work from Vandana Kannan. - pipestat interrupt handler to fix a few races around vblank/pageflip handling on byt (Imre). - Improve display fuse handling for display-less SKUs (Damien). - Drop locks while stalling for the gpu when serving pagefaults to improve interactivity (Chris). - And as usual piles of other improvements and small fixes all over. Note that full ppgtt isn't yet in a shape I'm really happy with - I'll go with the fallback option of disabling it for 3.15 for the next pull request if that doesn't improve. But first I need to dig through the patch flood from my vacations ;-) Cheers, Daniel The following changes since commit b8a5ff8d7c676a04e0da5ec16bb068dd39459042: drm/i915: Update rps interrupt limits (2014-02-07 10:26:17 +0100) are available in the git repository at: ssh://git.freedesktop.org/git/drm-intel tags/drm-intel-next-2014-02-14 for you to fetch changes up to 4c0e552882114d1edb588242d45035246ab078a0: drm/i915: fix NULL deref in the load detect code (2014-02-14 17:23:12 +0100) - Fix the execbuf rebind performance regression due to topic/ppgtt (Chris). - Fix up the connector cleanup ordering for sdvod i2c and dp aux devices (Imre). - Try to preserve the firmware modeset config on driver load. And a bit of prep work for smooth takeover of the fb contents (Jesse). - Prep cleanup for larger gtt address spaces on bdw (Ben). - Improve our vblank_wait code to make hsw modesets faster (Paulo). - Display debugfs file (Jesse). - DRRS prep work from Vandana Kannan. - pipestat interrupt handler to fix a few races around vblank/pageflip handling on byt (Imre). - Improve display fuse handling for display-less SKUs (Damien). - Drop locks while stalling for the gpu when serving pagefaults to improve interactivity (Chris). - And as usual piles of other improvements and small fixes all over. Ben Widawsky (5): drm/i915: Clarify RC6 enabling drm/i915: Stop pretending VLV has rc6+ drm/i915: Just print rc6 facts drm/i915/bdw: Use centralized rc6 info print drm/i915/bdw: Split up PPGTT cleanup Chris Wilson (4): drm/i915: Downgrade *ERROR* message for invalid user input drm/i915: Propagate PCI read/write errors during vga_set_state() drm/i915: Short-circuit no-op vga_set_state() drm/i915: Flush GPU rendering with a lockless wait during a pagefault Damien Lespiau (9): drm/i915: Always use INTEL_INFO() to access the device_info structure drm/i915: Make the intel_device_info structure kept in dev_priv writable drm/i915: Move num_plane to the intel_device_info structure drm/i915: Consolidate FUSE_STRAP in one set of defines drm/i915: Use I915_MAX_PIPES in the pipe/plane_to_crtc_mapping definitions drm/i915: Reorder i915_params fields to not create holes drm/i915: Disable display when fused off drm/i915: Provide a command line option to disable display drm/i915/lvds: Remove dead code from failing case Daniel Vetter (19): drm/i915: Use normal fb deref for the fbcon framebuffer drm/i915: Fix error path leak in fbdev fb allocation drm/i915: Pass explicit mode into mode_from_pipe_config v3 drm/i915: Some polish for the new pipestat_irq_handler drm/i915: kill intel_crtc_update_sarea_pos drm/i915: protect ringbuffer sarea update behind !MODESET drm/i915: delay master/sarea deref for legacy ioctls drm/i915: Consolidate binding parameters into flags drm/i915: split PIN_GLOBAL out from PIN_MAPPABLE drm/i915: Handle set_cache_level errors in the pipe control scratch setup drm/i915: Don't set PIN_MAPPABLE for legacy ringbuffers drm/i915: Don't pin the status page as mappable drm/i915: Handle set_cache_level errors in the status page setup drm/i915: Don't allocate context pages as mappable drm/i915: Allow blocking in the PDE alloc when running low on gtt space drm/i915: Simplify i915_gem_object_ggtt_unpin drm/i915: Directly return the vma from bind_to_vm drm/i915: Only bind each object rather than for every execbuffer drm/i915: fix NULL deref in the load detect code Imre Deak (8): drm/i915: pass status instead of enable flags to i915_enable_pipestat drm/i915: vlv: fix mapping of pipestat enable to status bits drm/i915: vlv: handle only ena
[PATCH 1/4] drm: Add support for CRTC primary planes
On Mon, Mar 03, 2014 at 03:47:43PM +, Damien Lespiau wrote:
> On Thu, Feb 27, 2014 at 02:14:40PM -0800, Matt Roper wrote:
> > Allow drivers to provide a drm_plane structure corresponding to a CRTC's
> > primary plane. These planes will be included in the plane list for any
> > clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit.
> >
> > Signed-off-by: Matt Roper
>
> Two small notes here and comments inside:
>
> - In term of new API enabling and to make the tree bisectable, one needs
> to 1/ do the preparation work 2/ enable the API. In this case, I would
> split up the patch to make the ioctl bits independent and the last
> patch of the series.
>
> - I don't see a point in introducing the complexity to enable sprite and
> cursor planes independently from each other. So before enabling the
> new setcap() ioctl, could we also expose the cursor planes and call
> the capability "universal planes" or similar?
I'm not sure I follow what you're saying on this second point. Sprites
(or overlays) are already exposed to userspace, so existing clients
expect anything they receive via drmModeGetPlaneResources() to behave in
the traditional manner. If we start throwing cursor planes into that
list without hiding them behind a capability bit, existing userspace try
to blindly use the cursors as full overlays without realizing that they
may carry additional restrictions on size and such, which will lead to
userspace breakage.
In cases where userspace has set a capability bit, I agree that
sprites/overlays/cursors could all pretty much be treated the same as
long as there are additional plane properties to let userspace
understand the exact restrictions of each plane. Is that what you were
referring to here?
I agree with your other comments; I'll work on a second revision that
incorporates the suggestions from you and Rob. Thanks for the review.
Matt
>
> --
> Damien
>
> > ---
> > drivers/gpu/drm/drm_crtc.c | 168
> > ++--
> > drivers/gpu/drm/drm_ioctl.c | 5 ++
> > include/drm/drmP.h | 2 +
> > include/drm/drm_crtc.h | 11 +++
> > include/uapi/drm/drm.h | 8 +++
> > 5 files changed, 189 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 35ea15d..21c6d4b 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -274,6 +274,74 @@ const char *drm_get_connector_status_name(enum
> > drm_connector_status status)
> > }
> > EXPORT_SYMBOL(drm_get_connector_status_name);
> >
> > +/*
> > + * Default set of pixel formats supported by primary planes. This matches
> > the
> > + * set of formats accepted by the traditional modesetting interfaces;
> > drivers
> > + * need only provide their own format list if it differs from the default.
> > + */
> > +static const uint32_t default_primary_plane_formats[] = {
> > + DRM_FORMAT_C8,
> > + DRM_FORMAT_RGB332,
> > + DRM_FORMAT_BGR233,
> > + DRM_FORMAT_XRGB,
> > + DRM_FORMAT_XBGR,
> > + DRM_FORMAT_RGBX,
> > + DRM_FORMAT_BGRX,
> > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_ABGR,
> > + DRM_FORMAT_RGBA,
> > + DRM_FORMAT_BGRA,
> > + DRM_FORMAT_XRGB1555,
> > + DRM_FORMAT_XBGR1555,
> > + DRM_FORMAT_RGBX5551,
> > + DRM_FORMAT_BGRX5551,
> > + DRM_FORMAT_ARGB1555,
> > + DRM_FORMAT_ABGR1555,
> > + DRM_FORMAT_RGBA5551,
> > + DRM_FORMAT_BGRA5551,
> > + DRM_FORMAT_RGB565,
> > + DRM_FORMAT_BGR565,
> > + DRM_FORMAT_RGB888,
> > + DRM_FORMAT_BGR888,
> > + DRM_FORMAT_XRGB,
> > + DRM_FORMAT_XBGR,
> > + DRM_FORMAT_RGBX,
> > + DRM_FORMAT_BGRX,
> > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_ABGR,
> > + DRM_FORMAT_RGBA,
> > + DRM_FORMAT_BGRA,
> > + DRM_FORMAT_XRGB2101010,
> > + DRM_FORMAT_XBGR2101010,
> > + DRM_FORMAT_RGBX1010102,
> > + DRM_FORMAT_BGRX1010102,
> > + DRM_FORMAT_ARGB2101010,
> > + DRM_FORMAT_ABGR2101010,
> > + DRM_FORMAT_RGBA1010102,
> > + DRM_FORMAT_BGRA1010102,
> > + DRM_FORMAT_YUYV,
> > + DRM_FORMAT_YVYU,
> > + DRM_FORMAT_UYVY,
> > + DRM_FORMAT_VYUY,
> > + DRM_FORMAT_AYUV,
> > + DRM_FORMAT_NV12,
> > + DRM_FORMAT_NV21,
> > + DRM_FORMAT_NV16,
> > + DRM_FORMAT_NV61,
> > + DRM_FORMAT_NV24,
> > + DRM_FORMAT_NV42,
> > + DRM_FORMAT_YUV410,
> > + DRM_FORMAT_YVU410,
> > + DRM_FORMAT_YUV411,
> > + DRM_FORMAT_YVU411,
> > + DRM_FORMAT_YUV420,
> > + DRM_FORMAT_YVU420,
> > + DRM_FORMAT_YUV422,
> > + DRM_FORMAT_YVU422,
> > + DRM_FORMAT_YUV444,
> > + DRM_FORMAT_YVU444,
> > +};
> > +
> > /**
> > * drm_get_subpixel_order_name - return a string for a given subpixel enum
> > * @order: enum of subpixel_order
> > @@ -921,7 +989,7 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> > EXPORT_SYMBOL(drm_encoder_cleanup);
> >
> > /**
> > - * drm_plane_init - Initialise a new plane object
> > + * drm_plane_init - Initia
[PATCH 1/4] drm: Add support for CRTC primary planes
On Mon, Mar 03, 2014 at 09:45:53AM -0800, Matt Roper wrote: > On Mon, Mar 03, 2014 at 03:47:43PM +, Damien Lespiau wrote: > > On Thu, Feb 27, 2014 at 02:14:40PM -0800, Matt Roper wrote: > > > Allow drivers to provide a drm_plane structure corresponding to a CRTC's > > > primary plane. These planes will be included in the plane list for any > > > clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit. > > > > > > Signed-off-by: Matt Roper > > > > Two small notes here and comments inside: > > > > - In term of new API enabling and to make the tree bisectable, one needs > > to 1/ do the preparation work 2/ enable the API. In this case, I would > > split up the patch to make the ioctl bits independent and the last > > patch of the series. > > > > - I don't see a point in introducing the complexity to enable sprite and > > cursor planes independently from each other. So before enabling the > > new setcap() ioctl, could we also expose the cursor planes and call > > the capability "universal planes" or similar? > > I'm not sure I follow what you're saying on this second point. Sprites > (or overlays) are already exposed to userspace, so existing clients > expect anything they receive via drmModeGetPlaneResources() to behave in > the traditional manner. If we start throwing cursor planes into that > list without hiding them behind a capability bit, existing userspace try > to blindly use the cursors as full overlays without realizing that they > may carry additional restrictions on size and such, which will lead to > userspace breakage. I mean, I don't see the point of having 2 separate calls to the SET_CAP ioctl() to enable both primary and cursor planes. I think we should have a single cap called "Universal planes" that expose both (which of course means we need to do the same work for cursor plane before the ioctl patch). This way we have fewer corner cases to care about. -- Damien
[PATCH] drm/edid: request HDMI underscan by default
On Thu, Feb 27, 2014 at 03:49:10PM +, Damien Lespiau wrote:
> On Thu, Feb 27, 2014 at 05:42:36PM +0200, Ville Syrj?l? wrote:
> > On Thu, Feb 27, 2014 at 09:19:30AM -0600, Daniel Drake wrote:
> > > Working with HDMI TVs is a real pain as they tend to overscan by
> > > default, meaning that the pixels around the edge of the framebuffer
> > > are not displayed. This is well explained here:
> > > http://mjg59.dreamwidth.org/8705.html
> > >
> > > There is a bit in the HDMI info frame that can request that the
> > > remote display shows the full pixel data ("underscan"). For the
> > > remote display, the HDMI spec states that this is optional - it
> > > doesn't have to listen. That means that most TVs will probably ignore
> > > this.
> > >
> > > But, maybe there are a handful of TVs for which this would help
> > > the situation. As we live in a digital world, ask the remote
> > > display not to overscan by default.
> > >
> > > Signed-off-by: Daniel Drake
> >
> > Reviewed-by: Ville Syrj?l?
>
> As a small note, I never managed to find a TV (out of the 2 I have
> around) that honour that flag, which is why I haven't pushed that patch
> before. I also had the hope that we could automatically overscan with
> the right amount at some point (with some sort of database) and with
> that flag set, we don't know if the sink is overscanning or not, but
> then I guess we could include whether the TV honour in that flag in a db
> as well.
>
> In any case, I echo the review:
>
> Reviewed-by: Damien Lespiau
Applied to my topic/core-stuff grab-bag branch, thanks for patch&review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #5 from smoki --- Created attachment 95050 --> https://bugs.freedesktop.org/attachment.cgi?id=95050&action=edit Before commit Example from games when video is there: main menu from OpenJK game https://github.com/JACoders/OpenJK . In the centar circle there is playing a video file. CPU usage is 50% and it have ~50 FPS -- 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/20140303/0610062a/attachment.html>
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #6 from smoki --- Created attachment 95051 --> https://bugs.freedesktop.org/attachment.cgi?id=95051&action=edit With this commit With this commit: CPU usage is higher 90% but it have just ~12 FPS :). -- 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/20140303/197721db/attachment-0001.html>
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #7 from smoki --- So in this case it uses 700 MHz more CPU power, but gives nothing FPS :). -- 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/20140303/54c52a40/attachment.html>
[PATCH 1/4] drm: Add support for CRTC primary planes
Hi
On Thu, Feb 27, 2014 at 11:14 PM, Matt Roper
wrote:
> Allow drivers to provide a drm_plane structure corresponding to a CRTC's
> primary plane. These planes will be included in the plane list for any
> clients setting the DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES capability bit.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/drm_crtc.c | 168
> ++--
> drivers/gpu/drm/drm_ioctl.c | 5 ++
> include/drm/drmP.h | 2 +
> include/drm/drm_crtc.h | 11 +++
> include/uapi/drm/drm.h | 8 +++
> 5 files changed, 189 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 35ea15d..21c6d4b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -274,6 +274,74 @@ const char *drm_get_connector_status_name(enum
> drm_connector_status status)
> }
> EXPORT_SYMBOL(drm_get_connector_status_name);
>
> +/*
> + * Default set of pixel formats supported by primary planes. This matches
> the
> + * set of formats accepted by the traditional modesetting interfaces; drivers
> + * need only provide their own format list if it differs from the default.
> + */
> +static const uint32_t default_primary_plane_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_RGB332,
> + DRM_FORMAT_BGR233,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGBX,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGBX5551,
> + DRM_FORMAT_BGRX5551,
> + DRM_FORMAT_ARGB1555,
> + DRM_FORMAT_ABGR1555,
> + DRM_FORMAT_RGBA5551,
> + DRM_FORMAT_BGRA5551,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_RGBX,
> + DRM_FORMAT_BGRX,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGBA,
> + DRM_FORMAT_BGRA,
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_RGBX1010102,
> + DRM_FORMAT_BGRX1010102,
> + DRM_FORMAT_ARGB2101010,
> + DRM_FORMAT_ABGR2101010,
> + DRM_FORMAT_RGBA1010102,
> + DRM_FORMAT_BGRA1010102,
> + DRM_FORMAT_YUYV,
> + DRM_FORMAT_YVYU,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_VYUY,
> + DRM_FORMAT_AYUV,
> + DRM_FORMAT_NV12,
> + DRM_FORMAT_NV21,
> + DRM_FORMAT_NV16,
> + DRM_FORMAT_NV61,
> + DRM_FORMAT_NV24,
> + DRM_FORMAT_NV42,
> + DRM_FORMAT_YUV410,
> + DRM_FORMAT_YVU410,
> + DRM_FORMAT_YUV411,
> + DRM_FORMAT_YVU411,
> + DRM_FORMAT_YUV420,
> + DRM_FORMAT_YVU420,
> + DRM_FORMAT_YUV422,
> + DRM_FORMAT_YVU422,
> + DRM_FORMAT_YUV444,
> + DRM_FORMAT_YVU444,
> +};
> +
As Damien said, I'd drop that list. I don't think we save much by
providing a default..
> /**
> * drm_get_subpixel_order_name - return a string for a given subpixel enum
> * @order: enum of subpixel_order
> @@ -921,7 +989,7 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> EXPORT_SYMBOL(drm_encoder_cleanup);
>
> /**
> - * drm_plane_init - Initialise a new plane object
> + * drm_plane_init - Initialise a new sprite plane object
> * @dev: DRM device
> * @plane: plane object to init
> * @possible_crtcs: bitmask of possible CRTCs
> @@ -930,7 +998,9 @@ EXPORT_SYMBOL(drm_encoder_cleanup);
> * @format_count: number of elements in @formats
> * @priv: plane is private (hidden from userspace)?
> *
> - * Inits a new object created as base part of a driver plane object.
> + * Inits a new object created as base part of a driver plane object. This
> + * function should only be called for traditional sprite/overlay planes.
> + * Primary planes should be initialized via @drm_plane_set_primary.
> *
> * RETURNS:
> * Zero on success, error code on failure.
> @@ -984,6 +1054,74 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
> EXPORT_SYMBOL(drm_plane_init);
>
> /**
> + * drm_plane_set_primary - Supply a primary plane for a CRTC
> + * @dev DRM device
> + * @plane: plane object representing the primary plane
> + * @crtc: CRTC this plane is associated with
> + * @funcs: callbacks for the new plane
> + * @formats: array of supported formats (%DRM_FORMAT_*). If NULL, the
> + * default list of formats traditionally supported by modesetting
> + * API's will be used and @format_count will be ignored.
> + * @format_count: number of elements in @formats
> + *
> + * Provides a drm_plane representing a CRTC's primary plane. This plane will
> + * only be exposed to clients that set the
> DRM_CLIENT_CAP_EXPOSE_PRIMARY_PLANES
> + *
[RFCv4 09/14] drm: convert plane to properties/state
On Wed, Feb 26, 2014 at 7:18 PM, Rob Clark wrote:
> On Wed, Feb 26, 2014 at 4:30 PM, Sean Paul wrote:
>> On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote:
>>> Break the mutable state of a plane out into a separate structure
>>> and use atomic properties mechanism to set plane attributes. This
>>> makes it easier to have some helpers for plane->set_property()
>>> and for checking for invalid params. The idea is that individual
>>> drivers can wrap the state struct in their own struct which adds
>>> driver specific parameters, for easy build-up of state across
>>> multiple set_property() calls and for easy atomic commit or roll-
>>> back.
>>>
>>> The same should be done for CRTC, encoder, and connector, but this
>>> patch only includes the first part (plane).
>>
>>
>> Hi Rob,
>> I've been tracking down a crash that came up on my exynos board when I
>> applied this patch. I hope you can hold my hand a little bit and give
>> some guidance.
>>
>>
>>
>>> +static int
>>> +drm_atomic_helper_commit_plane_state(struct drm_plane *plane,
>>> + struct drm_plane_state *pstate)
>>> +{
>>> + struct drm_framebuffer *old_fb = NULL, *fb = NULL;
>>> + int ret = 0;
>>> +
>>> + fb = pstate->fb;
>>> +
>>> + if (pstate->crtc && fb) {
>>> + ret = plane->funcs->update_plane(plane, pstate->crtc,
>>> pstate->fb,
>>> + pstate->crtc_x, pstate->crtc_y, pstate->crtc_w,
>>> pstate->crtc_h,
>>> + pstate->src_x, pstate->src_y, pstate->src_w,
>>> pstate->src_h);
>>> + if (!ret) {
>>> + /* on success, update state and fb refcnting: */
>>> + /* NOTE: if we ensure no driver sets
>>> plane->state->fb = NULL
>>> +* on disable, we can move this up a level and not
>>> duplicate
>>> +* nearly the same thing for both update_plane and
>>> disable_plane
>>> +* cases.. I leave it like this for now to be
>>> paranoid due to
>>> +* the slightly different ordering in the two cases
>>> in the
>>> +* original code.
>>> +*/
>>> + old_fb = plane->state->fb;
>>
>> I think this is slightly different than what we had before in
>> setplane. In the previous code, we had:
>>
>> ret = plane->funcs->update_plane(plane, crtc, fb,
>> plane_req->crtc_x,
>> plane_req->crtc_y,
>> plane_req->crtc_w,
>> plane_req->crtc_h,
>> plane_req->src_x,
>> plane_req->src_y,
>> plane_req->src_w,
>> plane_req->src_h);
>> if (!ret) {
>> old_fb = plane->fb;
>> fb = NULL;
>> plane->crtc = crtc;
>> plane->fb = fb;
>> }
>>
>> In this case, we'd unreference old_fb which is the previous plane->fb.
>> AFAICT, update_plane did not set plane->fb to fb, so it would, in
>> fact, be the old plane.
>
> to be honest, I need to dig up that branch again and remember (and
> rebase it while I'm at it)..
>
> I don't think the driver should be changing state->fb (ie. the state
> object should in theory, once constructed, be a sort of constant
> thing). So until swap_plane_state() plane->state->fb is *supposed* to
> be the old fb.
>
Hey Rob,
Sorry for the delay getting back to you. Indeed, I was confused in my
last email, thanks for straightening me out.
I traced through things a little more carefully and it looks like my
fb is being unreferenced every time we call set_property on the plane.
On exynos, we set a private zpos property via the set_property ioctl.
In this case, drm_mode_set_property_ioctl does not take a reference on
the plane's current fb, but we put a reference in atomic_commit
(assuming it's got a valid crtc/fb). Eventually, this runs the
refcount down to 0 and we end up freeing the fb early.
I think the fix here is to only unreference the plane's current fb in
the case where new_fb is true. ie:
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 14e0571..ec60d4e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -394,7 +394,8 @@ drm_atomic_helper_commit_plane_state(struct
drm_plane *plane,
* the slightly different ordering in the two
cases in the
* original code.
*/
- old_fb = plane->state->fb;
+ if (pstate->new_fb)
+ old_fb = plane->state->fb;
swap_plane_state(plane, pstate->state);
fb = NULL;
}
Seem reasonable?
Sean
> For crtc, as there were so many places in code accessing crtc->fb (and
> it was pretty intertwined in the crtc hel
[RFCv4 09/14] drm: convert plane to properties/state
On Mon, Mar 3, 2014 at 2:22 PM, Sean Paul wrote:
> On Wed, Feb 26, 2014 at 7:18 PM, Rob Clark wrote:
>> On Wed, Feb 26, 2014 at 4:30 PM, Sean Paul wrote:
>>> On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote:
Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes. This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.
The same should be done for CRTC, encoder, and connector, but this
patch only includes the first part (plane).
>>>
>>>
>>> Hi Rob,
>>> I've been tracking down a crash that came up on my exynos board when I
>>> applied this patch. I hope you can hold my hand a little bit and give
>>> some guidance.
>>>
>>>
>>>
+static int
+drm_atomic_helper_commit_plane_state(struct drm_plane *plane,
+ struct drm_plane_state *pstate)
+{
+ struct drm_framebuffer *old_fb = NULL, *fb = NULL;
+ int ret = 0;
+
+ fb = pstate->fb;
+
+ if (pstate->crtc && fb) {
+ ret = plane->funcs->update_plane(plane, pstate->crtc,
pstate->fb,
+ pstate->crtc_x, pstate->crtc_y, pstate->crtc_w,
pstate->crtc_h,
+ pstate->src_x, pstate->src_y, pstate->src_w,
pstate->src_h);
+ if (!ret) {
+ /* on success, update state and fb refcnting: */
+ /* NOTE: if we ensure no driver sets
plane->state->fb = NULL
+* on disable, we can move this up a level and not
duplicate
+* nearly the same thing for both update_plane and
disable_plane
+* cases.. I leave it like this for now to be
paranoid due to
+* the slightly different ordering in the two
cases in the
+* original code.
+*/
+ old_fb = plane->state->fb;
>>>
>>> I think this is slightly different than what we had before in
>>> setplane. In the previous code, we had:
>>>
>>> ret = plane->funcs->update_plane(plane, crtc, fb,
>>> plane_req->crtc_x,
>>> plane_req->crtc_y,
>>> plane_req->crtc_w,
>>> plane_req->crtc_h,
>>> plane_req->src_x,
>>> plane_req->src_y,
>>> plane_req->src_w,
>>> plane_req->src_h);
>>> if (!ret) {
>>> old_fb = plane->fb;
>>> fb = NULL;
>>> plane->crtc = crtc;
>>> plane->fb = fb;
>>> }
>>>
>>> In this case, we'd unreference old_fb which is the previous plane->fb.
>>> AFAICT, update_plane did not set plane->fb to fb, so it would, in
>>> fact, be the old plane.
>>
>> to be honest, I need to dig up that branch again and remember (and
>> rebase it while I'm at it)..
>>
>> I don't think the driver should be changing state->fb (ie. the state
>> object should in theory, once constructed, be a sort of constant
>> thing). So until swap_plane_state() plane->state->fb is *supposed* to
>> be the old fb.
>>
>
> Hey Rob,
> Sorry for the delay getting back to you. Indeed, I was confused in my
> last email, thanks for straightening me out.
>
> I traced through things a little more carefully and it looks like my
> fb is being unreferenced every time we call set_property on the plane.
> On exynos, we set a private zpos property via the set_property ioctl.
> In this case, drm_mode_set_property_ioctl does not take a reference on
> the plane's current fb, but we put a reference in atomic_commit
> (assuming it's got a valid crtc/fb). Eventually, this runs the
> refcount down to 0 and we end up freeing the fb early.
>
> I think the fix here is to only unreference the plane's current fb in
> the case where new_fb is true. ie:
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 14e0571..ec60d4e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -394,7 +394,8 @@ drm_atomic_helper_commit_plane_state(struct
> drm_plane *plane,
> * the slightly different ordering in the two
> cases in the
> * original code.
> */
> - old_fb = plane->state->fb;
> + if (pstate->new_fb)
> + old_fb = plane->state->fb;
> swap_plane_state(plane, pstate->state);
>
[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation
https://bugs.freedesktop.org/show_bug.cgi?id=73320 --- Comment #17 from Tom Stellard --- Can you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes -- 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/20140303/b0869e1d/attachment.html>
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 --- Comment #5 from Tom Stellard --- Can you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes If you experience any crashes or hangs please post the output of R600_DEBUG=ps,vs,gs -- 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/20140303/a0bd1bd0/attachment.html>
[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 --- Comment #6 from Tom Stellard --- Can you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes -- 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/20140303/a97498cc/attachment-0001.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #67 from Tom Stellard --- (In reply to comment #66) > @Tom Stellard: Will you prepare new patch for testing? And when you include > this fix into mesa? I'm still trying to track down a Tahiti GPU, so I can see what the issue is 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/20140303/9f2ad334/attachment.html>
[WARNING - 3.14-rc2] i915: pipe_off wait timed out
On Fri, Feb 14, 2014 at 05:41:01PM -0500, Steven Rostedt wrote: > I get the following splat in my tests running 3.14-rc2: > > [3.955123] WARNING: CPU: 0 PID: 1 at > /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_display.c:857 > intel_wait_for_pipe_off+0x17a/0x2d0() > [3.955124] pipe_off wait timed out > [3.955127] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc2-test+ #10 > [3.955128] Hardware name: /DG965MQ, BIOS > MQ96510J.86A.0372.2006.0605.1717 06/05/2006 > [3.955133] 0359 88007d075868 828dff7d > 0006 > [3.955136] 88007d0758b8 88007d0758a8 8106c015 > 1000^M > [3.955139] 880078d58000 00071008 fffb7b90 > 1000 > [3.955140] Call Trace: > [3.955144] [] dump_stack+0x77/0x9e > [3.955147] [] warn_slowpath_common+0xa5/0xf0 > [3.955150] [] warn_slowpath_fmt+0x51/0x60 > [3.955153] [] ? gen4_read32+0x52/0x70 > [3.955156] [] intel_wait_for_pipe_off+0x17a/0x2d0 > [3.955158] [] intel_disable_pipe+0x104/0x110^M > [3.955161] [] i9xx_crtc_disable+0x11e/0x4a0 > [3.955163] [] intel_crtc_update_dpms+0x94/0xe0 > [3.955166] [] intel_modeset_setup_hw_state+0x9f8/0x1020 > [3.955168] [] ? gen4_write64+0x80/0x80 > [3.955170] [] intel_modeset_gem_init+0x62/0x80 > [3.955173] [] i915_driver_load+0x15e0/0x1760 > [3.955176] [] ? device_add+0x31b/0xa20 > [3.955180] [] drm_dev_register+0xb4/0x260 > [3.955182] [] drm_get_pci_dev+0x15e/0x320 > [3.955186] [] ? trace_hardirqs_on+0x1d/0x30 > [3.955188] [] i915_pci_probe+0x4e/0x80 > [3.955191] [] pci_device_probe+0xdd/0x190 > [3.955194] [] driver_probe_device+0xc8/0x550 > [3.955196] [] __driver_attach+0xfb/0x110 > [3.955198] [] ? driver_probe_device+0x550/0x550 > [3.955200] [] bus_for_each_dev+0x9e/0xf0 > [3.955202] [] driver_attach+0x21/0x30 > [3.955204] [] bus_add_driver+0x16f/0x340 > [3.955207] [] driver_register+0xa7/0x190 > [3.955209] [] __pci_register_driver+0x6f/0x80 > [3.955211] [] drm_pci_init+0x159/0x170 > [3.955214] [] ? radeon_init+0xfb/0xfb^M > [3.955217] [] i915_init+0xa5/0xae > [3.955220] [] do_one_initcall+0xe1/0x1b2 > [3.955223] [] kernel_init_freeable+0x19c/0x29d > [3.955225] [] ? loglevel+0x46/0x46 > [3.955228] [] ? rest_init+0x120/0x120 > [3.955230] [] kernel_init+0x11/0x1a0 > [3.955233] [] ret_from_fork+0x7c/0xb0 > [3.955235] [] ? rest_init+0x120/0x120^M > [3.955256] ---[ end trace 708152452bf03fad ]--- > > > Config attached. If this is an ironlake it's https://bugs.freedesktop.org/show_bug.cgi?id=54687, for sandybridge it's https://bugs.freedesktop.org/show_bug.cgi?id=67462. Iirc we've stopped seing this on more recent platfroms (i.e. Ivybridge+). It's an issue in our dp code where the dp port doesn't cleanly shut down, but we haven't ever figured out what's really botched up. DP in general is nasty in that way. If there's no other bad side effects I don't think there's much we could do :( -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
On Wed, Feb 19, 2014 at 02:25:59PM +0100, Maarten Lankhorst wrote:
> op 17-02-14 19:41, Christian K?nig schreef:
> >Am 17.02.2014 19:24, schrieb Rob Clark:
> >>On Mon, Feb 17, 2014 at 12:36 PM, Christian K?nig
> >> wrote:
> >>>Am 17.02.2014 18:27, schrieb Rob Clark:
> >>>
> On Mon, Feb 17, 2014 at 11:56 AM, Christian K?nig
> wrote:
> >Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
> >
> >>This type of fence can be used with hardware synchronization for simple
> >>hardware that can block execution until the condition
> >>(dma_buf[offset] - value) >= 0 has been met.
> >
> >Can't we make that just "dma_buf[offset] != 0" instead? As far as I know
> >this way it would match the definition M$ uses in their WDDM
> >specification
> >and so make it much more likely that hardware supports it.
> well 'buf[offset] >= value' at least means the same slot can be used
> for multiple operations (with increasing values of 'value').. not sure
> if that is something people care about.
>
> >=value seems to be possible with adreno and radeon. I'm not really sure
> >about others (although I presume it as least supported for nv desktop
> >stuff). For hw that cannot do >=value, we can either have a different
> >fence
> >implementation which uses the !=0 approach. Or change seqno-fence
> >implementation later if needed. But if someone has hw that can do !=0
> >but
> >not >=value, speak up now ;-)
> >>>
> >>>Here! Radeon can only do >=value on the DMA and 3D engine, but not with UVD
> >>>or VCE. And for the 3D engine it means draining the pipe, which isn't
> >>>really
> >>>a good idea.
> >>hmm, ok.. forgot you have a few extra rings compared to me. Is UVD
> >>re-ordering from decode-order to display-order for you in hw? If not,
> >>I guess you need sw intervention anyways when a frame is done for
> >>frame re-ordering, so maybe hw->hw sync doesn't really matter as much
> >>as compared to gpu/3d->display. For dma<->3d interactions, seems like
> >>you would care more about hw<->hw sync, but I guess you aren't likely
> >>to use GPU A to do a resolve blit for GPU B..
> >
> >No UVD isn't reordering, but since frame reordering is predictable you
> >usually end up with pipelining everything to the hardware. E.g. you send the
> >decode commands in decode order to the UVD block and if you have overlay
> >active one of the frames are going to be the first to display and then you
> >want to wait for it on the display side.
> >
> >>For 3D ring, I assume you probably want a CP_WAIT_FOR_IDLE before a
> >>CP_MEM_WRITE to update fence value in memory (for the one signalling
> >>the fence). But why would you need that before a CP_WAIT_REG_MEM (for
> >>the one waiting for the fence)? I don't exactly have documentation
> >>for adreno version of CP_WAIT_REG_{MEM,EQ,GTE}.. but PFP and ME
> >>appear to be same instruction set as r600, so I'm pretty sure they
> >>should have similar capabilities.. CP_WAIT_REG_MEM appears to be same
> >>but with 32bit gpu addresses vs 64b.
> >
> >You shouldn't use any of the CP commands for engine synchronization (neither
> >for wait nor for signal). The PFP and ME are just the top of a quite deep
> >pipeline and when you use any of the CP_WAIT functions you block them for
> >something and that's draining the pipeline.
> >
> >With the semaphore and fence commands the values are just attached as
> >prerequisite to the draw command, e.g. the CP setups the draw environment
> >and issues the command, but the actual execution of it is delayed until the
> >"!= 0" condition hits. And in the meantime the CP already prepares the next
> >draw operation.
> >
> >But at least for compute queues wait semaphore aren't the perfect solution
> >either. What you need then is a GPU scheduler that uses a kernel task for
> >setting up the command submission for you when all prerequisites are meet.
> nouveau has sort of a scheduler in hardware. It can yield when waiting
> on a semaphore. And each process gets their own context and the
> timeslices can be adjusted. ;-) But I don't mind changing this patch
> when an actual user pops up. Nouveau can do a wait for (*sema & mask)
> != 0 only on nvc0 and newer, where mask can be chosen. But it can do ==
> somevalue and >= somevalue on older relevant optimus hardware, so if we
> know that it was zero before and we know the sign of the new value that
> could work too.
>
> Adding ops and a separate mask later on when users pop up is fine with
> me, the original design here was chosen so I could map the intel status
> page read-only into the process specific nvidia vm.
Yeah, I guess in the end we might end up having a pile of different
memory-based (shared through dma-bufs) based fences. But imo getting this
thing of the ground is more important, and you can always do crazy
per-platform/generation/whatever hacks and match on that specific fence
type in the interim. That'll cut it
[PATCH 4/6] android: convert sync to fence api, v4
On Mon, Feb 17, 2014 at 04:57:19PM +0100, Maarten Lankhorst wrote:
> Android syncpoints can be mapped to a timeline. This removes the need
> to maintain a separate api for synchronization. I've left the android
> trace events in place, but the core fence events should already be
> sufficient for debugging.
>
> v2:
> - Call fence_remove_callback in sync_fence_free if not all fences have fired.
> v3:
> - Merge Colin Cross' bugfixes, and the android fence merge optimization.
> v4:
> - Merge with the upstream fixes.
>
> Signed-off-by: Maarten Lankhorst
> ---
Snipped everything but headers - Ian Lister from our android team is
signed up to have a more in-depth look at proper integration with android
syncpoints. Adding him to cc.
> diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
> index 62e2255b1c1e..6036dbdc8e6f 100644
> --- a/drivers/staging/android/sync.h
> +++ b/drivers/staging/android/sync.h
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
>
> struct sync_timeline;
> struct sync_pt;
> @@ -40,8 +41,6 @@ struct sync_fence;
> * -1 if a will signal before b
> * @free_pt: called before sync_pt is freed
> * @release_obj: called before sync_timeline is freed
> - * @print_obj: deprecated
> - * @print_pt: deprecated
> * @fill_driver_data: write implementation specific driver data to data.
> * should return an error if there is not enough room
> * as specified by size. This information is returned
> @@ -67,13 +66,6 @@ struct sync_timeline_ops {
> /* optional */
> void (*release_obj)(struct sync_timeline *sync_timeline);
>
> - /* deprecated */
> - void (*print_obj)(struct seq_file *s,
> - struct sync_timeline *sync_timeline);
> -
> - /* deprecated */
> - void (*print_pt)(struct seq_file *s, struct sync_pt *sync_pt);
> -
> /* optional */
> int (*fill_driver_data)(struct sync_pt *syncpt, void *data, int size);
>
> @@ -104,42 +96,48 @@ struct sync_timeline {
>
> /* protected by child_list_lock */
> bool destroyed;
> + int context, value;
>
> struct list_head child_list_head;
> spinlock_t child_list_lock;
>
> struct list_head active_list_head;
> - spinlock_t active_list_lock;
>
> +#ifdef CONFIG_DEBUG_FS
> struct list_head sync_timeline_list;
> +#endif
> };
>
> /**
> * struct sync_pt - sync point
> - * @parent: sync_timeline to which this sync_pt belongs
> + * @fence: base fence class
> * @child_list: membership in sync_timeline.child_list_head
> * @active_list: membership in sync_timeline.active_list_head
> +<<< current
> * @signaled_list: membership in temporary signaled_list on stack
> * @fence: sync_fence to which the sync_pt belongs
> * @pt_list: membership in sync_fence.pt_list_head
> * @status: 1: signaled, 0:active, <0: error
> * @timestamp: time which sync_pt status transitioned from active to
> * signaled or error.
> +===
> +>>> patched
Conflict markers ...
> */
> struct sync_pt {
> - struct sync_timeline *parent;
> - struct list_head child_list;
> + struct fence base;
Hm, embedding feels wrong, since that still means that I'll need to
implement two kinds of fences in i915 - one using the seqno fence to make
dma-buf sync work, and one to implmenent sync_pt to make the android folks
happy.
If I can dream I think we should have a pointer to an underlying fence
here, i.e. a struct sync_pt would just be a userspace interface wrapper to
do explicit syncing using native fences, instead of implicit syncing like
with dma-bufs. But this is all drive-by comments from a very cursory
high-level look. I might be full of myself again ;-)
-Daniel
>
> + struct list_head child_list;
> struct list_head active_list;
> - struct list_head signaled_list;
> -
> - struct sync_fence *fence;
> - struct list_head pt_list;
> +};
>
> - /* protected by parent->active_list_lock */
> - int status;
> +static inline struct sync_timeline *sync_pt_parent(struct sync_pt *pt) {
> + return container_of(pt->base.lock, struct sync_timeline, child_list_lock);
> +}
>
> - ktime_t timestamp;
> +struct sync_fence_cb {
> + struct fence_cb cb;
> + struct fence *sync_pt;
> + struct sync_fence *fence;
> };
>
> /**
> @@ -149,9 +147,7 @@ struct sync_pt {
> * @name: name of sync_fence. Useful for debugging
> * @pt_list_head: list of sync_pts in the fence. immutable once fence
> * is created
> - * @waiter_list_head: list of asynchronous waiters on this fence
> - * @waiter_list_lock: lock protecting @waiter_list_head and @status
> - * @status: 1: signaled, 0:active, <0: error
> + * @status: 0: signaled, >0:active, <0: error
> *
> * @wq: wait queue for fence signaling
> * @sync_fence_list: membership in global fence list
> @@ -160,17 +156,15 @@ struct sync_fence {
> struct file *file;
> struct kref kref;
> char name[32];
> -
> - /* this list is immutable once the fence is created */
> - struct list_head pt_list_head;
> -
> - struct list_head waiter_list_head;
> - spinlock_t waiter_list_lock; /* also protects sta
[PATCH] drm: Set the plane's crtc before calling disable_plane.
On Mon, 3 Mar 2014 13:38:36 -0800
St?phane Marchesin wrote:
> Some drivers like exynos need the crtc to be able to disable the plane,
> so set it before calling disable_plane.
>
> Signed-off-by: St?phane Marchesin
> ---
> drivers/gpu/drm/drm_crtc.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 3b7d32d..0943316 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1947,10 +1947,21 @@ int drm_mode_setplane(struct drm_device *dev, void
> *data,
> }
> plane = obj_to_plane(obj);
>
> + obj = drm_mode_object_find(dev, plane_req->crtc_id,
> +DRM_MODE_OBJECT_CRTC);
> + if (!obj) {
> + DRM_DEBUG_KMS("Unknown crtc ID %d\n",
> + plane_req->crtc_id);
> + ret = -ENOENT;
> + goto out;
> + }
> + crtc = obj_to_crtc(obj);
> +
> /* No fb means shut it down */
> if (!plane_req->fb_id) {
> drm_modeset_lock_all(dev);
> old_fb = plane->fb;
> + plane->crtc = crtc;
> plane->funcs->disable_plane(plane);
> plane->crtc = NULL;
> plane->fb = NULL;
> @@ -1958,16 +1969,6 @@ int drm_mode_setplane(struct drm_device *dev, void
> *data,
> goto out;
> }
>
> - obj = drm_mode_object_find(dev, plane_req->crtc_id,
> -DRM_MODE_OBJECT_CRTC);
> - if (!obj) {
> - DRM_DEBUG_KMS("Unknown crtc ID %d\n",
> - plane_req->crtc_id);
> - ret = -ENOENT;
> - goto out;
> - }
> - crtc = obj_to_crtc(obj);
> -
> fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
> if (!fb) {
> DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
I'm pretty sure this is ok since we don't have much userspace using
this that might fail to pass in a crtc when shutting down a plane...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #9 from Chris Rankin --- Has anyone ever "valground" a 32 bit executable on a box which is natively 64 bit, please? This bug is currently making it impossible to run Wow-64.exe: http://bugs.winehq.org/show_bug.cgi?id=35582 That in itself isn't an issue - the memory leak occurs with both 32 bit and 64 bit WoW. However, the following command is failing: $ valgrind --trace-children=yes --leak-check=full /usr/bin/wine /opt/wine/World\ of\ Warcraft/Wow.exe -opengl -noautoload64bit with this error: valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No such file or directory Which I assume means that Valgrind is trying to use 64 bit tools on a 32 bit executable. -- 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/20140303/a828cca6/attachment.html>
[PATCH] drm: Set the plane's crtc before calling disable_plane.
On Mon, Mar 3, 2014 at 4:45 PM, Jesse Barnes
wrote:
> On Mon, 3 Mar 2014 13:38:36 -0800
> St?phane Marchesin wrote:
>
>> Some drivers like exynos need the crtc to be able to disable the plane,
>> so set it before calling disable_plane.
>>
>> Signed-off-by: St?phane Marchesin
>> ---
>> drivers/gpu/drm/drm_crtc.c | 21 +++--
>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 3b7d32d..0943316 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1947,10 +1947,21 @@ int drm_mode_setplane(struct drm_device *dev, void
>> *data,
>> }
>> plane = obj_to_plane(obj);
>>
>> + obj = drm_mode_object_find(dev, plane_req->crtc_id,
>> +DRM_MODE_OBJECT_CRTC);
>> + if (!obj) {
>> + DRM_DEBUG_KMS("Unknown crtc ID %d\n",
>> + plane_req->crtc_id);
>> + ret = -ENOENT;
>> + goto out;
>> + }
>> + crtc = obj_to_crtc(obj);
>> +
>> /* No fb means shut it down */
>> if (!plane_req->fb_id) {
>> drm_modeset_lock_all(dev);
>> old_fb = plane->fb;
>> + plane->crtc = crtc;
just curious, but how is the plane ending up enabled *without* a crtc?
That sounds a bit.. odd..
BR,
-R
>> plane->funcs->disable_plane(plane);
>> plane->crtc = NULL;
>> plane->fb = NULL;
>> @@ -1958,16 +1969,6 @@ int drm_mode_setplane(struct drm_device *dev, void
>> *data,
>> goto out;
>> }
>>
>> - obj = drm_mode_object_find(dev, plane_req->crtc_id,
>> -DRM_MODE_OBJECT_CRTC);
>> - if (!obj) {
>> - DRM_DEBUG_KMS("Unknown crtc ID %d\n",
>> - plane_req->crtc_id);
>> - ret = -ENOENT;
>> - goto out;
>> - }
>> - crtc = obj_to_crtc(obj);
>> -
>> fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
>> if (!fb) {
>> DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
>
> I'm pretty sure this is ok since we don't have much userspace using
> this that might fail to pass in a crtc when shutting down a plane...
>
> Reviewed-by: Jesse Barnes
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 74539] [r600g] Memory leak when playing WoW with RV790
https://bugs.freedesktop.org/show_bug.cgi?id=74539 --- Comment #10 from Chris Rankin --- (In reply to comment #9) > valgrind: failed to start tool 'memcheck' for platform 'amd64-linux': No > such file or directory More specifically: Valgrind is falling back to the x86_64 platform when executing the "--trace-children=yes" option! -- 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/20140303/257cb643/attachment.html>
[Bug 75005] "Upvoid" segfault in radeonsi/llvm
https://bugs.freedesktop.org/show_bug.cgi?id=75005 Christoph Haag changed: What|Removed |Added Attachment #94106|0 |1 is obsolete|| --- Comment #6 from Christoph Haag --- Created attachment 95062 --> https://bugs.freedesktop.org/attachment.cgi?id=95062&action=edit stderr of upvoid with R600_DEBUG=ps,vs,gs that triggered GPU fault (In reply to comment #5) > Can you try this branch: > http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes > > If you experience any crashes or hangs please post the output of > R600_DEBUG=ps,vs,gs I wasted some time compiling, clang was fixed for this branch version in 202737... Just in case anyone else is trying this. Anyway, my very comprehensive tests of about 5 runs :) seem like the GPU faults and hangs still happen, mostly if the game window is maximized. If it is not maximized and only a small window it does run longer and much more rarely hangs the GPU, and sometimes the game fails in several ways. That might be partly due to it being an alpha release, but maybe sometimes it's because of the driver? Don't know. Maybe you can decide whether it is caused by the problems here or needs new bugs. E.g. this results in SIGABRT and then(?) SIGILL: UpvoidEngine: r600_query.c:749: r600_suspend_nontimer_queries: Assertion `ctx->num_cs_dw_nontimer_queries_suspend == 0' failed. I can post a full backtrace if you want. It's currently segfaulting too much in unrelated code to get the segfault backtrace I originally wanted that involves almost only radeonsi, so I'll just attach the stderr output of one of the gpu fault hangs with R600_DEBUG=ps,vs,gs and try again later. -- 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/20140303/e8b4cc4d/attachment.html>
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #54 from saadnaji89 at gmail.com --- (In reply to Michel D?nzer from comment #53) > (In reply to saadnaji89 from comment #51) > > I am runnig Manjaro (Arch based distro 64 bit) with Kernel 3.13.5 as right > > now and I am having the same error except that I am geting repetitive blocks > > in the kernel log like this ever certain amount of time: > > See comment #35. > > > > and this is causing freeze for my laptop for 2-3 seconds, as well as causing > > the temperature of the gpu to raise up by 10 C . > > You probably need my Mesa patch to prevent the GPU from powering up > needlessly: https://bugzilla.kernel.org/attachment.cgi?id=126011 Thanks you. Are we going to see this patch applied to fix the problem in future kernel veriosn ?. I don't know whether you work for AMD or just someone is contributing to fix the problem -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #55 from Christoph Haag --- (In reply to saadnaji89 from comment #54) > Are we going to see this patch applied to fix the problem in future kernel > veriosn ?. I don't know whether you work for AMD or just someone is > contributing to fix the problem I wondered whether to reply, but now... He works for AMD. It's even on Wikipedia. This patch is not to the kernel, it is to mesa. It has been in mesa for 14 days: http://cgit.freedesktop.org/mesa/mesa/commit/?id=cf0172d46ab940a691da6516057c81f28961482f (Is it necessary to keep talking about already fixed stuff?) I'd say the only reason this is not closed yet is because of the radeon module unloading problems. Thinking of it, I haven't tried in a while.. Should I try to get some more information for it or is the delay just until someone has time to look at it? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75732] New: Memory leak with celestia
https://bugs.freedesktop.org/show_bug.cgi?id=75732 Priority: medium Bug ID: 75732 Assignee: dri-devel at lists.freedesktop.org Summary: Memory leak with celestia Severity: normal Classification: Unclassified OS: Linux (All) Reporter: rankincj at googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa This bug might be a duplicate of #74549. However, WoW + Wine + Valgrind is currently proving to be an intractable problem, and so I've decided to Valgrind celestia instead (since at least I've managed to get THAT to running again on x86_64!!!) For this test, git HEAD was set to: commit 9bace99d77642f8fbd46b1f0be025ad758f83f5e Author: Zack Rusin Date: Tue Jan 28 16:34:18 2014 -0500 gallivm: fix opcode and function nesting I executed the following command: $ valgrind --leak-check=full celestia and amidst all of the other issues that Valgrind complained about, it also happened to mention this: ==7446== 352 bytes in 1 blocks are possibly lost in loss record 8,803 of 9,718 ==7446==at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==7446==by 0x4011C44: _dl_allocate_tls (dl-tls.c:296) ==7446==by 0xBEE8862: pthread_create@@GLIBC_2.2.5 (allocatestack.c:580) ==7446==by 0x22F18208: pipe_thread_create.constprop.7 (threads_posix.h:264) ==7446==by 0x22F18B47: radeon_drm_winsys_create (radeon_drm_winsys.c:661) ==7446==by 0x22BA18F5: create_screen (drm_target.c:38) ==7446==by 0x22F13876: dri2_init_screen (dri2.c:1044) ==7446==by 0x22BA295F: driCreateNewScreen2 (dri_util.c:158) ==7446==by 0x52DC260: dri2CreateScreen (dri2_glx.c:1240) ==7446==by 0x52B67E8: __glXInitialize (glxext.c:778) ==7446==by 0x52B31AA: GetGLXPrivScreenConfig.part.2 (glxcmds.c:174) ==7446==by 0x52B392F: glXChooseVisual (glxcmds.c:170) ==7446== ==7446== 360 bytes in 5 blocks are possibly lost in loss record 8,811 of 9,718 ==7446==at 0x4C291D4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==7446==by 0xA24CEC6: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.3800.2) ==7446==by 0x9FBC1D4: g_closure_new_simple (in /usr/lib64/libgobject-2.0.so.0.3800.2) ==7446==by 0x9FBD671: g_cclosure_new (in /usr/lib64/libgobject-2.0.so.0.3800.2) ==7446==by 0x781E83F: gtk_action_group_add_toggle_actions_full (in /usr/lib64/libgtk-x11-2.0.so.0.2400.22) ==7446==by 0x4623F5: main (in /usr/bin/celestia) -- 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/20140303/a1a83574/attachment-0001.html>
[Bug 75732] [r600g] Memory leak with celestia, RV790
https://bugs.freedesktop.org/show_bug.cgi?id=75732 Chris Rankin changed: What|Removed |Added Summary|Memory leak with celestia |[r600g] Memory leak with ||celestia, RV790 -- 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/20140303/cc7a2fbe/attachment.html>
[RFC] drm/msm: use componentised device support
Hey Russell,
Here is a early/rough pass at conversion to componentized device support.
I was hoping you could have a quick look at this to make sure I'm on the
right track, since there were no non-DT examples for me to look at ;-)
I still haven't gotten rid of the global hdmi_pdev and a3xx_pdev ptrs. I
am not entirely sure how to find those subordinate device pointers again
without DT/phandle stuff. I think I might need something like:
struct device *component_find(struct device *dev, const char *name)
{
struct master *master;
struct component *c;
struct device *component = NULL;
mutex_lock(&component_mutex);
master = __master_find(dev, NULL);
if (master) {
list_for_each_entry(c, &master->components, master_node) {
if (!strcmp(name, dev_name(c->dev))) {
/* maybe take a ref to the device? */
component = c->dev;
break;
}
}
}
mutex_unlock(&component_mutex);
return component;
}
or I could probably hack around it somehow in msm.. I suppose I'm the only
one who still has to care for a bit longer about componentized + !DT.
Also still need to remove the extra MODULE_DEVICE_TABLE()'s for DT case
and few other little things.
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 34 ++---
drivers/gpu/drm/msm/hdmi/hdmi.c | 38 +++---
drivers/gpu/drm/msm/msm_drv.c | 128 +-
drivers/gpu/drm/msm/msm_drv.h | 1 +
4 files changed, 179 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index e6cb2bc..1f0bbf7 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -556,17 +556,17 @@ fail:
# include
#endif
-static int a3xx_probe(struct platform_device *pdev)
+static int a3xx_bind(struct device *dev, struct device *master, void *data)
{
static struct adreno_platform_config config = {};
#ifdef CONFIG_OF
- struct device_node *child, *node = pdev->dev.of_node;
+ struct device_node *child, *node = dev->of_node;
u32 val;
int ret;
ret = of_property_read_u32(node, "qcom,chipid", &val);
if (ret) {
- dev_err(&pdev->dev, "could not find chipid: %d\n", ret);
+ dev_err(dev, "could not find chipid: %d\n", ret);
return ret;
}
@@ -582,7 +582,7 @@ static int a3xx_probe(struct platform_device *pdev)
for_each_child_of_node(child, pwrlvl) {
ret = of_property_read_u32(pwrlvl,
"qcom,gpu-freq", &val);
if (ret) {
- dev_err(&pdev->dev, "could not find
gpu-freq: %d\n", ret);
+ dev_err(dev, "could not find gpu-freq:
%d\n", ret);
return ret;
}
config.fast_rate = max(config.fast_rate, val);
@@ -592,12 +592,12 @@ static int a3xx_probe(struct platform_device *pdev)
}
if (!config.fast_rate) {
- dev_err(&pdev->dev, "could not find clk rates\n");
+ dev_err(dev, "could not find clk rates\n");
return -ENXIO;
}
#else
- struct kgsl_device_platform_data *pdata = pdev->dev.platform_data;
+ struct kgsl_device_platform_data *pdata = dev->platform_data;
uint32_t version = socinfo_get_version();
if (cpu_is_apq8064ab()) {
config.fast_rate = 45000;
@@ -643,14 +643,30 @@ static int a3xx_probe(struct platform_device *pdev)
config.bus_scale_table = pdata->bus_scale_table;
# endif
#endif
- pdev->dev.platform_data = &config;
- a3xx_pdev = pdev;
+ dev->platform_data = &config;
+ a3xx_pdev = to_platform_device(dev);
return 0;
}
-static int a3xx_remove(struct platform_device *pdev)
+static void a3xx_unbind(struct device *dev, struct device *master,
+ void *data)
{
a3xx_pdev = NULL;
+}
+
+static const struct component_ops a3xx_ops = {
+ .bind = a3xx_bind,
+ .unbind = a3xx_unbind,
+};
+
+static int a3xx_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &a3xx_ops);
+}
+
+static int a3xx_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &a3xx_ops);
return 0;
}
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index b8d902d..71c58b9 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -255,17 +255,17 @@ fail:
#include
-static int hdmi_dev_probe(struct platform_device *pdev)
+static int hdmi_bind(struct device *dev, struct device *master, void *data)
{
static struct hdmi_platform_config config = {};
#ifdef CONFIG_OF
- struct device_node *of_node = pdev->dev.of_node;
+ s
Should drm's modetest work when an X server is running?
Dear dri developers,
Should libdrm's modetest work when an X server is running?
Should drmOpen(name, NULL) succeed when the drm device is already open?
Is "name" passed to drmOpen() the "drm" name returned by drmGetVersion()?
Or, is it the the kernel driver/module name?
tl;dr
Over the past couple of days I have been trying to get "modetest" from
the libdrm repository to run on my exynos based ARM chromebook.
With an X server running, "modetest" fails like this:
# modetest
trying to open device 'exynos'...failed.
no device found.
Without an X server, "modetest" succeeds:
# modetest
trying to open device 'exynos'...success.
Encoders:
id crtc type possible crtcs possible clones
15 5 TMDS 0x0001 0x0003
18 0 TMDS 0x0002 0x0003
...
So, why is modetest failing when the X server is running?
If we don't specify a module (-M) or device (-D) on the command line,
modetest searches through a hard coded list of "modules":
const char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx",
"omapdrm", "exynos", "tilcdc", "msm" };
For each module, it tries to open it with drmOpen:
dev.fd = drmOpen(modules[i], device);
When checking for "exynos", this becomes...
drmOpen("exynos", NULL), which first calls
-> drmAvailable()
-> drmOpenMinor(0, 1, DRM_NODE_RENDER)
-> drmOpenDevice(makedev(DRM_MAJOR, 0), 0, DRM_NODE_RENDER);
-> this eventually calls open("/dev/dri/card0"), which returns
a valid fd.
drmOpen("exynos", NULL) then calls
-> drmOpenByName("exynos")
-> /* Redundant drmAvailable() check */
-> for i=0:15:
-> drmOpenMinor(i, 1, DRM_NODE_RENDER);
-> if it returns a valid fd: version = drmGetVersion(fd)
-> if version->name == "exynos": id = drmGetBusid(fd);
-> if id != NULL && id != "": Success! return the fd
In other words, drmOpen("exynos", NULL) succeeds if any of
"/dev/dri/card*" can be opened, it drmGetVersion() succeeds and
returns version->name == "exynos", and if drmGetBusid(fd) is NULL or
"". In other words, it opens the first minor number that matches the
DRM "version" name and doesn't already have a busid assigned (ie, the
first matching minor that isn't in use).
So, this explains why modetest works when my X server is stopped. The
drm name matches, and there is no busid, so drmOpen() happily returns
an fd.
But on a system with intel graphics (i915), modetest works even with
the X server running, why?
It turns out that there is another chunk of code in drmOpenByName(),
that is linux only, and implements "Backward-compatibility /proc
support". In a loop it reads "/proc/dri/*/name" and matches the first
field against the "name" passed in to drmOpenByName(). If this
matches:
* if there are 3 fields, the 3rd field is passed to drmOpenByBusid()
* if there were only 2 fields, the 2nd field is parsed as a long and
passed as the dev parameter to drmOpenDevice().
"On my intel machine, the first field is "i915", the same name
returned as the version->name for drmGetVersion(), so we end up doing
something like drmOpenByBusid("pci::00:02.0), which succeeds
because that matches what is returned by drmGetBusid().
$ cat /proc/dri/0/name
i915 :00:02.0 pci::00:02.0
But, for exynos, the the driver name is actually "exynos-drm", so the
check fails, and drmOpen("exynos", NULL) fails.
# cat /proc/dri/0/name
exynos-drm exynos-drm platform:exynos-drm:00
I'm obviously using an older kernel. From the kernel git log, I see
that danvet recently removed the entire proc interface. So, does that
mean that on up to date kernels modetest (and the other libdrm tests)
will now also fail for intel if X is running (since the proc back door
is no longer available)?
Is this "working as intended"?
-Dan
[PATCH] drm: Check if the allocation has succeeded before dereferencing newmode
We allocate memory in drm_display_mode_from_vic_index() and use it without checking the pointer is valid. Fix that. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_edid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index f8d8a1d..f3cde90 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2580,6 +2580,9 @@ drm_display_mode_from_vic_index(struct drm_connector *connector, return NULL; newmode = drm_mode_duplicate(dev, &edid_cea_modes[cea_mode]); + if (!newmode) + return NULL; + newmode->vrefresh = 0; return newmode; -- 1.8.3.1
Should drm's modetest work when an X server is running?
On Mon, Mar 3, 2014 at 6:53 PM, Daniel Kurtz wrote:
> But, for exynos, the the driver name is actually "exynos-drm", so the
> check fails, and drmOpen("exynos", NULL) fails.
>
> # cat /proc/dri/0/name
> exynos-drm exynos-drm platform:exynos-drm:00
oh, hmm, yeah, I guess you break a few assumptions if the drm name !=
device name.. I guess mostly nobody notices because usually xserver
uses drmOpen() and mesa just open()'s the device file path passed from
xserver.
BR,
-R
[PATCH] drm/tilcdc increase allowable supported resolution
From: Darren Etheridge
1680x1050 appears to also be within the bandwidth capabilities
of the device and memory infrastructure.
Signed-off-by: Darren Etheridge
---
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 5bb64e3..b47ec24 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -43,7 +43,7 @@
* with optimized DDR & EMIF settings tweaked 1920x1080 at 24 appears to
* be supportable
*/
-#define TILCDC_DEFAULT_MAX_BANDWIDTH (1280*1024*60)
+#define TILCDC_DEFAULT_MAX_BANDWIDTH (1680*1050*60)
struct tilcdc_drm_private {
--
1.9.0
[PATCH 00/11] SimpleDRM & Sysfb
On 03/03/14 13:09, David Herrmann wrote: >> What do you think, would it be possible to keep the sysfb stuff in >> arch/x86, and still be able to do the rest of the stuff here? And then >> move the sysfs from arch/x86 to drivers/video later? > > I don't think there's any need for that. Linus does conflict > resolution all day long, so a short hint in Dave's pull-request (plus > an example merge) should be enough. Same is true for -next, I think. True, but, well, the conflict with this one is not a few lines. "git diff |wc -l" gives 2494 lines for the conflict. It's not really complex to resolve that one, though, as it's really about copying all the stuff into its new place. So I'm not sure if that makes Linus think "this is simple one, 30 secs and done" or "who the f*** sends me this crap" ;). Especially for two reasons: - The fb-reogranization is not very critical, and often clean-ups are not worth it (although I think this one is good one, of course). - Conflicting fbdev changes coming from another tree > And this is really just a mechanical thing, nothing hard to do. But of > course, it's your decision. However, keeping the code in x86 is the > wrong thing to do. As discussed with Ingo, the patch that extends Yes, I didn't mean keeping the code in x86 for good, but just for one kernel version to make merging easier. > x86/sysfb is only provided for easier backporting. The followup patch > immediately removes it again and adds proper video/sysfb. I'd dislike > splitting these just to avoid merge conflicts. I can also maintain a > merge-fixup branch in my tree, if anyone wants that. You can have a try at merging. If you think it's trivial, maybe it is and we can just let Linus handle it: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/fb-reorder Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/8293e00b/attachment-0001.pgp>
[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
On 28/02/14 15:43, Philipp Zabel wrote: > Hi Tomi, > > Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen: >> Add DT binding documentation for DVI Connector. >> >> Signed-off-by: Tomi Valkeinen >> Reviewed-by: Archit Taneja >> --- >> .../devicetree/bindings/video/dvi-connector.txt| 26 >> ++ >> 1 file changed, 26 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt >> >> diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt >> b/Documentation/devicetree/bindings/video/dvi-connector.txt >> new file mode 100644 >> index ..6a0aff866c78 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt >> @@ -0,0 +1,26 @@ >> +DVI Connector >> +== >> + >> +Required properties: >> +- compatible: "dvi-connector" >> + >> +Optional properties: >> +- label: a symbolic name for the connector >> +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC > > For the i.MX bindings I had called this property 'ddc', but > Documentation/devicetree/bindings/panel/simple-panel.txt already > uses 'ddc-i2c-bus'. We should definitely standardize this. I like 'ddc-i2c-bus'. Tomi -- next part ------ A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/3f2b2a36/attachment-0001.pgp>
[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
On 28/02/14 18:23, Russell King - ARM Linux wrote: >> I guess the compatible string is the easiest way for differentation, at >> least for the three main types, i.e. "dvi-d-connector" etc. >> >> "dvi-d-1l-connector" and "dvi-d-2l-connector" for the single/dual link? >> That looks a bit funny. > > I think that starts getting a tad messy: > > dvi-a-connector > dvi-d-1l-connector > dvi-d-2l-connector > dvi-i-1l-connector > dvi-i-2l-connector Yes, it's messy. Pondering this over the weekend, I think it makes sense to have just one compatible string, as all those connectors are still the same DVI connector, just different variations of the same. > That's rather a lot of compatible strings. Another possibility is: > > compatible = "dvi-connector"; > analog; > digital; > single-link; > dual-link; > > I'm debating whether "-signalling" should be on the 2nd and 3rd (or... > -signaling depending on how you prefer to spell that word.) At least > one of "analog" and/or "digital" must be specified, and if "digital" > is specified, then exactly one of "single-link" or "dual-link" should > be specified. > > So, this would mean we end up with: > > compatible = "dvi-connector"; > analog; > digital; > dual-link; > > for a DVI-I dual-link connector. Another option would be: num-links = 2; But I like your suggestion more. We could also optimize it, "digital" is extra as both "single-link" and "dual-link" mean also digital. But... I don't see much point in optimizing that way. So I agree with your suggestion as is. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/8ac18169/attachment.pgp>
[PATCH 4/9] Doc/DT: Add DT binding documentation for HDMI Connector
On 01/03/14 20:58, Geert Uytterhoeven wrote: > On Fri, Feb 28, 2014 at 5:34 PM, Russell King - ARM Linux > wrote: >> There's actually three HDMI connectors: >> >> All three connectors carry all required HDMI signals, including a TMDS >> link. The Type B connector is slightly larger and carries a second TMDS >> link, which is necessary to support very high resolution displays using >> dual link. The Type C connector carries the same signals as the Type A >> but is more compact and intended for mobile applications. >> >> So, Type C and Type A are electrically the same. > > There's also D (e.g. on BeagleBone Black) and E: > > http://en.wikipedia.org/wiki/HDMI#Connectors > > Electrically they seem to be the same as A/C. Right. And then there are the HDMI versions, and things like HDMI Ethernet Channel. After looking at these a bit, I don't think the HDMI connector needs any of those (hdmi version, eth) defined. So... compatible = "hdmi-connector"; type = "a"; Or compatible = "hdmi-connector"; type-a; I don't right away see any big pro with either one compared to the other. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/9622c09d/attachment-0001.pgp>
[PATCH 0/9] Doc/DT: DT bindings for various display components
Hi Rob, Pawel, Mark, Ian, Kumar, On 28/02/14 18:56, Russell King - ARM Linux wrote: > On Fri, Feb 28, 2014 at 06:48:35PM +0200, Tomi Valkeinen wrote: >> This is totally unclear to me. How does it become a public standard? >> What's the forum for this? > > Me too. That's where I'd hope someone on devicetree-discuss will be > able to help us work out what's the right approach here. :) The story briefly so far: I've implemented DT support for OMAP display, and created bindings for various (non-OMAP) display components, including generic connector bindings for DVI, HDMI and analog-tv. Russell's point was that these connector bindings are very generic, i.e. they are not for any particular chip from a particular vendor, but for any connector for DVI, HDMI or analog-tv. And he's worried that maybe we shouldn't define such generic bindings without consulting the whole device-tree community (i.e including non-linux users). So the question is, is there such a community and a forum to bring up this kind of things? If yes, should we bring this up there? If yes, what kind of things in general should be brought into the attention of non-linux users? What I wonder here is that while a thing like DVI connector is, of course, more generic than, say, "ti,tfp410" encoder chip, but isn't the case still the same: we're defining global bindings for hardware that should work for everyone, not only Linux users? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/e40abbd0/attachment-0001.pgp>
[PATCH 00/11] SimpleDRM & Sysfb
Hi, On 23/01/14 16:14, David Herrmann wrote: > Hi > > Another round of SimpleDRM patches. I somehow lost track of the last ones and > as > this is a major rewrite, I'll just start at v1 again. > > Some comments up-front: > > - @Ingo: Patch #1 and #2 are unchanged from the previous ML discussions. I >included them in this series as the other patches depend on them. Could you >pick them up for the x86 tree? The other 9 patches won't make it in 3.14 so >no reason to put them through the DRM tree. >All mentioned issues should be addressed. If there's still sth missing, >please let me know. > > - The DRM patches depend on my "DRM Anonymous Inode" patches. But it should > be >trivial to apply them on drm-next (I think only one line needs to be > changed: >i_mapping => dev_mapping). > > - I tested the SimpleDRM fbdev fallback with linux-console+Xorg and it works >fine. The DRM backend is only tested with some DRM tests I have locally. I >have no idea how to make Xorg pick up a specific /dev/dri/card0 card. It >always tells me "no screens found" (as the underlying device is not marked > as >boot_vga..). If someone knows how to tell Xorg to use card0, I'd gladly > test >this. But I'm no longer used to writing xorg.confs.. > > > This series introduces two new concepts: sysfb and SimpleDRM > Sysfb is just a generalization of the x86-sysfb concept. It allows to register > firmware-framebuffers with the system as platform-devices. This way, drivers > can > properly bind to these devices and we prevent multiple drivers from accessing > the same firmware-framebuffer. > Sysfb also provides hooks to get a safe handover to real hw-drivers (like > i915). > Please see the "video: sysfb: add generic firmware-fb interface" patch for a > thorough description of the API. This patch also adds a rather verbose > documentation of all known firmware-fb facilities. > > As second part, this series introduces SimpleDRM. It's a very basic DRM driver > that can replace efifb, vesafb, simplefb and friends. It's 100% compatible to > the "udl" DRM driver, so user-space like xf86-video-modesetting can pick them > up > just fine. User-space that cannot deal with drmModeDirtyFB() (like weston and > friends) currently cannot use SimpleDRM. However, that's also true for all > other > DRM drivers which provide shadow framebuffers. We could provide something like > FB-DEFIO, but that's just useless overhead to paper of lazy user-space. > > I have tested this with all hardware that I have at home, with a lot hand-over > combinations (with/without SYSFB, with efifb/vesafb/simplefb, with SimpleDRM, > ...) and all worked great so far. What's the status with this one? Headed for 3.15? Are the SimpleDRM and sysfb linked somehow? (I.e. do they need to be in the same series?) And jfyi, the drivers/video/ changes will conflict with the drivers/video/ directory reorganization series, which may be merged for 3.15. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/ecd1aafa/attachment-0001.pgp>
[PATCH 00/11] SimpleDRM & Sysfb
On 03/03/14 12:29, David Herrmann wrote: >> What's the status with this one? Headed for 3.15? >> >> Are the SimpleDRM and sysfb linked somehow? (I.e. do they need to be in >> the same series?) >> >> And jfyi, the drivers/video/ changes will conflict with the >> drivers/video/ directory reorganization series, which may be merged for >> 3.15. > > If simpledrm is included, then the series needs to be applied as a > whole. As Dave considered merging this for 3.15, I'd appreciate it if > you could ACK the fbdev related patches (they're really small!): > fbdev: efifb: add dev->remove() callback > fbdev: vesafb: add dev->remove() callback Those look fine. I'm not familiar with x86 fb, so I can't comment much to the series, but what worries me more is the "[PATCH 06/11] video: sysfb: add generic firmware-fb interface", which adds new stuff into drivers/video/. No problem as such, but as said, it'll conflict with the fbdev reorg patches. So, presuming nobody shoots down the fbdev reorg series, I'd like to have all fbdev patches going through the fbdev tree for 3.15, so that I can handle the (possibly messy) conflicts. What do you think, would it be possible to keep the sysfb stuff in arch/x86, and still be able to do the rest of the stuff here? And then move the sysfs from arch/x86 to drivers/video later? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/99879d2e/attachment-0001.pgp>
[PATCH] MAINTAINERS: add maintainer entry for TDA998x driver
Add a maintainers entry for the TDA998x driver. Rob Clark has handed this driver over to me to look after. Acked-by: Rob Clark Signed-off-by: Russell King --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 78d970649300..90cbbf4bf04c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6161,6 +6161,12 @@ S: Supported F: drivers/block/nvme* F: include/linux/nvme.h +NXP TDA998X DRM DRIVER +M: Russell King +S: Supported +F: drivers/gpu/drm/i2c/tda998x_drv.c +F: include/drm/i2c/tda998x.h + OMAP SUPPORT M: Tony Lindgren L: linux-omap at vger.kernel.org -- 1.8.3.1
[PATCH] drm/i2c: tda998x: potentially faster polling for edid
One of Jean-Francois patches changed the EDID polling to once every
10ms for 10 interations, whereas the original code did 1ms for 100
interations. This appears to cause boot-time detection to take
slightly - but noticably - longer. Revert this change.
Signed-off-by: Russell King
---
Jean,
I'm not sure why you made the change along with adding IRQ support in
"drm/i2c: tda998x: use irq for connection status and EDID read" - you
didn't include any commentry as to why you made this change. However,
we shouldn't write code assuming HZ=100 - where this kind of thing
matters, we should come up with better solutions (eg, using jiffy-based
timeouts if we want to timeout after a set period of time.)
I'm not sure whether one or other really is faster, it's just a
perception I have. Anyway, let's just revert back to the original
code for the non-IRQ case, and maybe improve it later.
drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 40c4f658abfb..956d857ee2c9 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1041,8 +1041,8 @@ static int read_edid_block(struct tda998x_priv *priv,
uint8_t *buf, int blk)
return i;
}
} else {
- for (i = 10; i > 0; i--) {
- msleep(10);
+ for (i = 100; i > 0; i--) {
+ msleep(1);
ret = reg_read(priv, REG_INT_FLAGS_2);
if (ret < 0)
return ret;
--
1.8.3.1
[GIT PULL] Another Armada DRM fix
David, Please incorporate the latest Armada DRM fixes, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-cubox.git drm-armada-fixes with SHA1 d13c46c67e546bb1dc1c4dc7c43e388d0119276b. I think the blame for this comes down to me - I complained about the kfifo API, but I didn't expect it to change as quickly as it did. Strangely, this didn't cause any visible problems... the machine has been through many boots without issue. Then I tried playing back video where it immediately exploded. Then it wouldn't boot anymore without oopsing, despite it being the same kernel which booted all the way through to Xorg without issue... fun. This will update the following files: drivers/gpu/drm/armada/armada_drv.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) through these changes: Russell King (1): DRM: armada: fix use of kfifo_put() Thanks.
[PATCH] drm/tilcdc: restore correct display mode and contents on pm resume
From: Darren Etheridge On resume the screen contents were not being restored properly. Looking at other DRM drivers it seems a call to drm_helper_resume_force_mode() is needed in the resume handler to force restoration of the mode and framebuffer data. Signed-off-by: Darren Etheridge --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 171a820..1a5ddfa 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -563,6 +563,13 @@ static int tilcdc_pm_resume(struct device *dev) if (registers[i].save && (priv->rev >= registers[i].rev)) tilcdc_write(ddev, registers[i].reg, priv->saved_register[n++]); + /* +* if this call isn't here, the display is blank on return from +* suspend. With this call here the contents of the framebuffer +* during suspend are restored correctly. +*/ + drm_helper_resume_force_mode(ddev); + drm_kms_helper_poll_enable(ddev); return 0; -- 1.9.0
[PATCH] drm: Set the plane's crtc before calling disable_plane.
Some drivers like exynos need the crtc to be able to disable the plane,
so set it before calling disable_plane.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/drm_crtc.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3b7d32d..0943316 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1947,10 +1947,21 @@ int drm_mode_setplane(struct drm_device *dev, void
*data,
}
plane = obj_to_plane(obj);
+ obj = drm_mode_object_find(dev, plane_req->crtc_id,
+ DRM_MODE_OBJECT_CRTC);
+ if (!obj) {
+ DRM_DEBUG_KMS("Unknown crtc ID %d\n",
+ plane_req->crtc_id);
+ ret = -ENOENT;
+ goto out;
+ }
+ crtc = obj_to_crtc(obj);
+
/* No fb means shut it down */
if (!plane_req->fb_id) {
drm_modeset_lock_all(dev);
old_fb = plane->fb;
+ plane->crtc = crtc;
plane->funcs->disable_plane(plane);
plane->crtc = NULL;
plane->fb = NULL;
@@ -1958,16 +1969,6 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
goto out;
}
- obj = drm_mode_object_find(dev, plane_req->crtc_id,
- DRM_MODE_OBJECT_CRTC);
- if (!obj) {
- DRM_DEBUG_KMS("Unknown crtc ID %d\n",
- plane_req->crtc_id);
- ret = -ENOENT;
- goto out;
- }
- crtc = obj_to_crtc(obj);
-
fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
if (!fb) {
DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
--
1.9.0.279.gdc9e3eb
[Intel-gfx] [PATCH] drm/i915: add support for Z-order of planes.
On 14-02-28 11:28 AM, Matt Roper wrote: > On Fri, Feb 28, 2014 at 06:03:11PM +0200, Ville Syrj?l? wrote: >> On Thu, Feb 27, 2014 at 03:44:04PM -0800, Matt Roper wrote: >>> On Thu, Feb 27, 2014 at 02:36:06PM -0800, Yu Dai wrote: On 14-02-25 04:19 PM, Matt Roper wrote: > On Thu, Feb 20, 2014 at 04:11:14PM -0800, yu.dai at intel.com wrote: >> From: "Yu(Alex) Dai" >> >> Add "zorder" property to crtc to control Z-order of sprite and >> primary planes. The alpha channel of the planes can be enabled >> or disabled during Z-order change. >> >> Signed-off-by: Yu(Alex) Dai > It seems like this is pretty VLV-specific at the moment. Aren't you > going to be writing bogus register values if you try to set this > property on a non-VLV platform? > > I'm not sure if any of the other non-VLV platforms supported by i915 > today can change plane z-orders or not, but this is likely to be > possible and useful on future platforms (or non-Intel platforms) as > well, which may have a different number of overall planes and different > ways of programming them. Yes, this is for VLV. New patch-set V3 was submitted. > Would it make more sense to move the z-order value to a plane property > so that the interface scales to any number of planes? If you just set > an integer value as a per-plane zorder-value, the code that actually > programs the hardware can go collect the values for each plane, sort > them to determine an order, and figure out what that translates to in > terms of platform-specific register programming. This would lend itself > nicely to the "check/calculate" step of the atomic/nuclear operation > once those interfaces land. The z-order of a plane really has no meaning until the actual composition is triggered. In Android, the order is determined by HWC when there are changes in layers. Breaking up this into plane property will evoke more drm IOCTL calls from user. The current "one-shot" call limits the flexibility but makes it simple. >>> That's true today where we only really have the ability to set >>> properties one by one. But I believe the end goal is to handle this >>> kind of functionality via the atomic/nuclear API's, where you wind up >>> shoving all the various things you want to change/program into a >>> property set (which happens in libdrm userspace) and then issue a single >>> ioctl which hands that property set to the kernel to be processed in a >>> sort of transactional model. >>> >>> Without the atomic/nuclear operations, I'm not sure how well z-order >>> property will really work in practice. If your compositor decides that >>> the next frame of content uses multiple hardware planes to display >>> various buffers, you really need to make sure that the z-order register >>> programming happens within the same vblank that the flips on each of >>> those planes take effect, otherwise things aren't going to look good to >>> the end user. With the non-atomic API's, I don't think there's really >>> any way to guarantee this. >> Yeah w/o the atomic API probably the only semi useable approach is to >> drop out from the sprite path when stuff actually moves around, and >> get back on it after the scene is again steady. >> >> As far as the z-order property, I did have a sort of similar idea >> originally where we'd define a bunch of different plane z-order >> combinations as an enum property on the crtc, and then the user has >> to choose one. That would make it easier for the user to figure out >> which way the planes can be stacked. This would be especially nice >> with some old Intel hardware where the z-order for the planes was >> specified using a couple of magic bits which severeily limited the >> ways you could stack the half a dozen or so planes. >> >> But then you'd either need to parse the string enum name to make any >> sense of it, or we'd need to encode the order in the value itself. But >> to be hardware agnostic, we'd need to use plane IDs in there, and those >> can in theory be up to 31bits, so we couldn't guarantee that the property >> value could hold more than two planes. Although I suppose we could use >> the plane index instead, which would then put the upper limit at 16 planes. >> Well, possibly more in case not all planes can be assigned to the same >> crtc. >> >> The simple approach is of course to have a range property per plane >> which defines the z-order. But then we need to worry about conflicts >> between z-order assignment, and it's harder for the user to figure out >> which combinations are legal. But the benefit is that this is the most >> obvious way to present this information. IIRC some people were >> suggesting we pick this scheme despite the limitations. >> >> -- >> Ville Syrj?l? >> Intel OTC > Conflicts between z-order assignments don't seem too worrisome to me; > I figure most display servers would pro
[PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel
On 28/02/14 15:40, Philipp Zabel wrote: > Am Freitag, den 28.02.2014, 14:20 +0200 schrieb Tomi Valkeinen: >> Add DT binding documentation for MIPI DPI Panel. >> >> Signed-off-by: Tomi Valkeinen >> Reviewed-by: Archit Taneja >> --- >> .../devicetree/bindings/video/panel-dpi.txt| 43 >> ++ >> 1 file changed, 43 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt >> >> diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt >> b/Documentation/devicetree/bindings/video/panel-dpi.txt >> new file mode 100644 >> index ..72636c6f1c67 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt >> @@ -0,0 +1,43 @@ >> +Generic MIPI DPI Panel >> +== >> + >> +Required properties: >> +- compatible: "panel-dpi" >> + >> +Optional properties: >> +- label: a symbolic name for the panel >> +- gpios: panel enable gpio and backlight enable gpio >> + >> +Required nodes: >> +- "panel-timing" containing video timings >> + (Documentation/devicetree/bindings/video/display-timing.txt) >> +- Video port for DPI input > > I don't see anything MIPI specific here. Couldn't this be added to the > existing simple-panel binding? Hmm, well, the simple-panel bindings doesn't define video ports, and not even a common compatible property. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/b3d21203/attachment.pgp>
[PATCH 0/3] Reorder drivers/video directory
On 27/02/14 13:54, Tomi Valkeinen wrote: > Hi, > > This is a re-send of the series, with RFC removed from the subject, and a > bunch > of acks added. > > I'm cc'ing more people, to make sure this doesn't come as a surprise, and to > make sure this is not a bad idea, doomed to fail horribly. > > So this series creates a new directory, drivers/video/fbdev/, to which all > fbdev related files are moved. Also, a new directory, > drivers/video/fbdev/core/ > is created, to which the core fbdev framework files are moved. This makes the > drivers/video hierarchy much more clear. > > Presuming no one has objections to this as such, I wonder what's the least > painful way to merge this? Normally, like any other fbdev change? As a > separate > pull request, maybe at -rc2 time frame, based on -rc1? Something else? > > Tomi > > Tomi Valkeinen (3): > video: move fbdev to drivers/video/fbdev > fbdev: move fbdev core files to separate directory > video: Kconfig: move drm and fb into separate menus I have pushed this to my for-next branch. Let's see what happens... At least I'm able to merge the current linux-next without any conflicts. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140303/0e115734/attachment.pgp>
[PATCH] drm: Set the plane's crtc before calling disable_plane.
On Mon, Mar 3, 2014 at 2:06 PM, Rob Clark wrote:
> On Mon, Mar 3, 2014 at 4:45 PM, Jesse Barnes
> wrote:
>> On Mon, 3 Mar 2014 13:38:36 -0800
>> St?phane Marchesin wrote:
>>
>>> Some drivers like exynos need the crtc to be able to disable the plane,
>>> so set it before calling disable_plane.
>>>
>>> Signed-off-by: St?phane Marchesin
>>> ---
>>> drivers/gpu/drm/drm_crtc.c | 21 +++--
>>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 3b7d32d..0943316 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -1947,10 +1947,21 @@ int drm_mode_setplane(struct drm_device *dev, void
>>> *data,
>>> }
>>> plane = obj_to_plane(obj);
>>>
>>> + obj = drm_mode_object_find(dev, plane_req->crtc_id,
>>> +DRM_MODE_OBJECT_CRTC);
>>> + if (!obj) {
>>> + DRM_DEBUG_KMS("Unknown crtc ID %d\n",
>>> + plane_req->crtc_id);
>>> + ret = -ENOENT;
>>> + goto out;
>>> + }
>>> + crtc = obj_to_crtc(obj);
>>> +
>>> /* No fb means shut it down */
>>> if (!plane_req->fb_id) {
>>> drm_modeset_lock_all(dev);
>>> old_fb = plane->fb;
>>> + plane->crtc = crtc;
>
> just curious, but how is the plane ending up enabled *without* a crtc?
> That sounds a bit.. odd..
Yup it has a crtc, but the plane->crtc is set to NULL just before we
call disable_plane(), and so disable_plane() can't rely on the crtc...
St?phane
>
> BR,
> -R
>
>>> plane->funcs->disable_plane(plane);
>>> plane->crtc = NULL;
>>> plane->fb = NULL;
>>> @@ -1958,16 +1969,6 @@ int drm_mode_setplane(struct drm_device *dev, void
>>> *data,
>>> goto out;
>>> }
>>>
>>> - obj = drm_mode_object_find(dev, plane_req->crtc_id,
>>> -DRM_MODE_OBJECT_CRTC);
>>> - if (!obj) {
>>> - DRM_DEBUG_KMS("Unknown crtc ID %d\n",
>>> - plane_req->crtc_id);
>>> - ret = -ENOENT;
>>> - goto out;
>>> - }
>>> - crtc = obj_to_crtc(obj);
>>> -
>>> fb = drm_framebuffer_lookup(dev, plane_req->fb_id);
>>> if (!fb) {
>>> DRM_DEBUG_KMS("Unknown framebuffer ID %d\n",
>>
>> I'm pretty sure this is ok since we don't have much userspace using
>> this that might fail to pass in a crtc when shutting down a plane...
>>
>> Reviewed-by: Jesse Barnes
>>
>> --
>> Jesse Barnes, Intel Open Source Technology Center
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
