[pull] radeon drm-next-3.14
On Fri, Jan 17, 2014 at 2:34 AM, Alex Deucher wrote: > Hi Dave, > > A few more changes for 3.14, mostly just bug fixes. Note that: > drm/radeon: add query to fetch the max engine clock. > will conflict with 3.13 final, but the fix is pretty obvious. No it isn't obvious at all! Since the info numbers are ABI we can't have an 0x19 in two places mean different things, so this pull is broken, please add the new info at 0x20 from the start, and the merge conflict fix is to add the 0x19 and 0x20 together, is the userspace side of these committed? Dave. > > The following changes since commit 53dac830537b51df555ba5e7ebb236705b7eaa7c: > > drm/mgag200: fix oops in cursor code. (2014-01-16 14:43:04 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~agd5f/linux drm-next-3.14 > > for you to fetch changes up to 4a8ee429cab2d62cf37f492db9861f918e79475b: > > drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table > (2014-01-16 11:04:07 -0500) > > > Alex Deucher (16): > Revert "drm/radeon: disable CIK CP semaphores for now" > drm/radeon: consolidate cp hdp flushing code for CIK > drm/radeon: consolidate sdma hdp flushing code for CIK > drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush > drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush > drm/radeon: disable dpm on BTC > drm/radeon/cik: use hw defaults for TC_CFG registers > drm/radeon: disable ss on DP for DCE3.x > drm/radeon/dp: bump i2c-over-aux retries to 7 > drm/radeon/dp: use usleep_range rather than udelay > drm/radeon/dp: sleep after powering up the display > drm/radeon: add query to fetch the max engine clock. > drm/radeon: handle ss percentage divider properly > drm/radeon: bail early from enable ss in certain cases > drm/radeon: write gfx pg bases even when gfx pg is disabled > drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table > > Christian K?nig (1): > drm/radeon: don't power gate paused UVD streams > > drivers/gpu/drm/radeon/atombios_crtc.c | 32 +++ > drivers/gpu/drm/radeon/atombios_dp.c | 18 +++--- > drivers/gpu/drm/radeon/cik.c | 95 > > drivers/gpu/drm/radeon/cik_sdma.c| 43 +++ > drivers/gpu/drm/radeon/radeon_atombios.c | 19 +-- > drivers/gpu/drm/radeon/radeon_kms.c | 7 +++ > drivers/gpu/drm/radeon/radeon_mode.h | 1 + > drivers/gpu/drm/radeon/radeon_pm.c | 10 +++- > drivers/gpu/drm/radeon/radeon_uvd.c | 2 + > drivers/gpu/drm/radeon/rv770_dpm.c | 14 ++--- > drivers/gpu/drm/radeon/si.c | 3 + > include/uapi/drm/radeon_drm.h| 3 +- > 12 files changed, 152 insertions(+), 95 deletions(-)
[PATCH] fs: export simple_dname for drm drivers.
David Herrmann's changes to use a pseudo filesystem for drm's shared inodes requires this be exported for drm to build as a module. I'd like to merge this via the drm tree, so please ack. Signed-off-by: Dave Airlie --- fs/dcache.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/dcache.c b/fs/dcache.c index 6055d61..27d66b8 100644 --- a/fs/dcache.c +++ b/fs/dcache.c @@ -3107,6 +3107,7 @@ char *simple_dname(struct dentry *dentry, char *buffer, int buflen) end = ERR_PTR(-ENAMETOOLONG); return end; } +EXPORT_SYMBOL(simple_dname); /* * Write full pathname from the root of the filesystem into the buffer. -- 1.8.4.2
[RFC v2 0/3] DRM Anonymous Inodes
>> Hi >> >> On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann >> wrote: >>> Hi >>> >>> With 3.13-rc1 the required VFS core changes for anonymous backing inodes in >>> DRM >>> got merged. This series reworks the previous patches (I think from early >>> August '13) and finally replaces the ugly drm_device->dev_mapping hack. >>> >>> The patches should be fairly obvious. As I currently only have nouveau >>> here, I'd >>> be happy to get some more testers with other drivers. >>> >>> Patch #1 adds an internal private mount point to DRM core. >>> Patch #2 replaces ->dev_mapping with a private anonymous inode for each >>> device. >>> Patch #3 removes the delayed dev_mapping initialization in TTM. >>> >>> The internal mnt-point is based on fs/aio.c and fs/anon_inode.c which do the >>> same. It's not clear to me why we cannot share the mnt-point between all >>> these, >>> but Al Viro made clear that he will reject any patches on anon_inode.c >>> which do >>> that. So lets follow his recommendation and use our own internal mnt-point. >> Also tested on i915 ivb now (before: nouveau+TTM). I think this is >> ready for 3.14 if nobody finds any issues. > I talked to Al, 7:13 < viro> umm... 17:14 < viro> you do realize that your module will be impossible to unload? 17:14 < viro> kern_mount will pin that fs down 17:14 < viro> bumping module refcount 17:15 < viro> so kern_unmount() in module_exit is not going to be called at all 17:15 -!- rafael__ [^rafael at aerd124.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 608 seconds] 17:16 < viro> what you want is some variation on simple_pin_fs() 17:17 < viro> done from drm_dev_alloc() 17:18 < viro> with simple_release_fs() from drm_dev_free(), right after iput() 17:20 < viro> the export itself is OK (albeit we might be better off exporting a variant of mount_pseudo() instead, so that aio and this sucker would both just call mount_dname_pseudo()) 17:21 < viro> the problem I see there is with kern_mount() use 17:47 -!- sameo [~samuel at 192.55.55.41] has quit [Remote host closed the connection] So maybe we should think about it a bit more :-) Dave.
[PATCH v2] backlight: turn backlight on/off when necessary
We don't have to turn backlight on/off everytime a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely being active to display something. This patch adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight should be turned on or off. To be more specific,
only one unblank operation on a certain blanked framebuffer
may increase the backlight device's use count by one, while
one blank operation on a certain unblanked framebuffer may
decrease the use count by one, because the userspace is
likely to unblank a unblanked framebuffer or blank a blanked
framebuffer.
Signed-off-by: Liu Ying
---
v1 can be found at https://lkml.org/lkml/2013/5/30/139
v1->v2:
* Make the commit message be more specific about the condition
in which backlight device use count can be increased/decreased.
* Correct the setting for bd->props.fb_blank.
drivers/video/backlight/backlight.c | 28 +---
include/linux/backlight.h |6 ++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 5d0..42044be 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
* framebuffer driver. We're looking if that important event is blanking,
- * and if it is, we're switching backlight power as well ...
+ * and if it is and necessary, we're switching backlight power as well ...
*/
static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
{
struct backlight_device *bd;
struct fb_event *evdata = data;
+ int node = evdata->info->node;
+ int fb_blank = 0;
/* If we aren't interested in this event, skip it immediately ... */
if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
@@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
if (bd->ops)
if (!bd->ops->check_fb ||
bd->ops->check_fb(bd, evdata->info)) {
- bd->props.fb_blank = *(int *)evdata->data;
- if (bd->props.fb_blank == FB_BLANK_UNBLANK)
- bd->props.state &= ~BL_CORE_FBBLANK;
- else
- bd->props.state |= BL_CORE_FBBLANK;
- backlight_update_status(bd);
+ fb_blank = *(int *)evdata->data;
+ if (fb_blank == FB_BLANK_UNBLANK &&
+ !bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = true;
+ if (!bd->use_count++) {
+ bd->props.state &= ~BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
+ }
+ } else if (fb_blank != FB_BLANK_UNBLANK &&
+ bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = false;
+ if (!(--bd->use_count)) {
+ bd->props.state |= BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_POWERDOWN;
+ backlight_update_status(bd);
+ }
+ }
}
mutex_unlock(&bd->ops_lock);
return 0;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f9cd96..7264742 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -9,6 +9,7 @@
#define _LINUX_BACKLIGHT_H
#include
+#include
#include
#include
@@ -104,6 +105,11 @@ struct backlight_device {
struct list_head entry;
struct device dev;
+
+ /* Multiple framebuffers may share one backlight device */
+ bool fb_bl_on[FB_MAX];
+
+ int use_count;
};
static inline void backlight_update_status(struct backlight_device *bd)
--
1.7.9.5
[Bug 72228] Painkiller: Hell and Damnation segfaults intermittently on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=72228 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Michel D?nzer --- Resolving per comment #8 (BTW, you can do this yourself :). -- 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/20140120/342f551e/attachment.html>
[PATCH] drm/gem: Always initialize the gem object in object_init
At least drm/i915 expects that the obj->dev pointer is set even in
failure paths. Specifically when the shmem initialization fails we
call i915_gem_object_free which needs to deref obj->base.dev to get at
the slab pointer in the device private structure. And the shmem
allocation can easily fail when userspace is hitting open file limits.
Doing the structure init even when the shmem file allocation fails
prevents this Oops.
Testcase: igt/gem_fd_exhaustion
Reported-and-Suggested-by: Linus Torvalds
Cc: Linus Torvalds
References:
http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 3ff39bb0402d..31c919903cd0 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -129,11 +129,12 @@ int drm_gem_object_init(struct drm_device *dev,
{
struct file *filp;
+ drm_gem_private_object_init(dev, obj, size);
+
filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
if (IS_ERR(filp))
return PTR_ERR(filp);
- drm_gem_private_object_init(dev, obj, size);
obj->filp = filp;
return 0;
--
1.8.1.4
[PATCH] drm/gem: Always initialize the gem object in object_init
Hi
On Mon, Jan 20, 2014 at 8:21 AM, Daniel Vetter
wrote:
> At least drm/i915 expects that the obj->dev pointer is set even in
> failure paths. Specifically when the shmem initialization fails we
> call i915_gem_object_free which needs to deref obj->base.dev to get at
> the slab pointer in the device private structure. And the shmem
> allocation can easily fail when userspace is hitting open file limits.
>
> Doing the structure init even when the shmem file allocation fails
> prevents this Oops.
Makes the error-paths simpler, and drm_gem_private_object_init()
doesn't allocate anything, so looks good:
Reviewed-by: David Herrmann
Thanks
David
> Testcase: igt/gem_fd_exhaustion
> Reported-and-Suggested-by: Linus Torvalds
> Cc: Linus Torvalds
> References:
> http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 3ff39bb0402d..31c919903cd0 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -129,11 +129,12 @@ int drm_gem_object_init(struct drm_device *dev,
> {
> struct file *filp;
>
> + drm_gem_private_object_init(dev, obj, size);
> +
> filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> if (IS_ERR(filp))
> return PTR_ERR(filp);
>
> - drm_gem_private_object_init(dev, obj, size);
> obj->filp = filp;
>
> return 0;
> --
> 1.8.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67631] Radeon UVD hang/crash
https://bugzilla.kernel.org/show_bug.cgi?id=67631 --- Comment #1 from Vitaliy Filippov --- The bug also reproduces on 3.13 from ubuntu-kernel PPA. Anyone?? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/gem: Always initialize the gem object in object_init
On Mon, Jan 20, 2014 at 08:21:54AM +0100, Daniel Vetter wrote: > At least drm/i915 expects that the obj->dev pointer is set even in > failure paths. Specifically when the shmem initialization fails we > call i915_gem_object_free which needs to deref obj->base.dev to get at > the slab pointer in the device private structure. And the shmem > allocation can easily fail when userspace is hitting open file limits. > > Doing the structure init even when the shmem file allocation fails > prevents this Oops. Regression from commit 89c8233f82d9c8af5b20e72e4a185a38a7d3c50b Author: David Herrmann Date: Thu Jul 11 11:56:32 2013 +0200 drm/gem: simplify object initialization > Testcase: igt/gem_fd_exhaustion > Reported-and-Suggested-by: Linus Torvalds > Cc: Linus Torvalds > References: > http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html > Cc: stable at vger.kernel.org > Signed-off-by: Daniel Vetter Cc: David Herrmann -- Chris Wilson, Intel Open Source Technology Centre
[patch] drm: use after free in drm_pci_exit()
We can't use "dev" after we freed it on the line before.
Fixes: b3f2333de8e8 ('drm: restrict the device list for shadow attached
drivers')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 5736aaa7e86c..f7af69bcf3f4 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -468,8 +468,8 @@ void drm_pci_exit(struct drm_driver *driver, struct
pci_driver *pdriver)
} else {
list_for_each_entry_safe(dev, tmp, &driver->legacy_dev_list,
legacy_dev_list) {
- drm_put_dev(dev);
list_del(&dev->legacy_dev_list);
+ drm_put_dev(dev);
}
}
DRM_INFO("Module unloaded\n");
[PATCH] drm/vmwgfx: Fix recently introduced sparse / smatch warnings and errors
Reported-by: Fengguang Wu
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |4 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 45 +--
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c |1 +
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |1 +
5 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 97aa551..82c41da 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -744,7 +744,7 @@ static void vmw_context_binding_transfer(struct
vmw_ctx_binding_state *cbs,
* Emits FIFO commands to scrub a binding represented by @cb.
* Then stops tracking the binding and re-initializes its storage.
*/
-void vmw_context_binding_kill(struct vmw_ctx_binding *cb)
+static void vmw_context_binding_kill(struct vmw_ctx_binding *cb)
{
(void) vmw_scrub_funcs[cb->bi.bt](&cb->bi);
vmw_context_binding_drop(cb);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 078b9b0..9893328 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -680,8 +680,10 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev_priv->prim_bb_mem = dev_priv->vram_size;
ret = vmw_dma_masks(dev_priv);
- if (unlikely(ret != 0))
+ if (unlikely(ret != 0)) {
+ mutex_unlock(&dev_priv->hw_mutex);
goto out_err0;
+ }
if (unlikely(dev_priv->prim_bb_mem < dev_priv->vram_size))
dev_priv->prim_bb_mem = dev_priv->vram_size;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
index ad29651..4910e7b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mob.c
@@ -35,19 +35,11 @@
#ifdef CONFIG_64BIT
#define VMW_PPN_SIZE 8
-#define vmw_cmd_set_otable_base SVGA3dCmdSetOTableBase64
-#define VMW_ID_SET_OTABLE_BASE SVGA_3D_CMD_SET_OTABLE_BASE64
-#define vmw_cmd_define_gb_mob SVGA3dCmdDefineGBMob64
-#define VMW_ID_DEFINE_GB_MOB SVGA_3D_CMD_DEFINE_GB_MOB64
#define VMW_MOBFMT_PTDEPTH_0 SVGA3D_MOBFMT_PTDEPTH64_0
#define VMW_MOBFMT_PTDEPTH_1 SVGA3D_MOBFMT_PTDEPTH64_1
#define VMW_MOBFMT_PTDEPTH_2 SVGA3D_MOBFMT_PTDEPTH64_2
#else
#define VMW_PPN_SIZE 4
-#define vmw_cmd_set_otable_base SVGA3dCmdSetOTableBase
-#define VMW_ID_SET_OTABLE_BASE SVGA_3D_CMD_SET_OTABLE_BASE
-#define vmw_cmd_define_gb_mob SVGA3dCmdDefineGBMob
-#define VMW_ID_DEFINE_GB_MOB SVGA_3D_CMD_DEFINE_GB_MOB
#define VMW_MOBFMT_PTDEPTH_0 SVGA3D_MOBFMT_PTDEPTH_0
#define VMW_MOBFMT_PTDEPTH_1 SVGA3D_MOBFMT_PTDEPTH_1
#define VMW_MOBFMT_PTDEPTH_2 SVGA3D_MOBFMT_PTDEPTH_2
@@ -105,7 +97,7 @@ static int vmw_setup_otable_base(struct vmw_private
*dev_priv,
{
struct {
SVGA3dCmdHeader header;
- vmw_cmd_set_otable_base body;
+ SVGA3dCmdSetOTableBase64 body;
} *cmd;
struct vmw_mob *mob;
const struct vmw_sg_table *vsgt;
@@ -146,10 +138,10 @@ static int vmw_setup_otable_base(struct vmw_private
*dev_priv,
}
memset(cmd, 0, sizeof(*cmd));
- cmd->header.id = VMW_ID_SET_OTABLE_BASE;
+ cmd->header.id = SVGA_3D_CMD_SET_OTABLE_BASE64;
cmd->header.size = sizeof(cmd->body);
cmd->body.type = type;
- cmd->body.baseAddress = mob->pt_root_page >> PAGE_SHIFT;
+ cmd->body.baseAddress = cpu_to_le64(mob->pt_root_page >> PAGE_SHIFT);
cmd->body.sizeInBytes = otable->size;
cmd->body.validSizeInBytes = 0;
cmd->body.ptDepth = mob->pt_level;
@@ -188,11 +180,12 @@ static void vmw_takedown_otable_base(struct vmw_private
*dev_priv,
SVGA3dCmdHeader header;
SVGA3dCmdSetOTableBase body;
} *cmd;
- struct ttm_buffer_object *bo = otable->page_table->pt_bo;
+ struct ttm_buffer_object *bo;
if (otable->page_table == NULL)
return;
+ bo = otable->page_table->pt_bo;
cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd));
if (unlikely(cmd == NULL))
DRM_ERROR("Failed reserving FIFO space for OTable setup.\n");
@@ -210,7 +203,7 @@ static void vmw_takedown_otable_base(struct vmw_private
*dev_priv,
if (bo) {
int ret;
- ret = ttm_bo_reserve(bo, false, true, false, false);
+ ret = ttm_bo_reserve(bo, false, true, false, NULL);
BUG_ON(ret != 0);
vmw_fence_single_bo(bo, NULL);
@@ -276,7 +269,7 @@ int vmw_otables_setup(struct vmw_private *dev_priv)
if (unlikely(ret != 0))
goto out_no_bo;
- ret = ttm_bo_reserve(dev_priv->otable_bo, false, true, false, false);
+ ret = ttm_bo_reserve(dev_priv->otable_bo, false, true, false, NULL);
BUG_ON(ret != 0);
r
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #188 from Sergey --- (In reply to comment #183) > You might also try my 3.14 branch: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14 Not sure if there are any important changes in this branch, but so far it looks more stable for me. I haven't seen hangs while video was played, though the week before i got them almost daily. And have seen hand during start up only once for last week. I might be just very lucky this week. -- 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/20140120/f79bee29/attachment.html>
[Bug 73619] XServer frequently freezes for a few seconds
https://bugs.freedesktop.org/show_bug.cgi?id=73619 --- Comment #3 from Alexander Richardson --- I have now upgraded to Mesa 10.0.2 and it is MUCH better. Freeze only happens very rarely now. Maybe some unrelated change made a race condition that causes this very unlikely. Sadly still don't have the time to bisect the kernel. -- 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/20140120/5bbf5bab/attachment.html>
Sharing Framebuffers between Client / Server
On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn wrote: > I am working on a client/server program, where the server creates (and has > access to a framebuffer), and then needs to share this framebuffer with a > client program so that this client program can draw into the framebuffer > directly (i.e. no memcpy). > > I am trying to figureout what the ?cleanest? way to do this is, such that I > can support Intel?s proprietary driver, the open source AMD and NVidia > drivers, and the VMWare driver (I have no need for the proprietary > ADM/NVidia drivers right now). From what I can tell, GEM is one way to do > this. The problem is VMWare doesn?t support GEM. > > I tried (knowing it would not work), using KMS to create the framebuffer, > and then sending the information needed to mmap to the client. This of > course failed because the framebuffer is marked non-sharable in the kernel. Dmabuf (or just plain old egl/glx which uses dri2 under the hood) would probably be what I suggest *except* you mention mmap. If you are doing software rendering, I guess you probably just want to suck it up and do XShmPutImage. >From what I understand, any sort of mmap access to vmwgfx buffers is tricky, because they end up being backed by normal GL textures on the host OS side (IIUC). So the single copy upload path in XShmPutImage might be close to the ideal path for sw rendered content. > To be clear, I am fine having to manually write ioctls for each driver, if > thats what it takes. But at this point, I am at a loss on the best method to > share scannot buffers (or at least in a way that doesn?t make someone cringe > when they see my code). Some sort of prepare/finish access ioctls for dmabuf to bracket mmap access are, I think, what vmwgfx is missing in order to implement dmabuf mmap. But no one so far has needed them badly enough to come up with something and send patches. IIUC, for vmwgfx there would still be a copy back to original texture on the host on finish-access, so it might not amount to anything much different from XShmPutImage. Probably better to ask some vmwgfx folks to clarify, since the virtual driver has some unique constraints which I may not be adequately representing. BR, -R > Thanks, > - Rian > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[RFC v2 0/3] DRM Anonymous Inodes
Hi On Mon, Jan 20, 2014 at 3:00 AM, Dave Airlie wrote: >>> Hi >>> >>> On Fri, Jan 3, 2014 at 3:41 PM, David Herrmann >>> wrote: Hi With 3.13-rc1 the required VFS core changes for anonymous backing inodes in DRM got merged. This series reworks the previous patches (I think from early August '13) and finally replaces the ugly drm_device->dev_mapping hack. The patches should be fairly obvious. As I currently only have nouveau here, I'd be happy to get some more testers with other drivers. Patch #1 adds an internal private mount point to DRM core. Patch #2 replaces ->dev_mapping with a private anonymous inode for each device. Patch #3 removes the delayed dev_mapping initialization in TTM. The internal mnt-point is based on fs/aio.c and fs/anon_inode.c which do the same. It's not clear to me why we cannot share the mnt-point between all these, but Al Viro made clear that he will reject any patches on anon_inode.c which do that. So lets follow his recommendation and use our own internal mnt-point. >>> Also tested on i915 ivb now (before: nouveau+TTM). I think this is >>> ready for 3.14 if nobody finds any issues. >> > > I talked to Al, > > 7:13 < viro> umm... > 17:14 < viro> you do realize that your module will be impossible to unload? > 17:14 < viro> kern_mount will pin that fs down > 17:14 < viro> bumping module refcount > 17:15 < viro> so kern_unmount() in module_exit is not going to be called at > all > 17:15 -!- rafael__ [^rafael at aerd124.neoplus.adsl.tpnet.pl] has quit > [Ping timeout: 608 seconds] > 17:16 < viro> what you want is some variation on simple_pin_fs() > 17:17 < viro> done from drm_dev_alloc() > 17:18 < viro> with simple_release_fs() from drm_dev_free(), right after iput() > 17:20 < viro> the export itself is OK (albeit we might be better off > exporting a variant of mount_pseudo() instead, so that aio and > this sucker would both just call mount_dname_pseudo()) > 17:21 < viro> the problem I see there is with kern_mount() use > 17:47 -!- sameo [~samuel at 192.55.55.41] has quit [Remote host closed > the connection] > > So maybe we should think about it a bit more :-) So we call simple_pin_fs() in drm_alloc_inode() and add a drm_free_inode() which calls iput() followed by simple_release_fs()? I will write up v3 and test with module re-loading this time. Thanks David
[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #101 from Marc --- It does greatly help for me as well as it lasted 5h. But setting the option to glamor isn't so good for me because there were display artifacts in some cases. For example I would open vinagre and the header bar (where there is Remote / View / ... menus and the Connect / Disconnect / ... buttons) wouldn't be drawn, I would see the content of what was there on the screen before I open that window instead. Same with gnome-control-center. I just noticed a package update in my distrib today: glamor-egl-0.5.1.r258-1-x86_64 I might give it another shot. I'll also update my kernel to 3.13 as I am on 3.12.7 at the moment. -- 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/20140120/6f845a39/attachment.html>
Sharing Framebuffers between Client / Server
On 01/20/2014 02:10 PM, Rob Clark wrote: > On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn wrote: >> I am working on a client/server program, where the server creates (and has >> access to a framebuffer), and then needs to share this framebuffer with a >> client program so that this client program can draw into the framebuffer >> directly (i.e. no memcpy). >> >> I am trying to figureout what the ?cleanest? way to do this is, such that I >> can support Intel?s proprietary driver, the open source AMD and NVidia >> drivers, and the VMWare driver (I have no need for the proprietary >> ADM/NVidia drivers right now). From what I can tell, GEM is one way to do >> this. The problem is VMWare doesn?t support GEM. >> >> I tried (knowing it would not work), using KMS to create the framebuffer, >> and then sending the information needed to mmap to the client. This of >> course failed because the framebuffer is marked non-sharable in the kernel. > Dmabuf (or just plain old egl/glx which uses dri2 under the hood) > would probably be what I suggest *except* you mention mmap. If you > are doing software rendering, I guess you probably just want to suck > it up and do XShmPutImage. > > >From what I understand, any sort of mmap access to vmwgfx buffers is > tricky, because they end up being backed by normal GL textures on the > host OS side (IIUC). So the single copy upload path in XShmPutImage > might be close to the ideal path for sw rendered content. > >> To be clear, I am fine having to manually write ioctls for each driver, if >> thats what it takes. But at this point, I am at a loss on the best method to >> share scannot buffers (or at least in a way that doesn?t make someone cringe >> when they see my code). > Some sort of prepare/finish access ioctls for dmabuf to bracket mmap > access are, I think, what vmwgfx is missing in order to implement > dmabuf mmap. But no one so far has needed them badly enough to come > up with something and send patches. > > IIUC, for vmwgfx there would still be a copy back to original texture > on the host on finish-access, so it might not amount to anything much > different from XShmPutImage. Probably better to ask some vmwgfx folks > to clarify, since the virtual driver has some unique constraints which > I may not be adequately representing. > > BR, > -R Rian, for sharing accelerated buffers, They'd best be created with Mesa's GBM, and shared using DRM prime. Those interfaces are generic and AFAICT, Ubuntu's Mir works exactly this way. The problem is that the client would need to link to mesa, and could use GL / GLES to transfer software contents to the buffer. For pure software contents, the server would share a generic shared memory buffer, together with a damage protocol, and composite / copy onto the framebuffer in the server. In principle, as Rob says, the dma-buf shared using DRM prime has an mmap() method, but none of the "big" drivers Intel, Nouveau and Radeon implements it, and for vmwgfx an implementation would be extremely inefficient. Also other drivers may have issues with write-combining and tiling of the mmap'ed framebuffer. If both the server and client would be 100% software one could create and share "dumb" kms buffers using DRM prime. If there's something in the vmwgfx driver that blocks sharing in this way, we could ease that restriction. But these buffers could not be rendered into. GEM is, BTW, purely driver-private. As you might see, the big restriction here is that there is no simple generic way to mmap() accelerated shared buffers from a lean client. This is intentional. For vmwgfx it's because of coherency issues that would make such an implementation inefficient. For other drivers I can imagine there are tiling- and caching issues. /Thomas > >> Thanks, >> - Rian >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm vblank timestamping changes
Hi Dave,
Here's the vblank timestamp pull request you wanted.
I addressed the few bugs that Mario pointed out and added
the r-bs.
As it has been a while since I made the changes, I gave it a
quick spin on a few different i915 machines. Fortunately
everything still seems to be fine.
The following changes since commit cfd72a4c2089aa3938f37281a34d6eb3306d5fd8:
Merge branch 'drm-intel-next' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2014-01-20
10:21:54 +1000)
are available in the git repository at:
git://gitorious.org/vsyrjala/linux.git drm-vbl-timestamp
for you to fetch changes up to 095163bad59bfeed294a81e0d873fa8943e4fa01:
drm/i915: Add a kludge for DSL incrementing too late and ISR not working
(2014-01-20 12:21:36 +0200)
Ville Syrj?l? (14):
drm: Pass the display mode to drm_calc_timestamping_constants()
drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()
drm/i915: Kill hwmode save/restore
drm/i915: Call drm_calc_timestamping_constants() earlier
drm: Improve drm_calc_timestamping_constants() documentation
drm: Simplify the math in drm_calc_timestamping_constants()
drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()
drm: Use crtc_clock in drm_calc_timestamping_constants()
drm: Change {pixel,line,frame}dur_ns from s64 to int
drm/i915: Fix scanoutpos calculations for interlaced modes
drm: Fix vblank timestamping constants for interlaced modes
drm: Pass 'flags' from the caller to .get_scanout_position()
drm/radeon: Move the early vblank IRQ fixup to
radeon_get_crtc_scanoutpos()
drm/i915: Add a kludge for DSL incrementing too late and ISR not working
drivers/gpu/drm/drm_crtc_helper.c| 2 +-
drivers/gpu/drm/drm_irq.c| 109 ---
drivers/gpu/drm/i915/i915_irq.c | 91 ++
drivers/gpu/drm/i915/intel_display.c | 29
drivers/gpu/drm/radeon/radeon_atombios.c | 6 +-
drivers/gpu/drm/radeon/radeon_display.c | 29 +++-
drivers/gpu/drm/radeon/radeon_drv.c | 1 +
drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
drivers/gpu/drm/radeon/radeon_mode.h | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
include/drm/drmP.h | 8 ++-
include/drm/drm_crtc.h | 2 +-
12 files changed, 144 insertions(+), 138 deletions(-)
--
Ville Syrj?l?
Intel OTC
[Bug 73619] XServer frequently freezes for a few seconds
https://bugs.freedesktop.org/show_bug.cgi?id=73619 Alex Deucher changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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/20140120/bc7d62fe/attachment.html>
[Bug 68701] On boot, console freeze after "conflicting fb hw usage nouveau fb vs..." with 3.13-rc8
https://bugzilla.kernel.org/show_bug.cgi?id=68701 --- Comment #2 from William --- Created attachment 122741 --> https://bugzilla.kernel.org/attachment.cgi?id=122741&action=edit successful dmesg for 3.13.0 Retested with 3.13.0 release, and the same kernel config as I used with 3.13-rc8, and the console is now OK, thanks. Will attach the dmesg from a 3.13.0 boot for reference. -- You are receiving this mail because: You are watching the assignee of the bug.
[pull] radeon drm-next-3.14
On Sun, Jan 19, 2014 at 7:02 PM, Dave Airlie wrote: > On Fri, Jan 17, 2014 at 2:34 AM, Alex Deucher > wrote: >> Hi Dave, >> >> A few more changes for 3.14, mostly just bug fixes. Note that: >> drm/radeon: add query to fetch the max engine clock. >> will conflict with 3.13 final, but the fix is pretty obvious. > > No it isn't obvious at all! > > Since the info numbers are ABI we can't have an 0x19 in two places > mean different things, > > so this pull is broken, please add the new info at 0x20 from the > start, and the merge conflict > fix is to add the 0x19 and 0x20 together, is the userspace side of > these committed? I should have said, when merged the number for engine clock query needs to be changed to 0x1a rather than 0x19. The userspace side for the engine clock query is not committed yet. I'll send an updated pull request. Alex > > Dave. > >> >> The following changes since commit 53dac830537b51df555ba5e7ebb236705b7eaa7c: >> >> drm/mgag200: fix oops in cursor code. (2014-01-16 14:43:04 +1000) >> >> are available in the git repository at: >> >> git://people.freedesktop.org/~agd5f/linux drm-next-3.14 >> >> for you to fetch changes up to 4a8ee429cab2d62cf37f492db9861f918e79475b: >> >> drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table >> (2014-01-16 11:04:07 -0500) >> >> >> Alex Deucher (16): >> Revert "drm/radeon: disable CIK CP semaphores for now" >> drm/radeon: consolidate cp hdp flushing code for CIK >> drm/radeon: consolidate sdma hdp flushing code for CIK >> drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush >> drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush >> drm/radeon: disable dpm on BTC >> drm/radeon/cik: use hw defaults for TC_CFG registers >> drm/radeon: disable ss on DP for DCE3.x >> drm/radeon/dp: bump i2c-over-aux retries to 7 >> drm/radeon/dp: use usleep_range rather than udelay >> drm/radeon/dp: sleep after powering up the display >> drm/radeon: add query to fetch the max engine clock. >> drm/radeon: handle ss percentage divider properly >> drm/radeon: bail early from enable ss in certain cases >> drm/radeon: write gfx pg bases even when gfx pg is disabled >> drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table >> >> Christian K?nig (1): >> drm/radeon: don't power gate paused UVD streams >> >> drivers/gpu/drm/radeon/atombios_crtc.c | 32 +++ >> drivers/gpu/drm/radeon/atombios_dp.c | 18 +++--- >> drivers/gpu/drm/radeon/cik.c | 95 >> >> drivers/gpu/drm/radeon/cik_sdma.c| 43 +++ >> drivers/gpu/drm/radeon/radeon_atombios.c | 19 +-- >> drivers/gpu/drm/radeon/radeon_kms.c | 7 +++ >> drivers/gpu/drm/radeon/radeon_mode.h | 1 + >> drivers/gpu/drm/radeon/radeon_pm.c | 10 +++- >> drivers/gpu/drm/radeon/radeon_uvd.c | 2 + >> drivers/gpu/drm/radeon/rv770_dpm.c | 14 ++--- >> drivers/gpu/drm/radeon/si.c | 3 + >> include/uapi/drm/radeon_drm.h| 3 +- >> 12 files changed, 152 insertions(+), 95 deletions(-)
[PATCH] drm/radeon: add UVD support for OLAND
It seems this got dropped when we merged UVD support last year. Add this back now. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_uvd.c | 1 + drivers/gpu/drm/radeon/uvd_v2_2.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c index 8158c2b..1fe802f6 100644 --- a/drivers/gpu/drm/radeon/radeon_uvd.c +++ b/drivers/gpu/drm/radeon/radeon_uvd.c @@ -91,6 +91,7 @@ int radeon_uvd_init(struct radeon_device *rdev) case CHIP_VERDE: case CHIP_PITCAIRN: case CHIP_ARUBA: + case CHIP_OLAND: fw_name = FIRMWARE_TAHITI; break; diff --git a/drivers/gpu/drm/radeon/uvd_v2_2.c b/drivers/gpu/drm/radeon/uvd_v2_2.c index b19ef49..824550d 100644 --- a/drivers/gpu/drm/radeon/uvd_v2_2.c +++ b/drivers/gpu/drm/radeon/uvd_v2_2.c @@ -153,6 +153,7 @@ int uvd_v2_2_resume(struct radeon_device *rdev) chip_id = 0x0115; break; case CHIP_PITCAIRN: + case CHIP_OLAND: chip_id = 0x0116; break; case CHIP_ARUBA: -- 1.8.3.1
[Bug 73789] [Radeon HD 7770 GHz Edition] Cape Verde XT: glxinfo report 3.0, but support for 3.1 annonced
https://bugs.freedesktop.org/show_bug.cgi?id=73789 --- Comment #4 from Stepan Bakshaev --- (In reply to comment #2) > For OpenGL versions higher than 3.0 the devs are only supporting core > profile. So this is not a bug. What does it mean "the devs"? -- 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/20140120/97fae92f/attachment.html>
[Bug 73789] [Radeon HD 7770 GHz Edition] Cape Verde XT: glxinfo report 3.0, but support for 3.1 annonced
https://bugs.freedesktop.org/show_bug.cgi?id=73789 --- Comment #5 from Marek Ol??k --- (In reply to comment #4) > (In reply to comment #2) > > For OpenGL versions higher than 3.0 the devs are only supporting core > > profile. So this is not a bug. > > What does it mean "the devs"? The developers. -- 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/20140120/a7b647a5/attachment.html>
[PATCH] drm/edid: Populate picture aspect ratio for CEA modes
On Mon, Dec 23, 2013 at 11:27:40AM +0530, Vandana Kannan wrote:
> Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
> CEA-861E Table 4. This is useful for filling up the detail in AVI
> infoframe.
>
> v2: Ville's inputs incorporated. Added picture aspect ratio as part of
> edid_cea_modes instead of DRM_MODE
>
> Signed-off-by: Vandana Kannan
> Reviewed-by: Alex Deucher
Reviewed-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_edid.c | 128
> ++--
> include/drm/drm_crtc.h |2 +
> 2 files changed, 66 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fb7cf0e..20e3784 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -600,347 +600,347 @@ static const struct drm_display_mode edid_cea_modes[]
> = {
> { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
> 752, 800, 0, 480, 490, 492, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> /* 2 - 720x480 at 60Hz */
> { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
> 798, 858, 0, 480, 489, 495, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> /* 3 - 720x480 at 60Hz */
> { DRM_MODE("720x480", DRM_MODE_TYPE_DRIVER, 27000, 720, 736,
> 798, 858, 0, 480, 489, 495, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 4 - 1280x720 at 60Hz */
> { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> 1430, 1650, 0, 720, 725, 730, 750, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 5 - 1920x1080i at 60Hz */
> { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> 2052, 2200, 0, 1080, 1084, 1094, 1125, 0,
> DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
> DRM_MODE_FLAG_INTERLACE),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 6 - 1440x480i at 60Hz */
> { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> 1602, 1716, 0, 480, 488, 494, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> /* 7 - 1440x480i at 60Hz */
> { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> 1602, 1716, 0, 480, 488, 494, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 8 - 1440x240 at 60Hz */
> { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> 1602, 1716, 0, 240, 244, 247, 262, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_DBLCLK),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> /* 9 - 1440x240 at 60Hz */
> { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
> 1602, 1716, 0, 240, 244, 247, 262, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_DBLCLK),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 10 - 2880x480i at 60Hz */
> { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
> 3204, 3432, 0, 480, 488, 494, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
> /* 11 - 2880x480i at 60Hz */
> { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956,
> 3204, 3432, 0, 480, 488, 494, 525, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
> DRM_MODE_FLAG_INTERLACE),
> - .vrefresh = 60, },
> + .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> /* 12 - 2880x240 at 60Hz */
> { DRM_MODE("2880x240", D
[Bug 73625] rv730 agp unstable while uvd video playback
https://bugs.freedesktop.org/show_bug.cgi?id=73625 --- Comment #17 from Roman Elshin --- It seems to me that uvd is stable with R600_DEBUG=nosb and current mesa (it is only necessary workaround). I mean stable behaviour - if it able to play some movie it always play it, or if it hang gpu on other it always hang it 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/20140120/89f6df57/attachment.html>
[Bug 73789] [Radeon HD 7770 GHz Edition] Cape Verde XT: glxinfo report 3.0, but support for 3.1 annonced
https://bugs.freedesktop.org/show_bug.cgi?id=73789 --- Comment #6 from Stepan Bakshaev --- Sorry for my buzz. I want to play Natural Selection 2 and don't want to think. You wrote about it already http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt?h=10.0&id=12484d2582a478b3ef126efe12f24c8e4a4d4db7#n10 OpenGL 3.1 and later versions are only supported with the Core profile. There are no plans to support GL_ARB_compatibility. Developers want to earn money from unknownworlds and don't want to code. Community of ns2 discusses mesa and waits for nothing http://forums.unknownworlds.com/discussion/132731/linux-intel-hd-4000-opengl-3-1-core-profile -- 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/20140120/b9a95590/attachment.html>
[Bug 73788] [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed
https://bugs.freedesktop.org/show_bug.cgi?id=73788 --- Comment #3 from Stepan Bakshaev --- Unigine Sanctuary on Cape Verde XT: At present: 30 fps Unigine Sanctuary demo benchmark edition v2.3 FPS: 29.9 Scores: 1267 Min FPS: 26.9 Max FPS: 31.8 Hardware Binary:Linux 32bit GCC 4.3.2 Release May 20 2010 Operating system: Linux 3.13.0-4-generic x86_64 CPU model: Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz CPU flags: 3392MHz MMX SSE SSE2 SSE3 SSSE3 SSE41 SSE42 HTT GPU model: Gallium 0.4 on AMD CAPE VERDE 3.0 Mesa 10.0.1 256Mb Settings Render: opengl Mode: 1920x1080 fullscreen Shaders: high Textures: high Filter: trilinear Anisotropy: 4x Translucence: enabled Parallax: enabled Reflection: enabled DOF:disabled HDR:disabled Vsync is disabled. Temp grows from 37 to 59. -- 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/20140120/08fe8044/attachment.html>
[Bug 71212] [RadeonSI]: Unigine Heaven fails to launch with X error
https://bugs.freedesktop.org/show_bug.cgi?id=71212 --- Comment #6 from Stepan Bakshaev --- (In reply to comment #5) > Running heaven with MESA_GL_VERSION_OVERRIDE=3.2 > MESA_GLSL_VERSION_OVERRIDE=150 hard hangs the system > after few minutes of launch OS: Ubuntu 14.04 (dev, updated to present state) Device:Cape Verde XT [Radeon HD 7770 GHz Edition] [683d] Bench finished success with results: Time:188.999 Frames:2666 FPS:14.1059 Min FPS:8.78678 Max FPS:26.3573 Score:590.19 -- 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/20140120/dcbbc102/attachment.html>
[Bug 71212] [RadeonSI]: Unigine Heaven fails to launch with X error
https://bugs.freedesktop.org/show_bug.cgi?id=71212 --- Comment #7 from Stepan Bakshaev --- (In reply to comment #6) > OS: Ubuntu 14.04 (dev, updated to present state) > Device: Cape Verde XT [Radeon HD 7770 GHz Edition] [683d] > > Bench finished success with results: > > Time: 188.999 > Frames: 2666 > FPS: 14.1059 > Min FPS: 8.78678 > Max FPS: 26.3573 > Score:590.19 It was about valley. -- 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/20140120/9a42fdc0/attachment.html>
[Bug 71212] [RadeonSI]: Unigine Heaven fails to launch with X error
https://bugs.freedesktop.org/show_bug.cgi?id=71212 --- Comment #8 from Stepan Bakshaev --- Heaven's 4.0 results: Time:260.509 Frames:3949 FPS:15.1588 Min FPS:5.87158 Max FPS:27.4029 Score:381.85 OS: Ubuntu 14.04 (dev, updated to present state) Device:Cape Verde XT [Radeon HD 7770 GHz Edition] [683d] -- 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/20140120/b07acc67/attachment.html>
[PATCH] drm: Initialize or valgrind-clear modesetting ioctl arguments.
On 12/28/2013 10:06 PM, Eric Anholt wrote: > Fixes valgrind complaints in the modesetting driver. I tried to > follow each ioctl's pattern for whether it was initializing just the > in values, or both in and out values. > --- > Makefile.am | 2 ++ > xf86drmMode.c | 19 +++ > 2 files changed, 21 insertions(+) Reviewed-by: Kenneth Graunke
[PATCH] intel: Track whether a buffer is idle to avoid trips to the kernel.
On 01/15/2014 12:38 AM, Eric Anholt wrote: > I've seen a number of apps spending unreasonable amounts of time in > drm_intel_bo_busy during the buffer mapping process. > > We can't track idleness in general, in the case of buffers shared > across processes. But this should significantly reduce our overhead > for checking for busy on things like VBOs. > > Improves (unoptimized) glamor x11perf -f8text by 0.243334% +/- > 0.161498% (n=1549), which has formerly been spending about .5% of its > time hitting the kernel for drm_intel_gem_bo_busy(). > --- > > I've still got a patch outstanding on the list for valgrind-cleaning > the modesetting paths. Since we're probably rolling a release soon, > that might be nice to get in. > > intel/intel_bufmgr_gem.c | 23 ++- > 1 file changed, 22 insertions(+), 1 deletion(-) Nice, makes sense...if they submit a batch referencing the buffer, it might be busy, so we need to check...if not, and it isn't shared, it's definitely idle, so skip the check. I like it. Reviewed-by: Kenneth Graunke
[PATCH 2/7] drm/udl: fix Bpp calculation in dumb_create()
Probably a typo.. we obviously need "(bpp + 7) / 8" instead of
"(bpp + 1) / 8". Unlikely to be hit in any sane code, but lets be safe.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 8d67b94..df963a1 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -60,7 +60,7 @@ int udl_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- args->pitch = args->width * ((args->bpp + 1) / 8);
+ args->pitch = args->width * ((args->bpp + 7) / 8);
args->size = args->pitch * args->height;
return udl_gem_create(file, dev,
args->size, &args->handle);
--
1.8.5.3
[PATCH 1/7] drm/udl: fix error-path when damage-req fails
We need to call dma_buf_end_cpu_access() in case a damage-request.
Unlikely, but might happen during device unplug.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/udl/udl_fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index dbadd49..50f564d 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -421,9 +421,10 @@ static int udl_user_framebuffer_dirty(struct
drm_framebuffer *fb,
clips[i].x2 - clips[i].x1,
clips[i].y2 - clips[i].y1);
if (ret)
- goto unlock;
+ goto end_access;
}
+end_access:
if (ufb->obj->base.import_attach) {
dma_buf_end_cpu_access(ufb->obj->base.import_attach->dmabuf,
0, ufb->obj->base.size,
--
1.8.5.3
[PATCH 3/7] drm/udl: import prime-fds with proper page-alignment
Instead of rounding down to the next lower page-boundary, round up. dma-buf guarantees that we can map buffers in multiples of a page, so if an exporter does not page-align, do it ourselves. This avoids issues if the exported buffer contains an unaligned size and we crop it. In this case, the buffer is too small for the UDL CRTC. So we round up to page-size now and avoid black borders. Worst case is we end up reading out some random kernel memory, but we can never fault as the whole page has the same access-rights. And in this case it's an issue of the buggy exporting driver, not the importing one. Signed-off-by: David Herrmann --- drivers/gpu/drm/udl/udl_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c index df963a1..1069e57 100644 --- a/drivers/gpu/drm/udl/udl_gem.c +++ b/drivers/gpu/drm/udl/udl_gem.c @@ -227,7 +227,7 @@ static int udl_prime_create(struct drm_device *dev, struct udl_gem_object *obj; int npages; - npages = size / PAGE_SIZE; + npages = PAGE_ALIGN(size) >> PAGE_SHIFT; *obj_p = NULL; obj = udl_gem_alloc_object(dev, npages * PAGE_SIZE); -- 1.8.5.3
[PATCH 4/7] drm/gem: fix indentation
Remove double-whitespace and wrong indentation. Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index bed5c3b..c1eaf35 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -691,7 +691,7 @@ drm_gem_object_release(struct drm_gem_object *obj) WARN_ON(obj->dma_buf); if (obj->filp) - fput(obj->filp); + fput(obj->filp); } EXPORT_SYMBOL(drm_gem_object_release); @@ -781,7 +781,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_ops = dev->driver->gem_vm_ops; vma->vm_private_data = obj; - vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); + vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); /* Take a ref for this mapping of the object, so that the fault * handler can dereference the mmap offset's pointer to the object. -- 1.8.5.3
[PATCH 5/7] drm/gem: free vma-node during object-cleanup
All drivers currently need to clean up the vma-node manually. There is no fancy logic involved so lets just clean it up unconditionally. The vma-manager correctly catches multiple calls so we are fine. Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index c1eaf35..7bf374e 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -692,6 +692,8 @@ drm_gem_object_release(struct drm_gem_object *obj) if (obj->filp) fput(obj->filp); + + drm_gem_free_mmap_offset(obj); } EXPORT_SYMBOL(drm_gem_object_release); -- 1.8.5.3
[PATCH 6/7] drm/crtc: add sanity checks to create_dumb()
Lets make sure some basic expressions are always true:
bpp != NULL
width != NULL
height != NULL
stride = bpp * width < 2^32
size = stride * height < 2^32
PAGE_ALIGN(size) < 2^32
At least the udl driver doesn't check for multiplication-overflows, so
lets just make sure it will never happen. These checks allow drivers to do
any 32bit math without having to test for mult-overflows themselves.
The two divisions might hurt performance a bit, but dumb_create() is only
used for scanout-buffers, so that should be fine. We could use 64bit math
to avoid the divisions, but that may be slow on 32bit machines.. Or maybe
there should just be a "safe_mult32()" helper, which currently doesn't
exist (I think?).
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_crtc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 266a01d..ff647fa 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3738,9 +3738,24 @@ int drm_mode_create_dumb_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
struct drm_mode_create_dumb *args = data;
+ u32 Bpp, stride, size;
if (!dev->driver->dumb_create)
return -ENOSYS;
+ if (!args->width || !args->height || !args->bpp)
+ return -EINVAL;
+
+ /* overflow checks for 32bit size calculations */
+ Bpp = (args->bpp + 7) / 8;
+ if (Bpp > 0xU / args->width)
+ return -EINVAL;
+ stride = Bpp * args->width;
+ if (args->height > 0xU / stride)
+ return -EINVAL;
+ size = args->height * stride;
+ if (PAGE_ALIGN(size) < size)
+ return -EINVAL;
+
return dev->driver->dumb_create(file_priv, dev, args);
}
--
1.8.5.3
[PATCH 7/7] drm/gem: dont init "ret" in drm_gem_mmap()
There is no need to initialize this variable, so drop it. Otherwise, the compiler won't warn if we use it unintialized. Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 7bf374e..700e8df 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -819,7 +819,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct *vma) struct drm_device *dev = priv->minor->dev; struct drm_gem_object *obj; struct drm_vma_offset_node *node; - int ret = 0; + int ret; if (drm_device_is_unplugged(dev)) return -ENODEV; -- 1.8.5.3
[Bug 73848] New: [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 Priority: medium Bug ID: 73848 Assignee: dri-devel at lists.freedesktop.org Summary: [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: marti at juffo.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI With ASUS Radeon R9 270, just after I boot up and GDM is supposed to start, my screen goes blank and some GPU faults are reported in dmesg. Upgrading to kernel 3.13 solves this issue. One time the graphics also recovered with 3.12.8 after coming back from suspend, but I have not been able to reproduce that. Using up-to-date Arch Linux testing with: xorg-server 1.15.0 mesa 10.0.2 libdrm 2.4.51 xf86-video-ati 7.2.0 kernel versions tested: 3.12.8, 3.12.1, 3.11.5, 3.10.10 The following errors are reported in dmesg (full log attached): radeon :01:00.0: GPU fault detected: 147 0x005e7001 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x091C0002 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1E070001 VM fault (0x01, vmid 15) at page 152829954, read from CP (112) radeon :01:00.0: GPU fault detected: 147 0x02de8801 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x VM fault (0x00, vmid 0) at page 0, read from unknown (0) radeon :01:00.0: GPU fault detected: 147 0x02de8801 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x VM fault (0x00, vmid 0) at page 0, read from unknown (0) radeon :01:00.0: GPU fault detected: 147 0x04df8402 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00080826 radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1F084002 VM fault (0x02, vmid 15) at page 526374, write from TC (132) -- 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/20140120/349bc139/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #1 from Marti Raudsepp --- Created attachment 92487 --> https://bugs.freedesktop.org/attachment.cgi?id=92487&action=edit dmesg.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/20140120/75d39f0d/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #2 from Marti Raudsepp --- Created attachment 92488 --> https://bugs.freedesktop.org/attachment.cgi?id=92488&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/20140120/52068d7c/attachment.html>
[Bug 73511] clinfo mises Max clock frequency on r600
https://bugs.freedesktop.org/show_bug.cgi?id=73511 --- Comment #5 from Tom Stellard --- (In reply to comment #4) > Created attachment 92115 [details] [review] > [PATCH rebased] drm/radeon: add query to fetch the max engine clock. > > (In reply to comment #2) > > Here's the kernel patch: > > http://people.freedesktop.org/~agd5f/0001-drm-radeon-add-query-to-fetch-the- > > max-engine-clock.patch > This patch doesn't apply to latest git tree. I've rebased it. Have you been able to test the patches? Do they work? -- 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/20140120/2fb4944b/attachment.html>
[PATCH] intel: Track whether a buffer is idle to avoid trips to the kernel.
Dear Eric,
thank you for the patch. I noticed one typo.
Am Mittwoch, den 15.01.2014, 00:38 -0800 schrieb Eric Anholt:
> I've seen a number of apps spending unreasonable amounts of time in
> drm_intel_bo_busy during the buffer mapping process.
>
> We can't track idleness in general, in the case of buffers shared
> across processes. But this should significantly reduce our overhead
> for checking for busy on things like VBOs.
>
> Improves (unoptimized) glamor x11perf -f8text by 0.243334% +/-
> 0.161498% (n=1549), which has formerly been spending about .5% of its
> time hitting the kernel for drm_intel_gem_bo_busy().
> ---
>
> I've still got a patch outstanding on the list for valgrind-cleaning
> the modesetting paths. Since we're probably rolling a release soon,
> that might be nice to get in.
>
> intel/intel_bufmgr_gem.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 75e95e6..27ad576 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -212,6 +212,15 @@ struct _drm_intel_bo_gem {
> bool reusable;
>
> /**
> + * Boolean of whether the GPU is definitely not accessing the buffer.
> + *
> + * This is only valid when reusable, since non-reusable
> + * buffers are those that have been shared wth other
w*i*th
> + * processes, so we don't know their state.
> + */
> + bool idle;
> +
> + /**
>* Size in bytes of this buffer and its relocation descendents.
>*
>* Used to avoid costly tree walking in
The rest looks fine.
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/94b36a5a/attachment.pgp>
Is a stale image but moving mouse cursor a driver problem?
Dear DRI folks, using Debian Sid/unstable with Linux 3.12.6, GNOME 3.8 and the Radeon stack the following problem happened, I do not know what to make of it. Under unknown circumstances the GNOME Screensaver on tty7 ?freezes?. The big clock in the background can be seen, but nothing can be entered (or there is no feedback). Only the mouse cursor can be moved. Switching to tty1 works and then switching back to tty7 the image from tty1 is still seen (distribution information in the first line and `hostname login:` in second) and the mouse cursor can still be moved. There are no messages shown in `.xsession-errors`, `/var/log/syslog` or `/var/log/Xorg.0.log`. Asking the GNOME folks about it in #gnome-shell on they replied it might be a driver bug. Can you confirm that? Are there any log files I can look at or other things I can do to find out what is wrong? Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/f957a097/attachment.pgp>
[Bug 73852] New: Dota 2: texture corruption (r600 on HD 6550M)
https://bugs.freedesktop.org/show_bug.cgi?id=73852 Priority: medium Bug ID: 73852 Assignee: dri-devel at lists.freedesktop.org Summary: Dota 2: texture corruption (r600 on HD 6550M) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: matejcs at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Hi, this is my first bug report, so feel free to point me in a different direction if necessary please. I am getting a flawless 30+ fps on one of the tutorial maps without any graphical glitch. However on a different map, there are heavy texture issues. Please see: http://youtu.be/wHLVaa5aTmA Last few lines from dmesg after gameplay: [ 3375.201258] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 3375.223619] radeon :02:00.0: evergreen_cs_track_check:974 mask 0x0777 | 0x0FFF no cb for 2 [ 3375.223625] radeon :02:00.0: evergreen_packet3_check:1918 invalid cmd stream [ 3375.223628] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 3375.248243] radeon :02:00.0: evergreen_cs_track_check:974 mask 0x0777 | 0x0FFF no cb for 2 [ 3375.248254] radeon :02:00.0: evergreen_packet3_check:1918 invalid cmd stream [ 3375.248259] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! Setup details: Game: Dota 2 Game version: latest update on January 9, 2014 Settings: Highest settings on 1920x1080 (low shadows) Kernel: 3.13.0-031300-generic GPU: 6550M GPU RAM: 1GB DDR3 CPU: i3 380m 2.5GHz RAM: 8GB DDR3 Distribution: Ubuntu 13.10 OpenGL version string: 3.0 Mesa 10.1.0-devel (git-d6b6ab5 saucy-oibaf-ppa+curaga) Thank you, Matyas -- 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/20140120/cdde2904/attachment-0001.html>
[ANNOUNCE] libdrm 2.4.52
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Widawsky (3): intel: squash unused variable 'bo_gem' intel: Handle malloc fails in context create intel: Merge latest i915_drm.h Eric Anholt (2): drm: Initialize or valgrind-clear modesetting ioctl arguments. intel: Track whether a buffer is idle to avoid trips to the kernel. Hyungwon Hwang (1): tests/kmstest: support exynos Keith Packard (1): Mark debug_print with __attribute__ ((format(__printf__, 1, 0))) Kenneth Graunke (2): intel: Create a new drm_intel_bo offset64 field. Bump the version to 2.4.52 Rob Clark (1): freedreno: add fd_device_new_dup() Vincent ABRIOU (1): modetest: add the possibility to select the refresh frequency for a mode git tag: libdrm-2.4.52 http://dri.freedesktop.org/libdrm/libdrm-2.4.52.tar.bz2 MD5: 01b75624a5da3a7543923e54c3547a24 libdrm-2.4.52.tar.bz2 SHA1: 7be6767efd0988c76c984fcdd1c8b712bcb9aea5 libdrm-2.4.52.tar.bz2 SHA256: fa693c2f1f61befcefbdcc396673e38481110bac9db610afa4b8afb2be0218c1 libdrm-2.4.52.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.52.tar.gz MD5: cb3547ccb435be6d80df68840da6b2ee libdrm-2.4.52.tar.gz SHA1: 356719ddee5d24b02106824ff69774e1f540ac9f libdrm-2.4.52.tar.gz SHA256: 8430fdc2edf11bce8932b6dbbe1cd128056e36865b13c7633a3298d7c42e7d08 libdrm-2.4.52.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS3atyAAoJEFtb2gcdScw4duYP/R+y23oK09C5NeCz3DTLyIQi n7LHnZ37xDZ2A/g+FORQNyglPMPZ3Ey6M8NkpJ0NRS8tN8W90ezVVubwMEUF8doW wtEw9ehSMXzhBu6R0Ervy1EjP7GygbmsWL6Pc+JXE7aNQ+l9Yi/7+zYZgb1KPYRv znq8VEi6EC9kLIEBrTnE6x/WBHQA/fdvMXAeww+y5ru+7Inlc4yxtFS/k0euBJox ytD1NbVLtPzafjgiD7XElPeiXchPoUYEZ5FffQv3HUo2OYKhydg13A7GeUyTRW5D J4uPSnGoAEF+IDnYL37tzeDVMjFZX0JigwAGFVNltkvuTWVsFbPO31PEyu8JbibJ mvKTsRdfKQzkVC9NEuE26e96M1VdTQsmbxApc9eNp5DaNxfsahq0bWF7vnzQ0Qhy qtRkRvd9WfVszV9bg53wvIos3u6DIugZ+dqIeSizMRDx5LXVPYmffChN38BhREvK elsdL9v0wgb0U17mS52IesR1CJl2NdnAREkaT9iDKeVfySmWUZGumdX75q12eEUo I+9yH0/79mq+mQ0j0FrUZLSsrwIpxLYsJRcRwOEVLKwuppL8r3C2aTDvE8zNJptA Izh5rxVXptCjfnLnzEo+V5az+RU8Ufp0MSj7HSiLxxg/Fd/dER7RjjyETUDlHJW5 JV65i5mwH4J6T85PRIEO =FaHh -END PGP SIGNATURE-
[Bug 73788] [Radeon HD 7770 GHz Edition] Cape Verde XT: DPM set state failed
https://bugs.freedesktop.org/show_bug.cgi?id=73788 --- Comment #4 from Alex Deucher --- Is this a regression? Was dpm working previously at some point, if so when? -- 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/20140120/8d837238/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #3 from Alex Deucher --- (In reply to comment #0) > With ASUS Radeon R9 270, just after I boot up and GDM is supposed to start, > my screen goes blank and some GPU faults are reported in dmesg. > > Upgrading to kernel 3.13 solves this issue. Any chance you could bisect to see what the fix was? -- 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/20140120/05cbd3ae/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #4 from Marti Raudsepp --- (In reply to comment #3) > Any chance you could bisect to see what the fix was? Is that safe? I'm not thrilled at the thought of booting prerelease kernels on my primary workstation. There's a chance of hitting filesystem/RAID/etc corruption bugs, no? Are there any liveUSB systems I could use instead of my own main installation? -- 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/20140120/7f662a22/attachment.html>
[pull] radeon drm-next-3.14
Hi Dave, New tree with the INFO ioctl merge fixed up. This also adds a couple of additional minor fixes. The following changes since commit cfd72a4c2089aa3938f37281a34d6eb3306d5fd8: Merge branch 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel into drm-next (2014-01-20 10:21:54 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.14 for you to fetch changes up to 5d029339bb8ce69aeb68280c3de67d3cea456146: drm/radeon: add UVD support for OLAND (2014-01-20 18:20:58 -0500) Alex Deucher (21): Revert "drm/radeon: disable CIK CP semaphores for now" drm/radeon: consolidate cp hdp flushing code for CIK drm/radeon: consolidate sdma hdp flushing code for CIK drm/radeon/cik: use POLL_REG_MEM special op for sDMA HDP flush drm/radeon/cik: use WAIT_REG_MEM special op for CP HDP flush drm/radeon: disable dpm on BTC drm/radeon/cik: use hw defaults for TC_CFG registers drm/radeon: disable ss on DP for DCE3.x drm/radeon/dp: bump i2c-over-aux retries to 7 drm/radeon/dp: use usleep_range rather than udelay drm/radeon/dp: sleep after powering up the display drm/radeon: add query to fetch the max engine clock (v2) drm/radeon: handle ss percentage divider properly drm/radeon: bail early from enable ss in certain cases drm/radeon: write gfx pg bases even when gfx pg is disabled drm/radeon: fix endian handling in radeon_atom_init_mc_reg_table drm/radeon/dpm: disable mclk switching on desktop RV770 drm/radeon: fix surface sync in fence on cayman (v2) drm/radeon: set the full cache bit for fences on r7xx+ drm/radeon: fix minor typos in si_dpm.c drm/radeon: add UVD support for OLAND Christian K?nig (1): drm/radeon: don't power gate paused UVD streams drivers/gpu/drm/radeon/atombios_crtc.c | 32 +++ drivers/gpu/drm/radeon/atombios_dp.c | 18 +++--- drivers/gpu/drm/radeon/cik.c | 95 drivers/gpu/drm/radeon/cik_sdma.c| 43 +++ drivers/gpu/drm/radeon/ni.c | 16 +++--- drivers/gpu/drm/radeon/nid.h | 1 + drivers/gpu/drm/radeon/r600.c| 13 +++-- drivers/gpu/drm/radeon/r600d.h | 1 + drivers/gpu/drm/radeon/radeon_atombios.c | 19 +-- drivers/gpu/drm/radeon/radeon_kms.c | 7 +++ drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/radeon_pm.c | 10 +++- drivers/gpu/drm/radeon/radeon_uvd.c | 3 + drivers/gpu/drm/radeon/rv770_dpm.c | 20 --- drivers/gpu/drm/radeon/si.c | 3 + drivers/gpu/drm/radeon/si_dpm.c | 4 +- drivers/gpu/drm/radeon/uvd_v2_2.c| 1 + include/uapi/drm/radeon_drm.h| 2 + 18 files changed, 178 insertions(+), 111 deletions(-)
[PATCH v3] ACPI / video: Add systems that should favor native backlight interface
Hi Igor, On 01/18/2014 09:54 PM, Igor Gnatenko wrote: > From: Aaron Lu > > Some system's ACPI video backlight control interface is broken and the > native backlight control interface should be used by default. This patch > sets the use_native_backlight parameter to true for those systems so > that video backlight control interface will not be created. To be > specific, the ThinkPad T430s/X230/X1 Carbon, Lenovo Yoga 13, Dell > Inspiron 7520, Acer Aspire 5733Z and HP ProBook 4340s are added here, > if they appear in some other DMI table before, they are removed from there. > > Note that the user specified kernel cmdline option will always have the > highest priority, i.e. if use_native_backlight=0 is specified and the > system is in the DMI table, the video module will not skip registering > backlight interface for it. > > Thinkpad T430s: > Reported-by: Theodore Tso > Reported-and-tested-by: Peter Weber > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231 > Thinkpad X230: > Reported-and-tested-by: Igor Gnatenko > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51231 > ThinkPad X1 Carbon: > Reported-and-tested-by: Igor Gnatenko > Lenovo Yoga 13: > Reported-by: Lennart Poettering > Reported-and-tested-by: Kevin Smith > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=63811 > Dell Inspiron 7520: > Reported-by: Rinat Ibragimov > Acer Aspire 5733Z: > Reported-by: > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=62941 > HP ProBook 4340s: > Reported-and-tested-by: Vladimir Sherenkov > Reference: http://redmine.russianfedora.pro/issues/1258 > > Signed-off-by: Aaron Lu > Signed-off-by: Igor Gnatenko Thanks for updating this patch. In the meantime, I plan to make some small modifications to this patch in next revision: 1 remove the win8 OSI check, I've seen win7 laptops that also needs to have only the GPU interface left and checking win8 doesn't make much sense now; 2 add more entries for laptops that appeared in bugzilla recently.
[PATCH] fs: export simple_dname for drm drivers.
On Mon, Jan 20, 2014 at 10:54:44AM +1000, Dave Airlie wrote:
> David Herrmann's changes to use a pseudo filesystem for drm's shared
> inodes requires this be exported for drm to build as a module.
>
> I'd like to merge this via the drm tree, so please ack.
Having looked through these patches... The problem is that you'll get
your module impossible to unload. Sane solution:
static struct vfsmount *drm_mnt;
static int count;
struct inode *drm_alloc_inode(void)
{
struct inode *res;
int err = simple_pin_fs(&drm_fs, &drm_mnt, &count);
if (err)
return ERR_PTR(err);
res = alloc_anon_inode(drm_mnt->mnt_sb);
if (IS_ERR(res))
simple_release_fs(&drm_mnt, &count);
return res;
}
/* call from drm_free_dev() */
void drm_put_anon_inode(struct drm_device *dev)
{
iput(dev->anon_inode);
simple_release_fs(&drm_mnt, &count);
}
and lose those kern_mount/kern_umount.
[PATCH v3 16/24] drm/i2c: tda998x: add DT documentation
On Sun, 19 Jan 2014 20:06:09 -0800
Olof Johansson wrote:
> Hi,
>
> On Sun, Jan 19, 2014 at 10:58 AM, Jean-Francois Moine
> wrote:
> > Signed-off-by: Jean-Francois Moine
> > ---
> > .../devicetree/bindings/drm/i2c/tda998x.txt| 24
> > ++
> > 1 file changed, 24 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/drm/i2c/tda998x.txt
>
> Please cc bindings for review to devicetree at vger.kernel.org (cc:d here now)
>
> > diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> > b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> > new file mode 100644
> > index 000..72da71d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
> > @@ -0,0 +1,24 @@
> > +Device-Tree bindings for the NXP TDA998x HDMI transmitter
> > +
> > +Required properties;
> > + - compatible: must be "nxp,tda998x"
> > +
> > +Optional properties:
> > + - interrupts: interrupt number for HDMI exchanges - default: by polling
>
> What are HDMI exchanges, and how do they differ from other interrupts?
The used HDMI interrupt events are screen plug/unplug and EDID read.
There are also CEC read/write which are not yet implemented in the
tda998x driver.
There is no difference from normal interrupts, except that the events
may be get by polling, so, the interrupt number is optional.
> > +
> > + - pinctrl-0: pin control group to be used for this controller (IRQ).
> > +
> > + - pinctrl-names: must contain a "default" entry.
> > +
> > + - video-ports: 24 bits value - default: <0x230145>
>
> What is this?
The video-ports value defines how the video controller is connected to
the tda998x chip. Each 4 bits value tells from which input pins comes
the video data and if there is any bit inversion. Each byte of this
video-ports is used to load the VIP_CNTRL_{0,1,2} registers. These ones
are described in the TDA9983B documentation which is the closer
available document about the TDA998x family.
The default value is the one defined for TI boards.
A known other value is <0x234501> which is used for Russell's Armada
DRM driver in the Cubox (Marvell A510), but this driver has no DT
support.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
[GIT PULL] omapdrm patches for 3.14
Dave, Ping. Tomi On 2014-01-09 15:31, Tomi Valkeinen wrote: > Hi Dave, > > Here are some omapdrm changes for 3.14 which have been around the lists > for some time now. > > Tomi > > The following changes since commit 802eee95bde72fd0cd0f3a5b2098375a487d1eda: > > Linux 3.13-rc6 (2013-12-29 16:01:33 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git > tags/omapdrm-3.14 > > for you to fetch changes up to 3d232346c5656b300028b6c920ddc10b229b5264: > > drm/omap: Enable DT support for DMM (2014-01-09 15:25:35 +0200) > > > omapdrm patches for 3.14 > > > Archit Taneja (5): > drm/omap: fix: Defer probe if an omapdss device requests for it at > connect > drm/omap: fix: disconnect devices when omapdrm module is removed > drm/omap: fix: disable encoder before destroying it > drm/omap: fix: change dev_unload order > drm/omap: Enable DT support for DMM > > Tomi Valkeinen (1): > drm/omap: fix (un)registering irqs inside an irq handler > > drivers/gpu/drm/omapdrm/omap_crtc.c | 11 +-- > drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 9 ++ > drivers/gpu/drm/omapdrm/omap_drv.c | 83 > > drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++ > drivers/gpu/drm/omapdrm/omap_encoder.c | 3 ++ > drivers/gpu/drm/omapdrm/omap_irq.c | 22 +++--- > drivers/video/omap2/dss/dispc.c | 1 - > 7 files changed, 99 insertions(+), 33 deletions(-) > -- 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/20140120/bfe2c9a6/attachment-0001.pgp>
Sharing Framebuffers between Client / Server
Thanks for reply.? Actually in my case, when I say client/server, I mean replacement for X, so XShmPutImage won?t work. What we are trying to do is actually similar to Wayland, and need to provide each client with a scannot buffer for direct rendering, while at the same time, providing a means for the server to read/write to all of the scannot buffers.? We have looked into EGL (EGL_DRM_BUFFER_USE_SCANOUT_MESA), but I have yet to code this up (will likely work on that this week), to see if it will work for us. We started with an example that we found, that was coded wrong in many ways. The biggest issue though, was that the buffer allocated using libkms could not be shared. We also looked into drmAddBuf / drmMapBuf, from what I could tell, nobody was using them. GEM seems to be the option of choice but vmwgfx doesn?t support that yet. Thanks, - Rian Sent with Unibox > On Jan 20, 2014, at 8:10 AM, Rob Clark wrote: > > > On Fri, Jan 17, 2014 at 6:43 AM, Rian Quinn wrote: > > >> I am working on a client/server program, where the server creates (and has >> access to a framebuffer), and then needs to share this framebuffer with a >> client program so that this client program can draw into the framebuffer >> directly (i.e. no memcpy). >> >> >> I am trying to figureout what the ?cleanest? way to do this is, such that I >> can support Intel?s proprietary driver, the open source AMD and NVidia >> drivers, and the VMWare driver (I have no need for the proprietary >> ADM/NVidia drivers right now). From what I can tell, GEM is one way to do >> this. The problem is VMWare doesn?t support GEM. >> >> >> I tried (knowing it would not work), using KMS to create the framebuffer, >> and then sending the information needed to mmap to the client. This of >> course failed because the framebuffer is marked non-sharable in the kernel. >> >> >> > > Dmabuf (or just plain old egl/glx which uses dri2 under the hood) > would probably be what I suggest *except* you mention mmap. If you > are doing software rendering, I guess you probably just want to suck > it up and do XShmPutImage. > > > From what I understand, any sort of mmap access to vmwgfx buffers is > tricky, because they end up being backed by normal GL textures on the > host OS side (IIUC). So the single copy upload path in XShmPutImage > might be close to the ideal path for sw rendered content. > > >> To be clear, I am fine having to manually write ioctls for each driver, if >> thats what it takes. But at this point, I am at a loss on the best method to >> share scannot buffers (or at least in a way that doesn?t make someone cringe >> when they see my code). >> >> >> > > Some sort of prepare/finish access ioctls for dmabuf to bracket mmap > access are, I think, what vmwgfx is missing in order to implement > dmabuf mmap. But no one so far has needed them badly enough to come > up with something and send patches. > > > IIUC, for vmwgfx there would still be a copy back to original texture > on the host on finish-access, so it might not amount to anything much > different from XShmPutImage. Probably better to ask some vmwgfx folks > to clarify, since the virtual driver has some unique constraints which > I may not be adequately representing. > > > BR, > -R > > >> Thanks, >> - Rian >> >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/53a1370a/attachment.html>
[PATCH v3] ACPI / video: Add systems that should favor native backlight interface
On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote: > 1 remove the win8 OSI check, I've seen win7 laptops that also needs to > have only the GPU interface left and checking win8 doesn't make much > sense now; Are we sure that those aren't simply some other bug? -- Matthew Garrett
Sharing Framebuffers between Client / Server
> > If both the server and client would be 100% software one could create > and share "dumb" kms buffers using DRM prime. If there's something in > the vmwgfx driver that blocks sharing in this way, we could ease that > restriction. But these buffers could not be rendered into. > > > GEM is, BTW, purely driver-private. > > > As you might see, the big restriction here is that there is no simple > generic way to mmap() accelerated shared buffers from a lean client. > This is intentional. For vmwgfx it's because of coherency issues that > would make such an implementation inefficient. For other drivers I can > imagine there are tiling- and caching issues. > > > /Thomas > > >> >> >>> Thanks, >>> - Rian >>> >>> >>> ___ >>> dri-devel mailing list >>> dri-devel at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> >>> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> > > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140120/be22e56d/attachment-0001.html>
