[PATCH] MAINTAINERS: Update drm/i915 git repo
Hi Daniel, On Tue, 4 Feb 2014 20:15:03 +0100 Daniel Vetter wrote: > > On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter > wrote: > > Moved to a common location so that Jani also can push to it, to avoid > > moving it every time I go on vacation. Please update autobuilders and > > everything else pointing at the drm-intel.git repo, the old one won't > > be updated any more. > > > > Cc: Dave Airlie > > Cc: Jani Nikula > > Signed-off-by: Daniel Vetter > > Oops, forgotten to cc our linux-next maintainer about this. Branch > names are still the same and I've checked that my scripts recreated > them all properly. So this should be good to go for the next -next. Thanks for letting me know - all updated now. -- Cheers, Stephen Rothwellsfr at canb.auug.org.au -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140205/bb6a77fb/attachment-0001.pgp>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 --- Comment #4 from Michel D?nzer --- (In reply to comment #3) > @Michel D?nzer, did you mean output of dmesg directly after crash, or just a > general one? Preferably the former, but the latter will do in the meantime. Does the problem also occur without Option "EXAVSync"? -- 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/20140205/bb72e328/attachment.html>
[Bug 74511] Increasing EQ - X freezes
https://bugs.freedesktop.org/show_bug.cgi?id=74511 --- Comment #2 from Michel D?nzer --- (In reply to comment #2) > I suspect this is related to Bug 74420 - EQ overflowing Indeed. Why did you file a separate report? What's the difference? -- 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/20140205/475b1ff1/attachment.html>
[RFC 12/16] drm/nouveau/fifo: add GK20A support
Hi Daniel,
On 02/04/2014 06:15 PM, Daniel Vetter wrote:
> On Sat, Feb 01, 2014 at 12:16:54PM +0900, Alexandre Courbot wrote:
>> GK20A's FIFO is compatible with NVE0, but only features 128 channels and
>> 1 runlist.
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/drm/nouveau/Makefile | 1 +
>> drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h| 1 +
>> drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c| 27
>> ++
>> drivers/gpu/drm/nouveau/core/include/engine/fifo.h | 1 +
>> 4 files changed, 30 insertions(+)
>> create mode 100644 drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
>>
>> diff --git a/drivers/gpu/drm/nouveau/Makefile
>> b/drivers/gpu/drm/nouveau/Makefile
>> index e88145b..6c4b76d 100644
>> --- a/drivers/gpu/drm/nouveau/Makefile
>> +++ b/drivers/gpu/drm/nouveau/Makefile
>> @@ -236,6 +236,7 @@ nouveau-y += core/engine/fifo/nv50.o
>> nouveau-y += core/engine/fifo/nv84.o
>> nouveau-y += core/engine/fifo/nvc0.o
>> nouveau-y += core/engine/fifo/nve0.o
>> +nouveau-y += core/engine/fifo/nvea.o
>> nouveau-y += core/engine/fifo/nv108.o
>> nouveau-y += core/engine/graph/ctxnv40.o
>> nouveau-y += core/engine/graph/ctxnv50.o
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
>> b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
>> index 014344e..e96b32b 100644
>> --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
>> +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h
>> @@ -8,6 +8,7 @@ int nve0_fifo_ctor(struct nouveau_object *, struct
>> nouveau_object *,
>> struct nouveau_object **);
>> void nve0_fifo_dtor(struct nouveau_object *);
>> int nve0_fifo_init(struct nouveau_object *);
>> +int nve0_fifo_fini(struct nouveau_object *, bool);
>>
>> struct nve0_fifo_impl {
>> struct nouveau_oclass base;
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
>> b/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
>> new file mode 100644
>> index 000..16f8905
>> --- /dev/null
>> +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Copyright (c) 2014, NVIDIA Corporation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>
> Just stumbled over this lincense header: Generally drm is mit/gpl dual
> lincensed. The important part for me is the drm core, but due to all the
> refactoring we tend to do and code extraction from drivers those are
> rather relevant imo, too. Was this just an oversight or are you still
> working with your legap people on this?
Thanks for pointing this out. This was an oversight on my part indeed.
The following revisions will use the correct MIT copyright header.
In case someone wants to contribute significant fixes to this patchset,
please be aware that MIT is the license that will apply from now on.
Thanks,
Alex.
[Bug 66331] WebGL water demo crashes LLVM
https://bugs.freedesktop.org/show_bug.cgi?id=66331 Dieter N?tzel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dieter N?tzel --- I said that I have 3.4 final (current stable)... Anyway, it is FIXED, now! - GREAT job! openSUSE 13.1 kernel 3.13.1 LLVM 3.4 ;-) Mesa 10.1.0-devel (git-16215a9) --- The first r600g geom shader (OpenGL 3.3) tree. --- But I have to patch my kernel...;-) r600g (RV730 AGP) Konqueror 4.12.2 (KDE 4.12.2) Could be CLOSED, now. -- 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/20140205/68deb85c/attachment.html>
[PATCH] drm/mgag200: fix typo causing bw limits to be ignored on some chips
From: Dave Airlie
mode->mdev otherwise the bw limits never kick in.
Reported in RHEL testing.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index b8583f2..9683747 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1519,11 +1519,11 @@ static int mga_vga_mode_valid(struct drm_connector
*connector,
(mga_vga_calculate_mode_bandwidth(mode, bpp)
> (32700 * 1024))) {
return MODE_BANDWIDTH;
- } else if (mode->type == G200_EH &&
+ } else if (mdev->type == G200_EH &&
(mga_vga_calculate_mode_bandwidth(mode, bpp)
> (37500 * 1024))) {
return MODE_BANDWIDTH;
- } else if (mode->type == G200_ER &&
+ } else if (mdev->type == G200_ER &&
(mga_vga_calculate_mode_bandwidth(mode,
bpp) > (55000 * 1024))) {
return MODE_BANDWIDTH;
--
1.8.4.2
[3.14-rc1] cirrus driver problem (qemu)
On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca wrote: > 2014-02-04, 13:20:54 +1000, Dave Airlie wrote: >> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca >> wrote: >> > When I boot 3.14-rc1 in qemu, I get the trace below. The console stops >> > updating and I don't get a login prompt. I can login, but I can't see >> > what I'm doing. I can login normally via SSH. >> > >> > If I revert the last commit in drivers/gpu/drm/cirrus: >> > >> > f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 drm: ast,cirrus,mgag200: use >> > drm_can_sleep >> > >> > the problem is solved. >> > >> >> Hi does the attach patch fix it? >> >> Dave. > > > Same problem. Didn't you reverse the logic on in_interrupt, compared > to the old "if (!in_interrupt())" ? It looks like drm_can_sleep() is > false when in_interrupt() is true. > > I modified your patch as below. Display doesn't freeze, but I still > get the warning. Oh wow I totally screwed up there, you are right, logic inversion. Can you try the attached? without the in_interrupt addition. Dave. -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-mgag200-ast-cirrus-fix-regression-with-drm_can_s.patch Type: text/x-patch Size: 2029 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140205/0cf81a5e/attachment.bin>
[PATCH 1/7] drm/vmwgfx: Don't commit staged bindings if execbuf fails
If execbuf fails and binding commands are never sent to the device,
don't commit the staged context bindings to the tracker.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 7a5f1eb..3f0b4d1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -114,8 +114,10 @@ static void vmw_resource_list_unreserve(struct list_head
*list,
* persistent context binding tracker.
*/
if (unlikely(val->staged_bindings)) {
- vmw_context_binding_state_transfer
- (val->res, val->staged_bindings);
+ if (!backoff) {
+ vmw_context_binding_state_transfer
+ (val->res, val->staged_bindings);
+ }
kfree(val->staged_bindings);
val->staged_bindings = NULL;
}
--
1.7.10.4
[PATCH 2/7] drm/vmwgfx: Fix regression caused by "drm/ttm: make ttm reservation calls behave like reservation calls"
The call to ttm_eu_backoff_reservation() as part of an error path would cause a lock imbalance if the reservation ticket was not initialized. This error is easily triggered from user-space by submitting a bogus command stream. Signed-off-by: Thomas Hellstrom Reviewed-by: Jakob Bornecrantz Cc: stable at vger.kernel.org Cc: Maarten Lankhorst Cc: Jerome Glisse Cc: Dave Airlie --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c index 3f0b4d1..dafa139 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -2195,11 +2195,11 @@ int vmw_execbuf_process(struct drm_file *file_priv, ret = vmw_cmd_check_all(dev_priv, sw_context, kernel_commands, command_size); if (unlikely(ret != 0)) - goto out_err; + goto out_err_nores; ret = vmw_resources_reserve(sw_context); if (unlikely(ret != 0)) - goto out_err; + goto out_err_nores; ret = ttm_eu_reserve_buffers(&ticket, &sw_context->validate_nodes); if (unlikely(ret != 0)) @@ -2291,10 +2291,11 @@ int vmw_execbuf_process(struct drm_file *file_priv, out_unlock_binding: mutex_unlock(&dev_priv->binding_mutex); out_err: - vmw_resource_relocations_free(&sw_context->res_relocations); - vmw_free_relocations(sw_context); ttm_eu_backoff_reservation(&ticket, &sw_context->validate_nodes); +out_err_nores: vmw_resource_list_unreserve(&sw_context->resource_list, true); + vmw_resource_relocations_free(&sw_context->res_relocations); + vmw_free_relocations(sw_context); vmw_clear_validations(sw_context); if (unlikely(dev_priv->pinned_bo != NULL && !dev_priv->query_cid_valid)) -- 1.7.10.4
[PATCH 3/7] drm/vmwgfx: Fix SET_SHADER_CONST emulation on guest-backed devices
Emulate the SET_SHADER_CONST legacy command on guest-backed devices by
issuing a SET_GB_SHADERCONSTS_INLINE command.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 37 +--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index dafa139..9441825 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1529,6 +1529,39 @@ static int vmw_cmd_set_shader(struct vmw_private
*dev_priv,
}
/**
+ * vmw_cmd_set_shader_const - Validate an SVGA_3D_CMD_SET_SHADER_CONST
+ * command
+ *
+ * @dev_priv: Pointer to a device private struct.
+ * @sw_context: The software context being used for this batch.
+ * @header: Pointer to the command header in the command stream.
+ */
+static int vmw_cmd_set_shader_const(struct vmw_private *dev_priv,
+ struct vmw_sw_context *sw_context,
+ SVGA3dCmdHeader *header)
+{
+ struct vmw_set_shader_const_cmd {
+ SVGA3dCmdHeader header;
+ SVGA3dCmdSetShaderConst body;
+ } *cmd;
+ int ret;
+
+ cmd = container_of(header, struct vmw_set_shader_const_cmd,
+ header);
+
+ ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_context,
+ user_context_converter, &cmd->body.cid,
+ NULL);
+ if (unlikely(ret != 0))
+ return ret;
+
+ if (dev_priv->has_mob)
+ header->id = SVGA_3D_CMD_SET_GB_SHADERCONSTS_INLINE;
+
+ return 0;
+}
+
+/**
* vmw_cmd_bind_gb_shader - Validate an SVGA_3D_CMD_BIND_GB_SHADER
* command
*
@@ -1642,8 +1675,8 @@ static const struct vmw_cmd_entry const
vmw_cmd_entries[SVGA_3D_CMD_MAX] = {
true, true, false),
VMW_CMD_DEF(SVGA_3D_CMD_SET_SHADER, &vmw_cmd_set_shader,
true, false, false),
- VMW_CMD_DEF(SVGA_3D_CMD_SET_SHADER_CONST, &vmw_cmd_cid_check,
- true, true, false),
+ VMW_CMD_DEF(SVGA_3D_CMD_SET_SHADER_CONST, &vmw_cmd_set_shader_const,
+ true, false, false),
VMW_CMD_DEF(SVGA_3D_CMD_DRAW_PRIMITIVES, &vmw_cmd_draw,
true, false, false),
VMW_CMD_DEF(SVGA_3D_CMD_SETSCISSORRECT, &vmw_cmd_cid_check,
--
1.7.10.4
[PATCH 0/7] Various vmwgfx fixes
Mostly problems caused by the new device support. Unfortunately a couple of rather big patches at the end. These add the missing bits required to run legacy user-space drivers on the new device
[PATCH 4/7] drm/vmwgfx: Fix legacy surface reference size copyback
Surfaces created using the guest-backed surface interface only keeps the
base mip size, so only copy that if the legacy surface reference
ioctl requests the size information.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 979da1c..ec2b998 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -908,8 +908,8 @@ int vmw_surface_reference_ioctl(struct drm_device *dev,
void *data,
rep->size_addr;
if (user_sizes)
- ret = copy_to_user(user_sizes, srf->sizes,
- srf->num_sizes * sizeof(*srf->sizes));
+ ret = copy_to_user(user_sizes, &srf->base_size,
+ sizeof(srf->base_size));
if (unlikely(ret != 0)) {
DRM_ERROR("copy_to_user failed %p %u\n",
user_sizes, srf->num_sizes);
--
1.7.10.4
[PATCH 5/7] drm/vmwgfx: Emulate legacy shaders on guest-backed devices v2
Command stream legacy shader creation and destruction is replaced by
NOPs in the command stream, and instead guest-backed shaders are created
and destroyed as part of the command validation process.
v2: Removed some stray debug messages.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |7 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 29 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 197 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 465 +++
4 files changed, 620 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 9893328..3bdc0ad 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -941,6 +941,7 @@ static void vmw_postclose(struct drm_device *dev,
drm_master_put(&vmw_fp->locked_master);
}
+ vmw_compat_shader_man_destroy(vmw_fp->shman);
ttm_object_file_release(&vmw_fp->tfile);
kfree(vmw_fp);
}
@@ -960,11 +961,17 @@ static int vmw_driver_open(struct drm_device *dev, struct
drm_file *file_priv)
if (unlikely(vmw_fp->tfile == NULL))
goto out_no_tfile;
+ vmw_fp->shman = vmw_compat_shader_man_create(dev_priv);
+ if (IS_ERR(vmw_fp->shman))
+ goto out_no_shman;
+
file_priv->driver_priv = vmw_fp;
dev_priv->bdev.dev_mapping = dev->dev_mapping;
return 0;
+out_no_shman:
+ ttm_object_file_release(&vmw_fp->tfile);
out_no_tfile:
kfree(vmw_fp);
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 554e7fa..cef0ff7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -75,10 +75,14 @@
#define VMW_RES_FENCE ttm_driver_type3
#define VMW_RES_SHADER ttm_driver_type4
+struct vmw_compat_shader_manager;
+
struct vmw_fpriv {
struct drm_master *locked_master;
struct ttm_object_file *tfile;
struct list_head fence_events;
+ bool gb_aware;
+ struct vmw_compat_shader_manager *shman;
};
struct vmw_dma_buffer {
@@ -318,7 +322,7 @@ struct vmw_sw_context{
struct drm_open_hash res_ht;
bool res_ht_initialized;
bool kernel; /**< is the called made from the kernel */
- struct ttm_object_file *tfile;
+ struct vmw_fpriv *fp;
struct list_head validate_nodes;
struct vmw_relocation relocs[VMWGFX_MAX_RELOCATIONS];
uint32_t cur_reloc;
@@ -336,6 +340,7 @@ struct vmw_sw_context{
bool needs_post_query_barrier;
struct vmw_resource *error_resource;
struct vmw_ctx_binding_state staged_bindings;
+ struct list_head staged_shaders;
};
struct vmw_legacy_display;
@@ -991,6 +996,28 @@ extern int vmw_shader_define_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv);
extern int vmw_shader_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int vmw_compat_shader_lookup(struct vmw_compat_shader_manager *man,
+ SVGA3dShaderType shader_type,
+ u32 *user_key);
+extern void vmw_compat_shaders_commit(struct vmw_compat_shader_manager *man,
+ struct list_head *list);
+extern void vmw_compat_shaders_revert(struct vmw_compat_shader_manager *man,
+ struct list_head *list);
+extern int vmw_compat_shader_remove(struct vmw_compat_shader_manager *man,
+ u32 user_key,
+ SVGA3dShaderType shader_type,
+ struct list_head *list);
+extern int vmw_compat_shader_add(struct vmw_compat_shader_manager *man,
+u32 user_key, const void *bytecode,
+SVGA3dShaderType shader_type,
+size_t size,
+struct ttm_object_file *tfile,
+struct list_head *list);
+extern struct vmw_compat_shader_manager *
+vmw_compat_shader_man_create(struct vmw_private *dev_priv);
+extern void
+vmw_compat_shader_man_destroy(struct vmw_compat_shader_manager *man);
+
/**
* Inline helper functions
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 9441825..352224b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -235,8 +235,12 @@ static void vmw_resource_relocations_apply(uint32_t *cb,
{
struct vmw_resource_relocation *rel;
- list_for_each_entry(rel, list, head)
- cb[rel->offset] = rel->res->id;
+ list_for_each_entry(rel, list, head) {
+ if (likely(rel->res != NULL))
+
[PATCH 6/7] drm/vmwgfx: Detect old user-space drivers and set up legacy emulation v2
GB aware mesa userspace drivers are detected by the fact that they are
calling the vmw getparam ioctl querying DRM_VMW_PARAM_HW_CAPS to detect
whether the device is Guest-backed object capable. For other drivers,
lie about hardware version and send the 3D capabilities in a format they
expect.
v2:
Use DRM_VMW_PARAM_MAX_MOB_MEMORY to detect gb awareness,
Make sure we don't ovwerwrite bounce buffer or write past user-space buffer
indicated size.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/svga3d_reg.h | 24 +
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 93 +++--
2 files changed, 101 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/svga3d_reg.h
b/drivers/gpu/drm/vmwgfx/svga3d_reg.h
index d95335c..b645647 100644
--- a/drivers/gpu/drm/vmwgfx/svga3d_reg.h
+++ b/drivers/gpu/drm/vmwgfx/svga3d_reg.h
@@ -2583,4 +2583,28 @@ typedef union {
float f;
} SVGA3dDevCapResult;
+typedef enum {
+ SVGA3DCAPS_RECORD_UNKNOWN= 0,
+ SVGA3DCAPS_RECORD_DEVCAPS_MIN= 0x100,
+ SVGA3DCAPS_RECORD_DEVCAPS= 0x100,
+ SVGA3DCAPS_RECORD_DEVCAPS_MAX= 0x1ff,
+} SVGA3dCapsRecordType;
+
+typedef
+struct SVGA3dCapsRecordHeader {
+ uint32 length;
+ SVGA3dCapsRecordType type;
+}
+SVGA3dCapsRecordHeader;
+
+typedef
+struct SVGA3dCapsRecord {
+ SVGA3dCapsRecordHeader header;
+ uint32 data[1];
+}
+SVGA3dCapsRecord;
+
+
+typedef uint32 SVGA3dCapPair[2];
+
#endif /* _SVGA3D_REG_H_ */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 116c497..f9881f9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -29,12 +29,18 @@
#include
#include "vmwgfx_kms.h"
+struct svga_3d_compat_cap {
+ SVGA3dCapsRecordHeader header;
+ SVGA3dCapPair pairs[SVGA3D_DEVCAP_MAX];
+};
+
int vmw_getparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct vmw_private *dev_priv = vmw_priv(dev);
struct drm_vmw_getparam_arg *param =
(struct drm_vmw_getparam_arg *)data;
+ struct vmw_fpriv *vmw_fp = vmw_fpriv(file_priv);
switch (param->param) {
case DRM_VMW_PARAM_NUM_STREAMS:
@@ -60,6 +66,11 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
__le32 __iomem *fifo_mem = dev_priv->mmio_virt;
const struct vmw_fifo_state *fifo = &dev_priv->fifo;
+ if ((dev_priv->capabilities & SVGA_CAP_GBOBJECTS)) {
+ param->value = SVGA3D_HWVERSION_WS8_B1;
+ break;
+ }
+
param->value =
ioread32(fifo_mem +
((fifo->capabilities &
@@ -69,17 +80,26 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
break;
}
case DRM_VMW_PARAM_MAX_SURF_MEMORY:
- param->value = dev_priv->memory_size;
+ if ((dev_priv->capabilities & SVGA_CAP_GBOBJECTS) &&
+ !vmw_fp->gb_aware)
+ param->value = dev_priv->max_mob_pages * PAGE_SIZE / 2;
+ else
+ param->value = dev_priv->memory_size;
break;
case DRM_VMW_PARAM_3D_CAPS_SIZE:
- if (dev_priv->capabilities & SVGA_CAP_GBOBJECTS)
- param->value = SVGA3D_DEVCAP_MAX;
+ if ((dev_priv->capabilities & SVGA_CAP_GBOBJECTS) &&
+ vmw_fp->gb_aware)
+ param->value = SVGA3D_DEVCAP_MAX * sizeof(uint32_t);
+ else if (dev_priv->capabilities & SVGA_CAP_GBOBJECTS)
+ param->value = sizeof(struct svga_3d_compat_cap) +
+ sizeof(uint32_t);
else
param->value = (SVGA_FIFO_3D_CAPS_LAST -
- SVGA_FIFO_3D_CAPS + 1);
- param->value *= sizeof(uint32_t);
+ SVGA_FIFO_3D_CAPS + 1) *
+ sizeof(uint32_t);
break;
case DRM_VMW_PARAM_MAX_MOB_MEMORY:
+ vmw_fp->gb_aware = true;
param->value = dev_priv->max_mob_pages * PAGE_SIZE;
break;
default:
@@ -91,6 +111,38 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
return 0;
}
+static int vmw_fill_compat_cap(struct vmw_private *dev_priv, void *bounce,
+ size_t size)
+{
+ struct svga_3d_compat_cap *compat_cap =
+ (struct svga_3d_compat_cap *) bounce;
+ unsigned int i;
+ size_t pair_offset = offsetof(struct svga_3d_compat_cap, pairs);
+ unsigned int max_size;
+
+ if (size < pair_offset)
+ return -EINVAL;
+
+ max_size = (size - pair_offset) / sizeof(SVGA3dCapPair);
+
+ if
[PATCH 7/7] drm/vmwgfx: Reemit context bindings when necessary v2
When a context is first referenced in the command stream, make sure that all
scrubbed (as a result of eviction) bindings are re-emitted. Also make sure that
all bound resources are put on the resource validate list.
This is needed for legacy emulation, since legacy user-space drivers will
typically not re-emit shader bindings. It also removes the requirement for
user-space drivers to re-emit render-target- and texture bindings.
Makes suspend and hibernate now also work with legacy user-space drivers on
guest-backed devices.
v2: Don't rebind on legacy devices.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 144 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6 ++
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 85 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 11 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |2 +-
6 files changed, 222 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 82c41da..9426c53 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -37,7 +37,7 @@ struct vmw_user_context {
-typedef int (*vmw_scrub_func)(struct vmw_ctx_bindinfo *);
+typedef int (*vmw_scrub_func)(struct vmw_ctx_bindinfo *, bool);
static void vmw_user_context_free(struct vmw_resource *res);
static struct vmw_resource *
@@ -50,9 +50,11 @@ static int vmw_gb_context_unbind(struct vmw_resource *res,
bool readback,
struct ttm_validate_buffer *val_buf);
static int vmw_gb_context_destroy(struct vmw_resource *res);
-static int vmw_context_scrub_shader(struct vmw_ctx_bindinfo *bi);
-static int vmw_context_scrub_render_target(struct vmw_ctx_bindinfo *bi);
-static int vmw_context_scrub_texture(struct vmw_ctx_bindinfo *bi);
+static int vmw_context_scrub_shader(struct vmw_ctx_bindinfo *bi, bool rebind);
+static int vmw_context_scrub_render_target(struct vmw_ctx_bindinfo *bi,
+ bool rebind);
+static int vmw_context_scrub_texture(struct vmw_ctx_bindinfo *bi, bool rebind);
+static void vmw_context_binding_state_scrub(struct vmw_ctx_binding_state *cbs);
static void vmw_context_binding_state_kill(struct vmw_ctx_binding_state *cbs);
static uint64_t vmw_user_context_size;
@@ -111,10 +113,14 @@ static void vmw_hw_context_destroy(struct vmw_resource
*res)
if (res->func->destroy == vmw_gb_context_destroy) {
mutex_lock(&dev_priv->cmdbuf_mutex);
+ mutex_lock(&dev_priv->binding_mutex);
+ (void) vmw_context_binding_state_kill
+ (&container_of(res, struct vmw_user_context, res)->cbs);
(void) vmw_gb_context_destroy(res);
if (dev_priv->pinned_bo != NULL &&
!dev_priv->query_cid_valid)
__vmw_execbuf_release_pinned_bo(dev_priv, NULL);
+ mutex_unlock(&dev_priv->binding_mutex);
mutex_unlock(&dev_priv->cmdbuf_mutex);
return;
}
@@ -328,7 +334,7 @@ static int vmw_gb_context_unbind(struct vmw_resource *res,
BUG_ON(bo->mem.mem_type != VMW_PL_MOB);
mutex_lock(&dev_priv->binding_mutex);
- vmw_context_binding_state_kill(&uctx->cbs);
+ vmw_context_binding_state_scrub(&uctx->cbs);
submit_size = sizeof(*cmd2) + (readback ? sizeof(*cmd1) : 0);
@@ -378,10 +384,6 @@ static int vmw_gb_context_destroy(struct vmw_resource *res)
SVGA3dCmdHeader header;
SVGA3dCmdDestroyGBContext body;
} *cmd;
- struct vmw_user_context *uctx =
- container_of(res, struct vmw_user_context, res);
-
- BUG_ON(!list_empty(&uctx->cbs.list));
if (likely(res->id == -1))
return 0;
@@ -528,8 +530,9 @@ out_unlock:
* vmw_context_scrub_shader - scrub a shader binding from a context.
*
* @bi: single binding information.
+ * @rebind: Whether to issue a bind instead of scrub command.
*/
-static int vmw_context_scrub_shader(struct vmw_ctx_bindinfo *bi)
+static int vmw_context_scrub_shader(struct vmw_ctx_bindinfo *bi, bool rebind)
{
struct vmw_private *dev_priv = bi->ctx->dev_priv;
struct {
@@ -548,7 +551,8 @@ static int vmw_context_scrub_shader(struct vmw_ctx_bindinfo
*bi)
cmd->header.size = sizeof(cmd->body);
cmd->body.cid = bi->ctx->id;
cmd->body.type = bi->i1.shader_type;
- cmd->body.shid = SVGA3D_INVALID_ID;
+ cmd->body.shid =
+ cpu_to_le32((rebind) ? bi->res->id : SVGA3D_INVALID_ID);
vmw_fifo_commit(dev_priv, sizeof(*cmd));
return 0;
@@ -559,8 +563,10 @@ static int vmw_context_scrub_shader(struct
vmw_ctx_bindinfo *bi)
* from a context.
*
* @bi: single binding inform
[PATCH] MAINTAINERS: Update drm/i915 git repo
On Tue, Feb 4, 2014 at 8:37 PM, Daniel Vetter wrote: > On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter > wrote: >> Moved to a common location so that Jani also can push to it, to avoid >> moving it every time I go on vacation. Please update autobuilders and >> everything else pointing at the drm-intel.git repo, the old one won't >> be updated any more. >> >> Cc: Dave Airlie >> Cc: Jani Nikula >> Signed-off-by: Daniel Vetter > > Also forgotten to cc our QA people ... And Wu Fengguang with his 0-day builder also needs to know about the new git repo! -Daniel >> --- >> MAINTAINERS | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 31a046213274..e3aaf277cf58 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2832,7 +2832,7 @@ M:Jani Nikula >> L: intel-gfx at lists.freedesktop.org >> L: dri-devel at lists.freedesktop.org >> Q: http://patchwork.freedesktop.org/project/intel-gfx/ >> -T: git git://people.freedesktop.org/~danvet/drm-intel >> +T: git git://anongit.freedesktop.org/drm-intel >> S: Supported >> F: drivers/gpu/drm/i915/ >> F: include/drm/i915* >> -- >> 1.8.5.2 >> > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 69901] intel ivy bridge/radeonsi PRIME hang since 3.14
https://bugzilla.kernel.org/show_bug.cgi?id=69901 --- Comment #6 from Thomas Hellstrom --- Created attachment 124621 --> https://bugzilla.kernel.org/attachment.cgi?id=124621&action=edit Patch that may fix the problem Could you try the attached patch out to see if it fixes the problem? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/ttm: Fix TTM object open regression
Commit drm/ttm: ttm object security fixes for render nodes introduced a
regression where, if a TTM object was opened multiple times from the same
open file, the caller would spin uninterruptibly in the kernel.
Fix this.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/ttm/ttm_object.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index 3707985..53b51c4 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -292,7 +292,7 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
if (ret == 0) {
ref = drm_hash_entry(hash, struct ttm_ref_object, hash);
- if (!kref_get_unless_zero(&ref->kref)) {
+ if (kref_get_unless_zero(&ref->kref)) {
rcu_read_unlock();
break;
}
--
1.7.10.4
[PATCH] drm/ttm: Don't clear page metadata of imported sg pages
These page pointers shouldn't be visible to TTM in the first place, but
until we fix that up, don't clear the page metadata because that
will upset the exporter.
Reported-by: Cristoph Haag
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_tt.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 9af9908..75f3190 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -380,6 +380,9 @@ static void ttm_tt_clear_mapping(struct ttm_tt *ttm)
pgoff_t i;
struct page **page = ttm->pages;
+ if (ttm->page_flags & TTM_PAGE_FLAG_SG)
+ return;
+
for (i = 0; i < ttm->num_pages; ++i) {
(*page)->mapping = NULL;
(*page++)->index = 0;
--
1.7.10.4
[Bug 74469] [opencl] OpenCL fails on Kabini Radeon 8330
https://bugs.freedesktop.org/show_bug.cgi?id=74469 Mike Lothian changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||mike at fireburn.co.uk --- Comment #1 from Mike Lothian --- I can confirm that http://patchwork.freedesktop.org/patch/19386/ fixes this for me -- 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/20140205/074685dc/attachment.html>
[Bug 74511] Increasing EQ - X freezes
https://bugs.freedesktop.org/show_bug.cgi?id=74511 --- Comment #3 from lockheed --- In the other bug the error message in Xorg.log is different even though both relate to EQ. The on-screen symptom is also different, so I though that although they are related, they are not exactly the same. Apologies, if this was incorrect. -- 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/20140205/a10d94a2/attachment.html>
[PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On Tue, 4 Feb 2014 18:06:25 + Mark Brown wrote: > On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote: > > > + /* change the snd_soc_pcm_stream values of the driver */ > > + stream->rates = rate_mask; > > + stream->channels_max = max_channels; > > + stream->formats = formats; > > > + /* copy the DAI driver to a writable area */ > > + dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL); > > + if (!dai_drv) > > + return -ENOMEM; > > + memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai)); > > + > > The code should be doing this by setting constraints based on the > current setup rather than by editing the data structure - the expecation > is very much that the data won't change so this prevents surprises with > future work on the core. As it is done in the soc core, in soc_pcm_open(), the runtime hw_params are initialized after the call to the CODEC startup, and the next CODEC event is hw_params() when the user has already chosen all the parameters. So, in the CODEC, I don't see how I could update the parameters dictated by the EDID otherwise in changing the DAI driver parameters. -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On 02/05/2014 10:11 AM, Jean-Francois Moine wrote: > On Tue, 4 Feb 2014 18:06:25 + > Mark Brown wrote: > >> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote: >> >>> + /* change the snd_soc_pcm_stream values of the driver */ >>> + stream->rates = rate_mask; >>> + stream->channels_max = max_channels; >>> + stream->formats = formats; >> >>> + /* copy the DAI driver to a writable area */ >>> + dai_drv = devm_kzalloc(&pdev->dev, sizeof(tda998x_dai), GFP_KERNEL); >>> + if (!dai_drv) >>> + return -ENOMEM; >>> + memcpy(dai_drv, tda998x_dai, sizeof(tda998x_dai)); >>> + >> >> The code should be doing this by setting constraints based on the >> current setup rather than by editing the data structure - the expecation >> is very much that the data won't change so this prevents surprises with >> future work on the core. > > As it is done in the soc core, in soc_pcm_open(), the runtime hw_params > are initialized after the call to the CODEC startup, and the next CODEC > event is hw_params() when the user has already chosen all the parameters. > > So, in the CODEC, I don't see how I could update the parameters > dictated by the EDID otherwise in changing the DAI driver parameters. > The startup function is the right place. But instead of modifying the DAI use snd_pcm_hw_constraint_mask64(), snd_pcm_hw_constraint_list(), etc. to setup the additional constraints that come from the EDID. Bonus points for making this a generic helper function that takes a runtime and a EDID and then applies the EDID constraints on the runtime. - Lars
[PATCH] MAINTAINERS: Update drm/i915 git repo
On Wed, Feb 05, 2014 at 08:54:15AM +0100, Daniel Vetter wrote: > On Tue, Feb 4, 2014 at 8:37 PM, Daniel Vetter > wrote: > > On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter > > wrote: > >> Moved to a common location so that Jani also can push to it, to avoid > >> moving it every time I go on vacation. Please update autobuilders and > >> everything else pointing at the drm-intel.git repo, the old one won't > >> be updated any more. > >> > >> Cc: Dave Airlie > >> Cc: Jani Nikula > >> Signed-off-by: Daniel Vetter > > > > Also forgotten to cc our QA people ... > > And Wu Fengguang with his 0-day builder also needs to know about the > new git repo! Yeah updated, thank you for the info! Fengguang > -Daniel > > >> --- > >> MAINTAINERS | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index 31a046213274..e3aaf277cf58 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -2832,7 +2832,7 @@ M:Jani Nikula >> linux.intel.com> > >> L: intel-gfx at lists.freedesktop.org > >> L: dri-devel at lists.freedesktop.org > >> Q: http://patchwork.freedesktop.org/project/intel-gfx/ > >> -T: git git://people.freedesktop.org/~danvet/drm-intel > >> +T: git git://anongit.freedesktop.org/drm-intel > >> S: Supported > >> F: drivers/gpu/drm/i915/ > >> F: include/drm/i915* > >> -- > >> 1.8.5.2 > >> > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 74469] [opencl] OpenCL fails on Kabini Radeon 8330
https://bugs.freedesktop.org/show_bug.cgi?id=74469 --- Comment #2 from Michel D?nzer --- Fixed in LLVM SVN r200830. -- 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/20140205/552afc49/attachment-0001.html>
[Bug 69901] intel ivy bridge/radeonsi PRIME hang since 3.14
https://bugzilla.kernel.org/show_bug.cgi?id=69901 --- Comment #7 from Christoph Haag --- Yes it fixes it, no lock ups anymore. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 69901] intel ivy bridge/radeonsi PRIME hang since 3.14
https://bugzilla.kernel.org/show_bug.cgi?id=69901 --- Comment #8 from Thomas Hellstrom --- Great. I'll include the patch in my next pull request. -- You are receiving this mail because: You are watching the assignee of the bug.
drm/radeon: add support mc ucode loading on CIK (v2)
Hello Alex Deucher,
The patch bc8273fe9701: "drm/radeon: add support mc ucode loading on
CIK (v2)" from Jun 29, 2012, leads to the following static checker
warning:
drivers/gpu/drm/radeon/cik.c:1728 ci_mc_load_microcode()
warn: we tested 'running' before and it was 'false'
drivers/gpu/drm/radeon/cik.c
1727 if (running == 0) {
1728 if (running) {
^^^
Never true condition.
1729 blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
1730 WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
1731 }
1732
1733 /* reset the engine and set to writable */
1734 WREG32(MC_SEQ_SUP_CNTL, 0x0008);
1735 WREG32(MC_SEQ_SUP_CNTL, 0x0010);
1736
1737 /* load mc io regs */
1738 for (i = 0; i < regs_size; i++) {
1739 WREG32(MC_SEQ_IO_DEBUG_INDEX, io_mc_regs[(i <<
1)]);
1740 WREG32(MC_SEQ_IO_DEBUG_DATA, io_mc_regs[(i <<
1) + 1]);
1741 }
1742 /* load the MC ucode */
1743 fw_data = (const __be32 *)rdev->mc_fw->data;
1744 for (i = 0; i < ucode_size; i++)
1745 WREG32(MC_SEQ_SUP_PGM, be32_to_cpup(fw_data++));
1746
1747 /* put the engine back into the active state */
1748 WREG32(MC_SEQ_SUP_CNTL, 0x0008);
1749 WREG32(MC_SEQ_SUP_CNTL, 0x0004);
1750 WREG32(MC_SEQ_SUP_CNTL, 0x0001);
1751
1752 /* wait for training to complete */
1753 for (i = 0; i < rdev->usec_timeout; i++) {
1754 if (RREG32(MC_SEQ_TRAIN_WAKEUP_CNTL) &
TRAIN_DONE_D0)
1755 break;
1756 udelay(1);
1757 }
1758 for (i = 0; i < rdev->usec_timeout; i++) {
1759 if (RREG32(MC_SEQ_TRAIN_WAKEUP_CNTL) &
TRAIN_DONE_D1)
1760 break;
1761 udelay(1);
1762 }
1763
1764 if (running)
^^^
Same.
1765 WREG32(MC_SHARED_BLACKOUT_CNTL, blackout);
1766 }
regards,
dan carpenter
drm/radeon/kms: add ucode loader for NI
Hello Alex Deucher,
The patch 0af62b016804: "drm/radeon/kms: add ucode loader for NI"
from Jan 6, 2011, leads to the following static checker warning:
drivers/gpu/drm/radeon/ni.c:646 ni_mc_load_microcode()
warn: we tested 'running' before and it was 'false'
drivers/gpu/drm/radeon/ni.c
643 running = RREG32(MC_SEQ_SUP_CNTL) & RUN_MASK;
644
645 if ((mem_type == MC_SEQ_MISC0_GDDR5_VALUE) && (running == 0)) {
646 if (running) {
^^^
Never true condition.
647 blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
648 WREG32(MC_SHARED_BLACKOUT_CNTL, 1);
649 }
650
651 /* reset the engine and set to writable */
652 WREG32(MC_SEQ_SUP_CNTL, 0x0008);
653 WREG32(MC_SEQ_SUP_CNTL, 0x0010);
654
655 /* load mc io regs */
656 for (i = 0; i < regs_size; i++) {
657 WREG32(MC_SEQ_IO_DEBUG_INDEX, io_mc_regs[(i <<
1)]);
658 WREG32(MC_SEQ_IO_DEBUG_DATA, io_mc_regs[(i <<
1) + 1]);
659 }
660 /* load the MC ucode */
661 fw_data = (const __be32 *)rdev->mc_fw->data;
662 for (i = 0; i < ucode_size; i++)
663 WREG32(MC_SEQ_SUP_PGM, be32_to_cpup(fw_data++));
664
665 /* put the engine back into the active state */
666 WREG32(MC_SEQ_SUP_CNTL, 0x0008);
667 WREG32(MC_SEQ_SUP_CNTL, 0x0004);
668 WREG32(MC_SEQ_SUP_CNTL, 0x0001);
669
670 /* wait for training to complete */
671 for (i = 0; i < rdev->usec_timeout; i++) {
672 if (RREG32(MC_IO_PAD_CNTL_D0) &
MEM_FALL_OUT_CMD)
673 break;
674 udelay(1);
675 }
676
677 if (running)
^^^
Again.
678 WREG32(MC_SHARED_BLACKOUT_CNTL, blackout);
679 }
regards,
dan carpenter
drm/radeon/kms: add support for MC ucode loading on SI
Hello Alex Deucher,
The patch 8b074dd64053: "drm/radeon/kms: add support for MC ucode
loading on SI" from Mar 20, 2012, leads to the following static
checker warning:
drivers/gpu/drm/radeon/si.c:1507 si_mc_load_microcode()
warn: we tested 'running' before and it was 'false'
drivers/gpu/drm/radeon/si.c
1506 if (running == 0) {
1507 if (running) {
^^^
Nope.
1508 blackout = RREG32(MC_SHARED_BLACKOUT_CNTL);
1509 WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1);
1510 }
1511
1512 /* reset the engine and set to writable */
1513 WREG32(MC_SEQ_SUP_CNTL, 0x0008);
1514 WREG32(MC_SEQ_SUP_CNTL, 0x0010);
1515
1516 /* load mc io regs */
1517 for (i = 0; i < regs_size; i++) {
1518 WREG32(MC_SEQ_IO_DEBUG_INDEX, io_mc_regs[(i <<
1)]);
1519 WREG32(MC_SEQ_IO_DEBUG_DATA, io_mc_regs[(i <<
1) + 1]);
1520 }
1521 /* load the MC ucode */
1522 fw_data = (const __be32 *)rdev->mc_fw->data;
1523 for (i = 0; i < ucode_size; i++)
1524 WREG32(MC_SEQ_SUP_PGM, be32_to_cpup(fw_data++));
1525
1526 /* put the engine back into the active state */
1527 WREG32(MC_SEQ_SUP_CNTL, 0x0008);
1528 WREG32(MC_SEQ_SUP_CNTL, 0x0004);
1529 WREG32(MC_SEQ_SUP_CNTL, 0x0001);
1530
1531 /* wait for training to complete */
1532 for (i = 0; i < rdev->usec_timeout; i++) {
1533 if (RREG32(MC_SEQ_TRAIN_WAKEUP_CNTL) &
TRAIN_DONE_D0)
1534 break;
1535 udelay(1);
1536 }
1537 for (i = 0; i < rdev->usec_timeout; i++) {
1538 if (RREG32(MC_SEQ_TRAIN_WAKEUP_CNTL) &
TRAIN_DONE_D1)
1539 break;
1540 udelay(1);
1541 }
1542
1543 if (running)
^^^
False.
1544 WREG32(MC_SHARED_BLACKOUT_CNTL, blackout);
1545 }
regards,
dan carpenter
[alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On 02/05/2014 12:18 PM, Mark Brown wrote: > On Wed, Feb 05, 2014 at 10:19:22AM +0100, Lars-Peter Clausen wrote: [..] >> Bonus points for making this a generic helper function that takes a >> runtime and a EDID and then applies the EDID constraints on the >> runtime. > > ...as previously requested. I know there was some discusion of broader > moves to factor this stuff out but it'd still be good to keep it > separated out even prior to a final non-EDID based solution so it's > easier to refactor. I think it will always be EDID (or ELD) based. As I understood it the re-factoring Takashi was talking about is related to how this data is passed from the graphics driver to the audio driver. The way things work right now in HDA land is that the graphics driver reads the EDID from the monitor, converts it to ELD and writes it to a special memory region in the graphics controller. This generates an interrupt in the audio driver and the audio driver reads the ELD from the hardware and sets up the constraints based on that. And I think that the plan is to change this to pass the EDID directly from the graphics driver to the audio driver without taking the detour through the hardware. This is what we'll need for embedded systems anyway. A system that allows to associate a sound driver with a specific HDMI port and status updates for that port, e.g. new EDID or cable connected/disconnected are passed from the graphics driver handling that port to the audio driver. - Lars
[PULL vmwgfx-fixes-3.14]
Dave, A couple of vmwgfx fixes together with missing bits of legacy device emulation to facilitate old user-space drivers on new devices. The shader emulation bits are a bit large, but since they mostly touch the new device code, regressions are unlikely. I figure the gain of having this from the start clearly outweighs the risc of adding these bits at this point. /Thomas The following changes since commit ef64cf9d06049e4e9df661f3be60b217e476bee1: Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-01-30 10:46:06 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux tags/vmwgfx-fixes-3.14-2014-02-05 for you to fetch changes up to cd9a21a831af0af7539a0e37e4455da03df7cf82: vmwgfx: Fix unitialized stack read in vmw_setup_otable_base (2014-02-05 08:52:34 +0100) Pull request of 2014-02-05 Dave Jones (1): vmwgfx: Fix unitialized stack read in vmw_setup_otable_base Thomas Hellstrom (7): drm/vmwgfx: Don't commit staged bindings if execbuf fails drm/vmwgfx: Fix regression caused by "drm/ttm: make ttm reservation calls behave like reservation calls" drm/vmwgfx: Fix SET_SHADER_CONST emulation on guest-backed devices drm/vmwgfx: Fix legacy surface reference size copyback drm/vmwgfx: Emulate legacy shaders on guest-backed devices v2 drm/vmwgfx: Detect old user-space drivers and set up legacy emulation v2 drm/vmwgfx: Reemit context bindings when necessary v2 drivers/gpu/drm/vmwgfx/svga3d_reg.h | 24 ++ drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 144 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |7 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 35 ++- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 330 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c| 93 +- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |1 + drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 11 +- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 467 ++ drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |6 +- 10 files changed, 988 insertions(+), 130 deletions(-)
[PATCH] drm/ttm: Don't clear page metadata of imported sg pages
- Ursprungligt meddelande -
> These page pointers shouldn't be visible to TTM in the first place, but
> until we fix that up, don't clear the page metadata because that
> will upset the exporter.
>
> Reported-by: Cristoph Haag
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_tt.c |3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Jakob Bornecrantz
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 9af9908..75f3190 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -380,6 +380,9 @@ static void ttm_tt_clear_mapping(struct ttm_tt *ttm)
> pgoff_t i;
> struct page **page = ttm->pages;
>
> + if (ttm->page_flags & TTM_PAGE_FLAG_SG)
> + return;
> +
> for (i = 0; i < ttm->num_pages; ++i) {
> (*page)->mapping = NULL;
> (*page++)->index = 0;
> --
> 1.7.10.4
>
[PULL] ttm-fixes-3.14
Dave, Two fixes for TTM regressions in 3.14-rc1 The following changes since commit 76f4f415e502e4dfaf409edd0d4ed0dd3a0a0419: Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-01-23 13:50:54 +1000) are available in the git repository at: git://people.freedesktop.org/~thomash/linux tags/ttm-fixes-3.14-2014-02-05 for you to fetch changes up to 1b76af5ce8deb1c775ad1674bd249d782b5b13d9: drm/ttm: Don't clear page metadata of imported sg pages (2014-02-05 16:03:29 +0100) Pull request of 2014-02-05 Thomas Hellstrom (2): drm/ttm: Fix TTM object open regression drm/ttm: Don't clear page metadata of imported sg pages drivers/gpu/drm/ttm/ttm_object.c |2 +- drivers/gpu/drm/ttm/ttm_tt.c |3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #61 from Pali Roh?r --- Hi Tom Stellard! Now I updated kernel to 3.13, drm from git, radeon x driver from git and mesa from git with above patch. And patch really fixed problem with glamor rendering :-) Here is output from glxgears $ glxgears Default raster_config = 0x124a rb mask = 10 Final raster_config = 0x124f Default raster_config = 0x124a rb mask = 10 Final raster_config = 0x124f Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 270 frames in 5.0 seconds = 53.990 FPS ^C Tested also with 3.14-rc1 kernel and still working. But with old kernels (3.11) there is same problem and not working. -- 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/20140205/7dd30e80/attachment.html>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 --- Comment #5 from lockheed --- Created attachment 93454 --> https://bugs.freedesktop.org/attachment.cgi?id=93454&action=edit dmesg Here is dmesg directly after crash. Does that help? -- 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/20140205/e22698a9/attachment.html>
[Bug 70706] Regression in fbconfig
https://bugs.freedesktop.org/show_bug.cgi?id=70706 --- Comment #17 from Eugene Shalygin --- In my case "Module" section is empty and I have the issue. X.Org X Server 1.15.0 xf86-vide0-ati, module version = 7.3.99 Mesa 10.1.0-devel (git-023a50d), r600g driver -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140205/7278818e/attachment.html>
[alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On Wed, 05 Feb 2014 10:19:22 +0100 Lars-Peter Clausen wrote: > > So, in the CODEC, I don't see how I could update the parameters > > dictated by the EDID otherwise in changing the DAI driver parameters. > > > > The startup function is the right place. But instead of modifying the DAI > use snd_pcm_hw_constraint_mask64(), snd_pcm_hw_constraint_list(), etc. to > setup the additional constraints that come from the EDID. It is more complicated, but it works. Nevertheless, I have 2 problems: - snd_pcm_hw_constraint_list() keeps a pointer to the list, so, it cannot be in the stack. It fix this with static struct and rate array. - snd_pcm_hw_constraint_mask64() is not exported. Is there an other way to set constraints on the formats/sample widths? -- Ken ar c'henta? | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On 02/05/2014 07:07 PM, Jean-Francois Moine wrote:
> On Wed, 05 Feb 2014 10:19:22 +0100
> Lars-Peter Clausen wrote:
>
>>> So, in the CODEC, I don't see how I could update the parameters
>>> dictated by the EDID otherwise in changing the DAI driver parameters.
>>>
>>
>> The startup function is the right place. But instead of modifying the DAI
>> use snd_pcm_hw_constraint_mask64(), snd_pcm_hw_constraint_list(), etc. to
>> setup the additional constraints that come from the EDID.
>
> It is more complicated, but it works. Nevertheless, I have 2 problems:
>
> - snd_pcm_hw_constraint_list() keeps a pointer to the list, so, it
>cannot be in the stack. It fix this with static struct and rate array.
>
Right. If the struct is modified though it should be per device and not
global. I think the best way to implement this is to make the array static
and specify a mask for the constraint based on the EDID. E.g.
static unsigned int hdmi_rates[] = {
32000,
44100,
48000,
88200,
96000,
176400,
192000,
};
rate_mask = 0;
while (...) {
...
rate_mask |= 1 << sad[1];
}
rate_constraints->list = hdmi_rates;
rate_constraints->count = ARRAY_SIZE(hdmi_rates);
rate_constraints->mask = rate_mask;
> - snd_pcm_hw_constraint_mask64() is not exported.
>Is there an other way to set constraints on the formats/sample widths?
I think that's a bug. Both snd_pcm_hw_constraint_mask() and
snd_pcm_hw_constraint_mask64() should be exported. Can you send a patch?
- Lars
[PATCH 1/3] drm/nv4c/mc: nv4x igp's have a different msi rearm register
See https://bugs.freedesktop.org/show_bug.cgi?id=74492
Reported-by: Ronald
Suggested-by: Marcin Ko?cielnicki
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/device/nv40.c | 10 ++---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/nv04.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/nv44.c | 2 +-
drivers/gpu/drm/nouveau/core/subdev/mc/nv4c.c | 45 +++
6 files changed, 54 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/core/subdev/mc/nv4c.c
diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile
index e88145b..d310c19 100644
--- a/drivers/gpu/drm/nouveau/Makefile
+++ b/drivers/gpu/drm/nouveau/Makefile
@@ -141,6 +141,7 @@ nouveau-y += core/subdev/mc/base.o
nouveau-y += core/subdev/mc/nv04.o
nouveau-y += core/subdev/mc/nv40.o
nouveau-y += core/subdev/mc/nv44.o
+nouveau-y += core/subdev/mc/nv4c.o
nouveau-y += core/subdev/mc/nv50.o
nouveau-y += core/subdev/mc/nv94.o
nouveau-y += core/subdev/mc/nv98.o
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
b/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
index 1b653dd..08b8859 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/nv40.c
@@ -311,7 +311,7 @@ nv40_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nv40_clock_oclass;
device->oclass[NVDEV_SUBDEV_THERM ] = &nv40_therm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device->oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device->oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device->oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass;
device->oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
@@ -334,7 +334,7 @@ nv40_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nv40_clock_oclass;
device->oclass[NVDEV_SUBDEV_THERM ] = &nv40_therm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device->oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device->oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device->oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass;
device->oclass[NVDEV_SUBDEV_FB ] = nv4e_fb_oclass;
@@ -357,7 +357,7 @@ nv40_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nv40_clock_oclass;
device->oclass[NVDEV_SUBDEV_THERM ] = &nv40_therm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device->oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device->oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device->oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass;
device->oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
@@ -380,7 +380,7 @@ nv40_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nv40_clock_oclass;
device->oclass[NVDEV_SUBDEV_THERM ] = &nv40_therm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device->oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device->oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device->oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass;
device->oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
@@ -403,7 +403,7 @@ nv40_identify(struct nouveau_device *device)
device->oclass[NVDEV_SUBDEV_CLOCK ] = &nv40_clock_oclass;
device->oclass[NVDEV_SUBDEV_THERM ] = &nv40_therm_oclass;
device->oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass;
- device->oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass;
+ device->oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass;
device->oclass[NVDEV_SUBDEV_BUS] = nv31_bus_oclass;
device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass;
device->oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass;
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index adc88b7..3c6738e 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -47,6 +47,7 @@ struct nouveau_mc_oclass {
extern struct nouveau_oclass
[PATCH 2/3] drm/nv4c/vga: decode register is in a different place on nv4x igp's
Suggested-by: Marcin Ko?cielnicki
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 81638d7..471347e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -14,7 +14,9 @@ nouveau_vga_set_decode(void *priv, bool state)
{
struct nouveau_device *device = nouveau_dev(priv);
- if (device->chipset >= 0x40)
+ if (device->card_type == NV_40 && device->chipset >= 0x4c)
+ nv_wr32(device, 0x088060, state);
+ else if (device->chipset >= 0x40)
nv_wr32(device, 0x088054, state);
else
nv_wr32(device, 0x001854, state);
--
1.8.3.2
[PATCH 3/3] drm/nv4c/bios: disallow retrieving from prom on nv4x igp's
Suggested-by: Marcin Ko?cielnicki Signed-off-by: Ilia Mirkin --- drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c index aa0fbbe..ef0c9c4 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/base.c @@ -130,6 +130,10 @@ nouveau_bios_shadow_prom(struct nouveau_bios *bios) u16 pcir; int i; + /* there is no prom on nv4x IGP's */ + if (device->card_type == NV_40 && device->chipset >= 0x4c) + return; + /* enable access to rom */ if (device->card_type >= NV_50) pcireg = 0x088050; -- 1.8.3.2
[RFC 10/16] drm/nouveau/timer: skip calibration on GK20A
On 02/04/2014 01:39 AM, Alexandre Courbot wrote: > On 02/04/2014 12:55 PM, Ben Skeggs wrote: >> On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot >> wrote: >>> GK20A's timer is directly attached to the system timer and cannot be >>> calibrated. Skip the calibration phase on that chip since the >>> corresponding registers do not exist. >> Just a curiosity: What timer resolution does the HW initialise at? > > On T124 the timer input is the oscillator clock, which depending on the > device can run between 12 and 48Mhz (IIUC). On the one Tegra124 board we support upstream, the crystal is 12MHz. I believe this is a typical/common value; almost all the Tegra boards we support upstream run at this rate.
[Bug 68527] Planetary Annihilation Alpha: translation from TGSI failed !
https://bugs.freedesktop.org/show_bug.cgi?id=68527 --- Comment #17 from sxx.public at yahoo.com --- Small update on my issue. In latest version of Mesa this shader don't cause GPU lockup anymore, but retried of shader compilation didn't stop so my console got spammed with tons same errors: EE ../../../../../../src/gallium/drivers/r600/r600_shader.c:157 r600_pipe_shader_create - translation from TGSI failed ! EE ../../../../../../src/gallium/drivers/r600/r600_state_common.c:745 r600_shader_select - Failed to build shader variant (type=1) -1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140205/f073336a/attachment.html>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 --- Comment #6 from lockheed --- >>>>> Does the problem also occur without Option "EXAVSync"? If anything, turning it off makes it worse. With it, I get the crash anywhere between few hours, to 2 days. Without it, it crashed in less than an hour. -- 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/20140205/701562cd/attachment.html>
[PATCH v2 1/6] drm/udl: fix error-path when damage-req fails
ping..
On Thu, Jan 23, 2014 at 1:48 PM, David Herrmann
wrote:
> We need to call dma_buf_end_cpu_access() in case a damage-request.
> Unlikely, but might happen during device unplug.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/udl/udl_fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index dbadd49..3771763 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -421,7 +421,7 @@ 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;
> + break;
> }
>
> if (ufb->obj->base.import_attach) {
> --
> 1.8.5.3
>
[PATCH v2 2/6] drm/udl: fix Bpp calculation in dumb_create()
ping..
On Thu, Jan 23, 2014 at 1:50 PM, David Herrmann
wrote:
> 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.
> Use DIV_ROUND_UP() to avoid the problem entirely and make the core more
> readable.
>
> Reviewed-by: Daniel Vetter
> 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..be4fcd0 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 * DIV_ROUND_UP(args->bpp, 8);
> args->size = args->pitch * args->height;
> return udl_gem_create(file, dev,
> args->size, &args->handle);
> --
> 1.8.5.3
>
[PATCH 4/7] drm/gem: fix indentation
ping On Mon, Jan 20, 2014 at 8:26 PM, David Herrmann wrote: > 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
ping On Mon, Jan 20, 2014 at 8:26 PM, David Herrmann wrote: > 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 v2 5/6] drm/crtc: add sanity checks to create_dumb()
ping
On Thu, Jan 23, 2014 at 3:10 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Jan 23, 2014 at 2:55 PM, Ville Syrj?l?
> wrote:
>> On Thu, Jan 23, 2014 at 01:53:15PM +0100, David Herrmann wrote:
>>> 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?).
>>>
>>> Reviewed-by: Daniel Vetter
>>> Signed-off-by: David Herrmann
>>> ---
>>> drivers/gpu/drm/drm_crtc.c | 17 +
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 266a01d..2b50702 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -3738,9 +3738,26 @@ 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 cpp, stride, size;
>>>
>>> if (!dev->driver->dumb_create)
>>> return -ENOSYS;
>>> + if (!args->width || !args->height || !args->bpp)
>>> + return -EINVAL;
>>> +
>>> + /* overflow checks for 32bit size calculations */
>>> + cpp = DIV_ROUND_UP(args->bpp, 8);
>>> + if (cpp > 0xU / args->width)
>>> + return -EINVAL;
>>
>> IIRC I used -ERANGE for such things in some drm_framebuffer checks. Not
>> sure if that's the best error value or not, but using the same one in
>> both places would be nice.
>
> I'm actually a fan of EINVAL here, as this is really more about "do
> the arguments make sense?" than "does the range exceed the driver's
> capabilities?" But what do I know.. So more comments on that are
> welcome. And btw., we already mix EINVAL and ERANGE so this would just
> contribute to the already existing mess (see the stride verifications
> which usually return EINVAL, but the overflow checks often return
> ERANGE).
>
> Thanks
> David
>
>>> + stride = cpp * args->width;
>>> + if (args->height > 0xU / stride)
>>> + return -EINVAL;
>>> +
>>> + /* test for wrap-around */
>>> + size = args->height * stride;
>>> + if (PAGE_ALIGN(size) == 0)
>>> + return -EINVAL;
>>> +
>>> return dev->driver->dumb_create(file_priv, dev, args);
>>> }
>>>
>>> --
>>> 1.8.5.3
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>> Ville Syrj?l?
>> Intel OTC
[PATCH 7/7] drm/gem: dont init "ret" in drm_gem_mmap()
ping On Tue, Jan 21, 2014 at 10:51 AM, Daniel Vetter wrote: > On Mon, Jan 20, 2014 at 08:26:29PM +0100, David Herrmann wrote: >> 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 > > I've replied with a few small comments on some patches, with those > addressed all but patch 3 are > > Reviewed-by: Daniel Vetter > > A follow-up to 4 to remove callsites from drivers would be neat though. > -Daniel > >> --- >> 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 >> > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 31230] [RADEON:KMS:RV250:RESUME] corrupted screen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=31230 --- Comment #3 from dplasa --- Bug is still present up to current kernels (I tested up to 3.11 in ubuntu 13.10) - the screen is corrupted after a resume from pm-suspend (suspend to ram). Corrupt means: the screen content appears approx. 3 times over the screen. (Sort of like three tiles). Also the VT is trashed, I see 3 login prompts :) However the screen is ok/fixed after I do a pm-hibernate (suspend to disk) and resume from it. When I used "nomodeset" and let the xorg driver do the mode setting stuff everything worked fine. Unfortunatly the recent xorg drivers have lost their capability to do their own modeset and now I'm stuck with KMS. -- 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/20140205/5e359ccc/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #62 from Tom Stellard --- (In reply to comment #61) > Hi Tom Stellard! > > Now I updated kernel to 3.13, drm from git, radeon x driver from git and > mesa from git with above patch. And patch really fixed problem with glamor > rendering :-) > > Here is output from glxgears > > $ glxgears > Default raster_config = 0x124a > rb mask = 10 > Final raster_config = 0x124f > Default raster_config = 0x124a > rb mask = 10 > Final raster_config = 0x124f > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate. > 270 frames in 5.0 seconds = 53.990 FPS > ^C > > Tested also with 3.14-rc1 kernel and still working. But with old kernels > (3.11) there is same problem and not working. Older kernels don't provide an interface to query the enabled backends. It should work with 3.12.x and newer. -- 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/20140205/b4e9c998/attachment.html>
[alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On Wed, Feb 05, 2014 at 10:19:22AM +0100, Lars-Peter Clausen wrote: > On 02/05/2014 10:11 AM, Jean-Francois Moine wrote: > >So, in the CODEC, I don't see how I could update the parameters > >dictated by the EDID otherwise in changing the DAI driver parameters. > The startup function is the right place. But instead of modifying > the DAI use snd_pcm_hw_constraint_mask64(), > snd_pcm_hw_constraint_list(), etc. to setup the additional > constraints that come from the EDID. Right. > Bonus points for making this a generic helper function that takes a > runtime and a EDID and then applies the EDID constraints on the > runtime. ...as previously requested. I know there was some discusion of broader moves to factor this stuff out but it'd still be good to keep it separated out even prior to a final non-EDID based solution so it's easier to refactor. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140205/f91a9e51/attachment.pgp>
[PATCH] drm/nouveau/hwmon: replace strict_strtol() with kstrtol()
The usage of strict_strtol() is not preferred, because strict_strtol() is obsolete. Thus, kstrtol() should be used. Signed-off-by: Jingoo Han --- drivers/gpu/drm/nouveau/nouveau_hwmon.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c b/drivers/gpu/drm/nouveau/nouveau_hwmon.c index 4aff04f..34ad3fa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c @@ -383,8 +383,9 @@ nouveau_hwmon_set_pwm1_enable(struct device *d, struct device_attribute *a, long value; int ret; - if (strict_strtol(buf, 10, &value) == -EINVAL) - return -EINVAL; + ret = kstrtol(buf, 10, &value); + if (ret) + return ret; ret = therm->attr_set(therm, NOUVEAU_THERM_ATTR_FAN_MODE, value); if (ret) -- 1.7.10.4
[3.14-rc1] cirrus driver problem (qemu)
2014-02-05, 14:50:18 +1000, Dave Airlie wrote: > On Wed, Feb 5, 2014 at 8:53 AM, Sabrina Dubroca wrote: > > 2014-02-04, 13:20:54 +1000, Dave Airlie wrote: > >> On Tue, Feb 4, 2014 at 1:34 AM, Sabrina Dubroca > >> wrote: > >> > When I boot 3.14-rc1 in qemu, I get the trace below. The console stops > >> > updating and I don't get a login prompt. I can login, but I can't see > >> > what I'm doing. I can login normally via SSH. > >> > > >> > If I revert the last commit in drivers/gpu/drm/cirrus: > >> > > >> > f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 drm: ast,cirrus,mgag200: use > >> > drm_can_sleep > >> > > >> > the problem is solved. > >> > > >> > >> Hi does the attach patch fix it? > >> > >> Dave. > > > > > > Same problem. Didn't you reverse the logic on in_interrupt, compared > > to the old "if (!in_interrupt())" ? It looks like drm_can_sleep() is > > false when in_interrupt() is true. > > > > I modified your patch as below. Display doesn't freeze, but I still > > get the warning. > > Oh wow I totally screwed up there, you are right, logic inversion. > > Can you try the attached? > > without the in_interrupt addition. > > Dave. It works, thanks! No freeze, no warning. Sabrina
[alsa-devel] [PATCH v3 4/5] ASoC: tda998x: adjust the audio hw parameters from EDID
On Wed, Feb 05, 2014 at 02:31:09PM +0100, Lars-Peter Clausen wrote: > On 02/05/2014 12:18 PM, Mark Brown wrote: > >...as previously requested. I know there was some discusion of broader > >moves to factor this stuff out but it'd still be good to keep it > >separated out even prior to a final non-EDID based solution so it's > >easier to refactor. > I think it will always be EDID (or ELD) based. As I understood it > the re-factoring Takashi was talking about is related to how this > data is passed from the graphics driver to the audio driver. The way Right, the data of course has to come from there originally, it's about how we pass the data and updates to it around. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140205/5244a05d/attachment-0001.pgp>
