Re: [PATCH 0/5] Add TTM functionality and drm exports for vmwgfx
On Mon, Dec 7, 2009 at 6:46 AM, Thomas Hellstrom thellst...@vmware.com wrote: This patch series adds TTM functionality and a couple of drm exports needed by the vmwgfx drm driver. The patch adding the vmwgfx driver itself will be posted later. The current driver source is available at git://git.freedesktop.org/git/mesa/vmwgfx Applied all of these to drm-core-next, Thanks, Dave. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm/ttm: Rework validation memory space allocation
Jerome Glisse wrote:
On Sat, Dec 05, 2009 at 11:30:38PM +0100, Thomas Hellström wrote:
Jerome Glisse wrote:
On Sat, Dec 05, 2009 at 01:14:29PM +0100, Thomas Hellström wrote:
Jerome,
I'm just reviewing the API change here. I'll do a more thorough
code review when the API is agreed upon.
+
+/**
+ * struct ttm_placement
+ *
+ * @fpfn:first valid page frame number to put the object
+ * @lpfn:last valid page frame number to put the object
+ * @placements: prefered placements, 4bits per placement,
+ * first 4 bits are the the number of placement
+ * @busy_placements: prefered placements when need to evict,
+ * 4bits per placement, first 4 bits are the the number of placement
+ * @flags: Additional placement flags
+ *
+ * Structure indicating the placement you request for an object.
+ */
+struct ttm_placement {
+ unsignedfpfn;
+ unsignedlpfn;
+ u64 placements;
+ u32 flags;
+};
+
The names fpfn and lpfn are a bit misleading, since the pfn can
be confused with kernel pfns. These are really page offsets into
the managed area? At least this confused me a bit.
For @placements and @busy_placements, I take it you encode both
the possible placements and the priority order (although you
leave out the @busy_placements in the struct. I think
@busy_placements are needed, though. Consider a situation where
you want to place a texture in vram, but if that causes a
pipeline stall due to VRAM eviction, rather place it in AGP.
I dislike the coding of all this information in a single member,
also I think one should distinguish between allowable placement
and priority. The validation code may want to alter priority,
which is not easily done in current TTM, and core TTM basically
only wants to be able to move objects out to cached or uncached
system memory.
What about
struct ttm_placement {
unsigned long fpfn;
unsigned long lpfn;
const u64 *placements; //Encoded the traditional way
unsigned num_placements;
const u64 *busy_placements;
unsigned num_busy_placements;
}
I removed busy placement, i think giving placement preference is enough.
Obviously at least OpenChrome is using that functionality.
A typical use-case where this isn't enough is where you have a
texture that's preferrably
placed in VRAM but it may also be placed in TT. If both these are
unavailable,
you'd like to start evicting from TT, because that's done in an
instant, compared to PCI DMA from
VRAM which is at 60MB/s on some chipsets.
If you look at code you can see that ttm will try with first placement,
than second, ... My change allow to change the priority as you provide
one with each validation.
Yes. Allowing to change the priority for each validation is a thing
that's missing, and I'd like to see
that functionality go in.
For instance if you prefer a bo in vram and only allow vram :
placements = (VRAM 4) | 1
If you prefere bo in VRAM but the bo can also be in TT :
placements = (VRAM 4) | (TT 8) | 2
If you prefer bo in TT but can also be in vram :
placements = (TT 4) | (VRAM 8) | 2
I would like to avoid having pointer, using a quadword seems enought
to fit all need i can think of (15 different placement). So my
change is all about allowing driver to alter priority for each
validation.
Packing the information in a quadword is also very ugly, and makes
the unpacking code
hard to follow. In the typical case, either the driver decides
placement based on previous usage history,
and in that case only one placement would be given. Or the legacy
case where a
driver uses a static array for priorities. Hence a pointer to an
array is IMHO the obvious choice.
On the avoiding eviction thing, the plan i was thinking of is mostly
to let the driver come up with an heuristic to decide when to put
a bo in vram or not. This would mean driver won't set vram as first
priority placement if the driver don't think it's worth evicting
other bo for it. Thought adding busy might be a good idea, i can
understand that it could be usefull.
One thing that should be considered if you want to implement an
advanced heuristic in the driver,
is to add a bool to the validate function that stops it from
evicting. In that case the driver could
do that itself, and implement whatever strategy it likes.
Ok so i will switch to array and add back busy stuff. I think to allow
driver to decide what to do if eviction is needed is as simple as driver
supplying empty busy placements this would lead to validate returning
-ENOMEM then driver can do whatever it thinks is best.
Yes, that seems like a good solution.
For radeon my plan is to have a function to mess with the lru list
in order to try to sort a bit what we want to evict, i might do that
[PATCH 2/3] drm/ttm: Rework validation memory space allocation (V2)
This change allow driver to pass sorted memory placement,
from most prefered placement to least prefered placement.
In order to avoid long function prototype a structure is
used to gather memory placement informations such as range
restriction (if you need a buffer to be in given range).
Range restriction is determined by fpfn lpfn which are
the first page and last page number btw which allocation
can happen. If those fields are set to 0 ttm will assume
buffer can be put anywhere in the address space (thus it
avoids putting a burden on the driver to always properly
set those fields).
This patch also factor few functions like evicting first
entry of lru list or getting a memory space. This avoid
code duplication.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 443 ++-
include/drm/ttm/ttm_bo_api.h| 42 +++-
include/drm/ttm/ttm_bo_driver.h | 20 +--
3 files changed, 236 insertions(+), 269 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 87c0625..5ffb44f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -27,6 +27,14 @@
/*
* Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
*/
+/* Notes:
+ *
+ * We store bo pointer in drm_mm_node struct so we know which bo own a
+ * specific node. There is no protection on the pointer, thus to make
+ * sure things don't go berserk you have to access this pointer while
+ * holding the global lru lock and make sure anytime you free a node you
+ * reset the pointer to NULL.
+ */
#include ttm/ttm_module.h
#include ttm/ttm_bo_driver.h
@@ -247,7 +255,6 @@ EXPORT_SYMBOL(ttm_bo_unreserve);
/*
* Call bo-mutex locked.
*/
-
static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
{
struct ttm_bo_device *bdev = bo-bdev;
@@ -328,14 +335,8 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
if (bo-mem.mem_type == TTM_PL_SYSTEM) {
-
- struct ttm_mem_reg *old_mem = bo-mem;
- uint32_t save_flags = old_mem-placement;
-
- *old_mem = *mem;
+ bo-mem = *mem;
mem-mm_node = NULL;
- ttm_flag_masked(save_flags, mem-placement,
- TTM_PL_MASK_MEMTYPE);
goto moved;
}
@@ -418,6 +419,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
kref_put(bo-list_kref, ttm_bo_ref_bug);
}
if (bo-mem.mm_node) {
+ bo-mem.mm_node-private = NULL;
drm_mm_put_block(bo-mem.mm_node);
bo-mem.mm_node = NULL;
}
@@ -554,17 +556,14 @@ void ttm_bo_unref(struct ttm_buffer_object **p_bo)
}
EXPORT_SYMBOL(ttm_bo_unref);
-static int ttm_bo_evict(struct ttm_buffer_object *bo, unsigned mem_type,
- bool interruptible, bool no_wait)
+static int ttm_bo_evict(struct ttm_buffer_object *bo, bool interruptible,
+ bool no_wait)
{
- int ret = 0;
struct ttm_bo_device *bdev = bo-bdev;
struct ttm_bo_global *glob = bo-glob;
struct ttm_mem_reg evict_mem;
- uint32_t proposed_placement;
-
- if (bo-mem.mem_type != mem_type)
- goto out;
+ struct ttm_placement placement;
+ int ret = 0;
spin_lock(bo-lock);
ret = ttm_bo_wait(bo, false, interruptible, no_wait);
@@ -584,14 +583,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
unsigned mem_type,
evict_mem = bo-mem;
evict_mem.mm_node = NULL;
- proposed_placement = bdev-driver-evict_flags(bo);
-
- ret = ttm_bo_mem_space(bo, proposed_placement,
- evict_mem, interruptible, no_wait);
- if (unlikely(ret != 0 ret != -ERESTART))
- ret = ttm_bo_mem_space(bo, TTM_PL_FLAG_SYSTEM,
- evict_mem, interruptible, no_wait);
-
+ bdev-driver-evict_flags(bo, placement);
+ ret = ttm_bo_mem_space(bo, placement, evict_mem, interruptible,
+ no_wait);
if (ret) {
if (ret != -ERESTART)
printk(KERN_ERR TTM_PFX
@@ -605,95 +599,117 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
unsigned mem_type,
if (ret) {
if (ret != -ERESTART)
printk(KERN_ERR TTM_PFX Buffer eviction failed\n);
+ spin_lock(glob-lru_lock);
+ if (evict_mem.mm_node) {
+ evict_mem.mm_node-private = NULL;
+ drm_mm_put_block(evict_mem.mm_node);
+ evict_mem.mm_node = NULL;
+ }
+ spin_unlock(glob-lru_lock);
goto
[PATCH 3/3] drm/radeon/kms: Convert radeon to new TTM validation API (V2)
This convert radeon to use new TTM validation API, it doesn't
really take advantage of it beside in the eviction case.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h|3 ++
drivers/gpu/drm/radeon/radeon_object.c | 54 ++--
drivers/gpu/drm/radeon/radeon_ttm.c| 61 +++
3 files changed, 67 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 92bebc0..fa265e8 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -208,6 +208,8 @@ struct radeon_bo {
/* Protected by gem.mutex */
struct list_headlist;
/* Protected by tbo.reserved */
+ u32 placements[3];
+ struct ttm_placementplacement;
struct ttm_buffer_objecttbo;
struct ttm_bo_kmap_obj kmap;
unsignedpin_count;
@@ -1000,6 +1002,7 @@ extern void radeon_surface_init(struct radeon_device
*rdev);
extern int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data);
extern void radeon_legacy_set_clock_gating(struct radeon_device *rdev, int
enable);
extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
enable);
+extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
/* r100,rv100,rs100,rv200,rs200,r200,rv250,rs300,rv280 */
struct r100_mc_save {
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index bec4943..d9b239b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -75,6 +75,25 @@ static inline u32 radeon_ttm_flags_from_domain(u32 domain)
return flags;
}
+void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
+{
+ u32 c = 0;
+
+ rbo-placement.fpfn = 0;
+ rbo-placement.lpfn = 0;
+ rbo-placement.placement = rbo-placements;
+ rbo-placement.busy_placement = rbo-placements;
+ if (domain RADEON_GEM_DOMAIN_VRAM)
+ rbo-placements[c++] = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
+ TTM_PL_FLAG_VRAM;
+ if (domain RADEON_GEM_DOMAIN_GTT)
+ rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_TT;
+ if (domain RADEON_GEM_DOMAIN_CPU)
+ rbo-placements[c++] = TTM_PL_MASK_CACHING | TTM_PL_FLAG_SYSTEM;
+ rbo-placement.num_placement = c;
+ rbo-placement.num_busy_placement = c;
+}
+
int radeon_bo_create(struct radeon_device *rdev, struct drm_gem_object *gobj,
unsigned long size, bool kernel, u32 domain,
struct radeon_bo **bo_ptr)
@@ -169,24 +188,20 @@ void radeon_bo_unref(struct radeon_bo **bo)
int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64 *gpu_addr)
{
- u32 flags;
- u32 tmp;
- int r;
+ int r, i;
- flags = radeon_ttm_flags_from_domain(domain);
+ radeon_ttm_placement_from_domain(bo, domain);
if (bo-pin_count) {
bo-pin_count++;
if (gpu_addr)
*gpu_addr = radeon_bo_gpu_offset(bo);
return 0;
}
- tmp = bo-tbo.mem.placement;
- ttm_flag_masked(tmp, flags, TTM_PL_MASK_MEM);
- bo-tbo.proposed_placement = tmp | TTM_PL_FLAG_NO_EVICT |
- TTM_PL_MASK_CACHING;
+ radeon_ttm_placement_from_domain(bo, domain);
+ for (i = 0; i bo-placement.num_placement; i++)
+ bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
retry:
- r = ttm_buffer_object_validate(bo-tbo, bo-tbo.proposed_placement,
- true, false);
+ r = ttm_buffer_object_validate(bo-tbo, bo-placement, true, false);
if (likely(r == 0)) {
bo-pin_count = 1;
if (gpu_addr != NULL)
@@ -202,7 +217,7 @@ retry:
int radeon_bo_unpin(struct radeon_bo *bo)
{
- int r;
+ int r, i;
if (!bo-pin_count) {
dev_warn(bo-rdev-dev, %p unpin not necessary\n, bo);
@@ -211,11 +226,10 @@ int radeon_bo_unpin(struct radeon_bo *bo)
bo-pin_count--;
if (bo-pin_count)
return 0;
- bo-tbo.proposed_placement = bo-tbo.mem.placement
- ~TTM_PL_FLAG_NO_EVICT;
+ for (i = 0; i bo-placement.num_placement; i++)
+ bo-placements[i] = ~TTM_PL_FLAG_NO_EVICT;
retry:
- r = ttm_buffer_object_validate(bo-tbo, bo-tbo.proposed_placement,
- true, false);
+ r = ttm_buffer_object_validate(bo-tbo, bo-placement, true, false);
if (unlikely(r != 0)) {
if (r == -ERESTART)
goto retry;
@@ -326,15 +340,15 @@ int radeon_bo_list_validate(struct list_head *head,
TTM rework buffer validation V2
Updated patch series of TTM validation rework associated cleanup. Thomas i think the patch is ready to go in, so far on radeon no issue but i haven't exercised extensively those changes. wmgfx, openchrome and nouveau will need changes but it should be minor (driver can provide the fixed priority as a safe default). Cheers, Jerome -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] drm: Add search/get functions to get a block in a specific range
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/drm_mm.c | 88 ++
include/drm/drm_mm.h | 34 ++
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 97dc5a4..5a06efe 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -226,6 +226,44 @@ struct drm_mm_node *drm_mm_get_block_generic(struct
drm_mm_node *node,
}
EXPORT_SYMBOL(drm_mm_get_block_generic);
+struct drm_mm_node *drm_mm_get_block_range_generic(struct drm_mm_node *node,
+ unsigned long size,
+ unsigned alignment,
+ unsigned long start,
+ unsigned long end,
+ int atomic)
+{
+ struct drm_mm_node *align_splitoff = NULL;
+ unsigned tmp = 0;
+ unsigned wasted = 0;
+
+ if (node-start start)
+ wasted += start - node-start;
+ if (alignment)
+ tmp = ((node-start + wasted) % alignment);
+
+ if (tmp)
+ wasted += alignment - tmp;
+ if (wasted) {
+ align_splitoff = drm_mm_split_at_start(node, wasted, atomic);
+ if (unlikely(align_splitoff == NULL))
+ return NULL;
+ }
+
+ if (node-size == size) {
+ list_del_init(node-fl_entry);
+ node-free = 0;
+ } else {
+ node = drm_mm_split_at_start(node, size, atomic);
+ }
+
+ if (align_splitoff)
+ drm_mm_put_block(align_splitoff);
+
+ return node;
+}
+EXPORT_SYMBOL(drm_mm_get_block_range_generic);
+
/*
* Put a block. Merge with the previous and / or next block if they are free.
* Otherwise add to the free stack.
@@ -331,6 +369,56 @@ struct drm_mm_node *drm_mm_search_free(const struct drm_mm
*mm,
}
EXPORT_SYMBOL(drm_mm_search_free);
+struct drm_mm_node *drm_mm_search_free_in_range(const struct drm_mm *mm,
+ unsigned long size,
+ unsigned alignment,
+ unsigned long start,
+ unsigned long end,
+ int best_match)
+{
+ struct list_head *list;
+ const struct list_head *free_stack = mm-fl_entry;
+ struct drm_mm_node *entry;
+ struct drm_mm_node *best;
+ unsigned long best_size;
+ unsigned wasted;
+
+ best = NULL;
+ best_size = ~0UL;
+
+ list_for_each(list, free_stack) {
+ entry = list_entry(list, struct drm_mm_node, fl_entry);
+ wasted = 0;
+
+ if (entry-size size)
+ continue;
+
+ if (entry-start end || (entry-start+entry-size) start)
+ continue;
+
+ if (entry-start start)
+ wasted += start - entry-start;
+
+ if (alignment) {
+ register unsigned tmp = (entry-start + wasted) %
alignment;
+ if (tmp)
+ wasted += alignment - tmp;
+ }
+
+ if (entry-size = size + wasted) {
+ if (!best_match)
+ return entry;
+ if (size best_size) {
+ best = entry;
+ best_size = entry-size;
+ }
+ }
+ }
+
+ return best;
+}
+EXPORT_SYMBOL(drm_mm_search_free_in_range);
+
int drm_mm_clean(struct drm_mm * mm)
{
struct list_head *head = mm-ml_entry;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 62329f9..b40b2f0 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -66,6 +66,13 @@ extern struct drm_mm_node *drm_mm_get_block_generic(struct
drm_mm_node *node,
unsigned long size,
unsigned alignment,
int atomic);
+extern struct drm_mm_node *drm_mm_get_block_range_generic(
+ struct drm_mm_node *node,
+ unsigned long size,
+ unsigned alignment,
+ unsigned long start,
+ unsigned long end,
+ int atomic);
static inline struct drm_mm_node *drm_mm_get_block(struct drm_mm_node *parent,
unsigned long size,
[Bug 25489] New: distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 Summary: distortion in screen. Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: stompdagg...@yahoo.com I have a ati 3450 mobility on a dell studio 1535 running gentoo. I use kernel-2.6.32, kms, radeon, mesa and libdrm from git/svn, recently, I have noticed this distortions. it started not to long ago when I was using kernel-2.6.31 with radeon, mesa and libdrm and the x11-drm driver from git/svn, I'm not sure if it is mesa related, please assign to right maintainer if it isn't mesa related. here is the dmesg related snip: [drm] GART: num cpu pages 131072, num gpu pages 131072 ieee1394: Host added: ID:BUS[0-00:1023] GUID[464fc000126bec70] [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] LVDS [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] LCD1: INTERNAL_KLDSCP_LVTMA [drm] Connector 2: [drm] HDMI-A [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] fb mappable at 0xE0141000 [drm] vram apper at 0xE000 [drm] size 5299200 [drm] fb depth is 24 [drm]pitch is 5888 executing set pll executing set crtc timing [drm] LVDS-11: set mode 1440x900 1b I can provide more info if needed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25490] New: kernel crash with 2.6.32, drm and kms enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=25490 Summary: kernel crash with 2.6.32, drm and kms enabled. Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: stompdagg...@yahoo.com Created an attachment (id=31818) -- (http://bugs.freedesktop.org/attachment.cgi?id=31818) traceback I have a ati 3450 mobility on a dell studio 1535 running gentoo. I use kernel-2.6.32, kms, radeon, mesa and libdrm from git/svn. 10 minutes ago while usind the comp my screen blacked out and return into a blurry screen. I'm use kde 4.3.4 and was using composite at that time. here is the traceback: -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2 RESEND] Replace TTM -ERESTART returns with -ERESTARTSYS
Thomas attached is updated patch, they apply on top of my ttm changes. I modified radeon to return -ERESTARTSYS and updated libdrm_radeon to deal with this change. I didn't changed the patch that much but i added my signoff maybe only ack is need, not sure about that. Cheers, Jerome -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon: Remove tests for -ERESTART from the TTM code.
From: Thomas Hellstrom thellst...@vmware.com
Also sets affected TTM calls up to not wait interruptible, since
that would cause an in-kernel spin until the TTM call succeeds, since
the Radeon code does not return to user-space when a signal is received.
Modifies interruptible fence waits to return -ERESTARTSYS rather than
-EBUSY when interrupted by a signal, since that's the (yet undocumented)
semantics required by the TTM sync object hooks.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_fence.c |5 +--
drivers/gpu/drm/radeon/radeon_object.c | 38 ++-
2 files changed, 14 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 2ac3163..78743cd 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -197,9 +197,8 @@ retry:
r = wait_event_interruptible_timeout(rdev-fence_drv.queue,
radeon_fence_signaled(fence), timeout);
radeon_irq_kms_sw_irq_put(rdev);
- if (unlikely(r == -ERESTARTSYS)) {
- return -EBUSY;
- }
+ if (unlikely(r != 0))
+ return r;
} else {
radeon_irq_kms_sw_irq_get(rdev);
r = wait_event_timeout(rdev-fence_drv.queue,
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index d9b239b..ca172ad 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -121,16 +121,15 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
INIT_LIST_HEAD(bo-list);
flags = radeon_ttm_flags_from_domain(domain);
-retry:
+ /* Kernel allocation are uninterruptible */
r = ttm_buffer_object_init(rdev-mman.bdev, bo-tbo, size, type,
- flags, 0, 0, true, NULL, size,
+ flags, 0, 0, !kernel, NULL, size,
radeon_ttm_bo_destroy);
if (unlikely(r != 0)) {
- if (r == -ERESTART)
- goto retry;
- /* ttm call radeon_ttm_object_object_destroy if error happen */
- dev_err(rdev-dev, object_init failed for (%ld, 0x%08X)\n,
- size, flags);
+ if (r != -ERESTARTSYS)
+ dev_err(rdev-dev,
+ object_init failed for (%ld, 0x%08X)\n,
+ size, flags);
return r;
}
*bo_ptr = bo;
@@ -200,18 +199,14 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64
*gpu_addr)
radeon_ttm_placement_from_domain(bo, domain);
for (i = 0; i bo-placement.num_placement; i++)
bo-placements[i] |= TTM_PL_FLAG_NO_EVICT;
-retry:
- r = ttm_buffer_object_validate(bo-tbo, bo-placement, true, false);
+ r = ttm_buffer_object_validate(bo-tbo, bo-placement, false, false);
if (likely(r == 0)) {
bo-pin_count = 1;
if (gpu_addr != NULL)
*gpu_addr = radeon_bo_gpu_offset(bo);
}
- if (unlikely(r != 0)) {
- if (r == -ERESTART)
- goto retry;
+ if (unlikely(r != 0))
dev_err(bo-rdev-dev, %p pin failed\n, bo);
- }
return r;
}
@@ -228,15 +223,10 @@ int radeon_bo_unpin(struct radeon_bo *bo)
return 0;
for (i = 0; i bo-placement.num_placement; i++)
bo-placements[i] = ~TTM_PL_FLAG_NO_EVICT;
-retry:
- r = ttm_buffer_object_validate(bo-tbo, bo-placement, true, false);
- if (unlikely(r != 0)) {
- if (r == -ERESTART)
- goto retry;
+ r = ttm_buffer_object_validate(bo-tbo, bo-placement, false, false);
+ if (unlikely(r != 0))
dev_err(bo-rdev-dev, %p validate failed for unpin\n, bo);
- return r;
- }
- return 0;
+ return r;
}
int radeon_bo_evict_vram(struct radeon_device *rdev)
@@ -346,15 +336,11 @@ int radeon_bo_list_validate(struct list_head *head, void
*fence)
radeon_ttm_placement_from_domain(bo,
lobj-rdomain);
}
-retry:
r = ttm_buffer_object_validate(bo-tbo,
bo-placement,
true, false);
- if (unlikely(r)) {
- if (r == -ERESTART)
- goto retry;
+ if (unlikely(r))
return r;
-
[PATCH 1/2] drm/ttm: Have the TTM code return -ERESTARTSYS instead of -ERESTART.
From: Thomas Hellstrom thellst...@vmware.com
Return -ERESTARTSYS instead of -ERESTART when interrupted by a signal.
The -ERESTARTSYS is converted to an -EINTR by the kernel signal layer
before returned to user-space.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 29 +++--
drivers/gpu/drm/ttm/ttm_bo_vm.c |7 +--
include/drm/ttm/ttm_bo_api.h| 14 +++---
include/drm/ttm/ttm_bo_driver.h |8
4 files changed, 23 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5ffb44f..b8dea3a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -125,7 +125,7 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo,
bool interruptible)
ret = wait_event_interruptible(bo-event_queue,
atomic_read(bo-reserved) == 0);
if (unlikely(ret != 0))
- return -ERESTART;
+ return ret;
} else {
wait_event(bo-event_queue, atomic_read(bo-reserved) == 0);
}
@@ -570,7 +570,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool
interruptible,
spin_unlock(bo-lock);
if (unlikely(ret != 0)) {
- if (ret != -ERESTART) {
+ if (ret != -ERESTARTSYS) {
printk(KERN_ERR TTM_PFX
Failed to expire sync object before
buffer eviction.\n);
@@ -587,7 +587,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool
interruptible,
ret = ttm_bo_mem_space(bo, placement, evict_mem, interruptible,
no_wait);
if (ret) {
- if (ret != -ERESTART)
+ if (ret != -ERESTARTSYS)
printk(KERN_ERR TTM_PFX
Failed to find memory space for
buffer 0x%p eviction.\n, bo);
@@ -597,7 +597,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool
interruptible,
ret = ttm_bo_handle_move_mem(bo, evict_mem, true, interruptible,
no_wait);
if (ret) {
- if (ret != -ERESTART)
+ if (ret != -ERESTARTSYS)
printk(KERN_ERR TTM_PFX Buffer eviction failed\n);
spin_lock(glob-lru_lock);
if (evict_mem.mm_node) {
@@ -794,7 +794,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
uint32_t cur_flags = 0;
bool type_found = false;
bool type_ok = false;
- bool has_eagain = false;
+ bool has_erestartsys = false;
struct drm_mm_node *node = NULL;
int i, ret;
@@ -869,28 +869,21 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem-mm_node-private = bo;
return 0;
}
- if (ret == -ERESTART)
- has_eagain = true;
+ if (ret == -ERESTARTSYS)
+ has_erestartsys = true;
}
- ret = (has_eagain) ? -ERESTART : -ENOMEM;
+ ret = (has_erestartsys) ? -ERESTARTSYS : -ENOMEM;
return ret;
}
EXPORT_SYMBOL(ttm_bo_mem_space);
int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
{
- int ret = 0;
-
if ((atomic_read(bo-cpu_writers) 0) no_wait)
return -EBUSY;
- ret = wait_event_interruptible(bo-event_queue,
- atomic_read(bo-cpu_writers) == 0);
-
- if (ret == -ERESTARTSYS)
- ret = -ERESTART;
-
- return ret;
+ return wait_event_interruptible(bo-event_queue,
+ atomic_read(bo-cpu_writers) == 0);
}
int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
@@ -1652,7 +1645,7 @@ int ttm_bo_block_reservation(struct ttm_buffer_object
*bo, bool interruptible,
ret = wait_event_interruptible
(bo-event_queue, atomic_read(bo-reserved) == 0);
if (unlikely(ret != 0))
- return -ERESTART;
+ return ret;
} else {
wait_event(bo-event_queue,
atomic_read(bo-reserved) == 0);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 1c040d0..609a85a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -114,7 +114,7 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
ret = ttm_bo_wait(bo, false, true, false);
spin_unlock(bo-lock);
if (unlikely(ret != 0)) {
- retval = (ret != -ERESTART)
[Bug 25489] distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-07 09:56:52 PST --- Please attach your xorg log and and dmesg output. Also, can you describe the distortions? flickering? rendering artifacts? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2 RESEND] Replace TTM -ERESTART returns with -ERESTARTSYS
Jerome Glisse wrote: Thomas attached is updated patch, they apply on top of my ttm changes. I modified radeon to return -ERESTARTSYS and updated libdrm_radeon to deal with this change. I didn't changed the patch that much but i added my signoff maybe only ack is need, not sure about that. Cheers, Jerome Thanks, Jerome. I haven't yet looked at the libdrm_radeon change, and my hope was that no user-space change was needed, since the -ERESTARTSYS is converted to an -EINTR in the kernel signal layer before returned to user-space, and the -EINTR is handled in drmCommand[Write|Read|None]. /Thomas -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/1 Rafał Miłecki zaj...@gmail.com: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Cheers Mike -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Misreported VRAM
I have a Radeon 4650 (RV730) : 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV730 PRO [Radeon HD 4650] [1002:9498] This should have 1GB DDR2 VRAM on board however my dmesg states differently [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon :01:00.0: PCI INT A - GSI 18 (level, low) - IRQ 18 radeon :01:00.0: setting latency timer to 64 [drm] radeon: Initializing kernel modesetting. [drm] register mmio base: 0xFE9F [drm] register mmio size: 65536 ATOM BIOS: 11X [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 1028846 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Loading RV730 CP Microcode platform radeon_cp.0: firmware: using built-in firmware radeon/RV730_pfp.bin platform radeon_cp.0: firmware: using built-in firmware radeon/RV730_me.bin [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] HDMI-A [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY1 [drm] Connector 1: [drm] VGA [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c [drm] Encoders: [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 2: [drm] DVI-I [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP1: INTERNAL_UNIPHY [drm] fb mappable at 0xD0141000 [drm] vram apper at 0xD000 [drm] size 8294400 [drm] fb depth is 24 [drm]pitch is 7680 Is it perhaps reporting something else? Cheers Mike -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix r100-r500 CS checker for compressed textures.
The calculations are wrong.
E.g. for image 16 x 16, format is DXT3 (block size = 16 bytes, block width =
4, block height = 4) the size is 256. Yours code would calculate it as 16 *
(16 / 4) = 64.
The proper way to calculate it is
unsigned wblocks = (width + blockWidth - 1) / blockWidth;
unsigned hblocks = (height + blockHeight - 1) / blockHeight;
unsigned size = wblocks * hblocks * bytesPerBlock;
For DXT1 blockWidth is 4, blockHeight 4 and bytesPerBlock 4.
For DXT3 and DXT5 blockWidth is 4, blockHeight 4 and bytesPerBlock 8.
For small textures wblocks need to be aligned to 4 for DXT1, and 2 for DXT3/5
You may want to look at get_compressed_image_size in radeon_mipmap_tree.c and
_mesa_format_image_size in mesa/src/mesa/main/formats.c for reference.
Regards,
Maciej
Dnia poniedziałek, 7 grudnia 2009 o 04:17:52 Dave Airlie napisał(a):
From: Dave Airlie airl...@redhat.com
This adds support for compressed textures to the r100-r500 CS
checker, it lets me run openarena and the demos in mesa fine,
If someone can check the size calcs for DXT1/35 the w//h changes
that would be nice.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 26 +++---
drivers/gpu/drm/radeon/r100_track.h |5 +
drivers/gpu/drm/radeon/r200.c | 10 --
drivers/gpu/drm/radeon/r300.c | 12 +---
4 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 79206e9..6597b5c 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1256,7 +1256,6 @@ static int r100_packet0_check(struct radeon_cs_parser
*p, case RADEON_TXFORMAT_ARGB:
case RADEON_TXFORMAT_VYUY422:
case RADEON_TXFORMAT_YVYU422:
- case RADEON_TXFORMAT_DXT1:
case RADEON_TXFORMAT_SHADOW16:
case RADEON_TXFORMAT_LDUDV655:
case RADEON_TXFORMAT_DUDV88:
@@ -1264,12 +1263,19 @@ static int r100_packet0_check(struct
radeon_cs_parser *p, break;
case RADEON_TXFORMAT_ARGB:
case RADEON_TXFORMAT_RGBA:
- case RADEON_TXFORMAT_DXT23:
- case RADEON_TXFORMAT_DXT45:
case RADEON_TXFORMAT_SHADOW32:
case RADEON_TXFORMAT_LDUDUV:
track-textures[i].cpp = 4;
break;
+ case RADEON_TXFORMAT_DXT1:
+ track-textures[i].cpp = 1;
+ track-textures[i].compress_format =
R100_TRACK_COMP_DXT1;
+ break;
+ case RADEON_TXFORMAT_DXT23:
+ case RADEON_TXFORMAT_DXT45:
+ track-textures[i].cpp = 1;
+ track-textures[i].compress_format =
R100_TRACK_COMP_DXT35;
+ break;
}
track-textures[i].cube_info[4].width = 1 ((idx_value 16)
0xf);
track-textures[i].cube_info[4].height = 1 ((idx_value
20) 0xf);
@@ -2588,6 +2594,7 @@ static inline void r100_cs_track_texture_print(struct
r100_cs_track_texture *t) DRM_ERROR(coordinate type%d\n,
t-tex_coord_type); DRM_ERROR(width round to power of 2 %d\n,
t-roundup_w);
DRM_ERROR(height round to power of 2 %d\n, t-roundup_h);
+ DRM_ERROR(compress format%d\n, t-compress_format);
}
static int r100_cs_track_cube(struct radeon_device *rdev,
@@ -2654,9 +2661,21 @@ static int r100_cs_track_texture_check(struct
radeon_device *rdev, h = h / (1 i);
if (track-textures[u].roundup_h)
h = roundup_pow_of_two(h);
+ if (track-textures[u].compress_format) {
+ /* compressed textures are block based */
+ if (track-textures[u].compress_format ==
R100_TRACK_COMP_DXT1) {
+ w *= 2;
+ h /= 8;
+ } else {
+ h /= 4;
+ }
+ if (w 32)
+ w = 32;
+ }
size += w * h;
}
size *= track-textures[u].cpp;
+
switch (track-textures[u].tex_coord_type) {
case 0:
break;
@@ -2821,6 +2840,7 @@ void r100_cs_track_clear(struct radeon_device *rdev,
struct r100_cs_track *track track-arrays[i].esize = 0x7F;
}
for (i = 0; i track-num_texture; i++) {
+ track-textures[i].compress_format = R100_TRACK_COMP_NONE;
track-textures[i].pitch = 16536;
track-textures[i].width = 16536;
track-textures[i].height = 16536;
diff --git a/drivers/gpu/drm/radeon/r100_track.h
[Bug 25478] SIGSEGV in radeon_texture.c:524
http://bugs.freedesktop.org/show_bug.cgi?id=25478 --- Comment #1 from Maciej Cencora m.cenc...@gmail.com 2009-12-07 11:36:30 PST --- It looks like duplicate of #25355. Should be fixed by 8cde43eb19c4dcceb7. Can you confirm? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25489] distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 --- Comment #2 from dagg stompdagg...@yahoo.com 2009-12-07 11:40:27 PST --- (In reply to comment #1) Please attach your xorg log and and dmesg output. Also, can you describe the distortions? flickering? rendering artifacts? there are distortions and occasional flickering, not sure what rendering artifacts. strange, I was sure the screenshot was attached... I'm attaching files. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25489] distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 --- Comment #3 from dagg stompdagg...@yahoo.com 2009-12-07 11:41:05 PST --- Created an attachment (id=31820) -- (http://bugs.freedesktop.org/attachment.cgi?id=31820) screenshot -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25489] distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 --- Comment #4 from dagg stompdagg...@yahoo.com 2009-12-07 11:41:55 PST --- Created an attachment (id=31821) -- (http://bugs.freedesktop.org/attachment.cgi?id=31821) dmesg log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25489] distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 --- Comment #5 from dagg stompdagg...@yahoo.com 2009-12-07 11:42:32 PST --- Created an attachment (id=31822) -- (http://bugs.freedesktop.org/attachment.cgi?id=31822) xorg.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25489] distortion in screen.
http://bugs.freedesktop.org/show_bug.cgi?id=25489 --- Comment #6 from dagg stompdagg...@yahoo.com 2009-12-07 11:43:30 PST --- (In reply to comment #2) (In reply to comment #1) Please attach your xorg log and and dmesg output. Also, can you describe the distortions? flickering? rendering artifacts? there are distortions and occasional flickering, not sure what rendering artifacts. strange, I was sure the screenshot was attached... I'm attaching files. not sure what are rendering artifacts. (my bad, missed the are word) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2 RESEND] Replace TTM -ERESTART returns with -ERESTARTSYS
On Mon, Dec 07, 2009 at 06:51:34PM +0100, Thomas Hellstrom wrote: Jerome Glisse wrote: Thomas attached is updated patch, they apply on top of my ttm changes. I modified radeon to return -ERESTARTSYS and updated libdrm_radeon to deal with this change. I didn't changed the patch that much but i added my signoff maybe only ack is need, not sure about that. Cheers, Jerome Thanks, Jerome. I haven't yet looked at the libdrm_radeon change, and my hope was that no user-space change was needed, since the -ERESTARTSYS is converted to an -EINTR in the kernel signal layer before returned to user-space, and the -EINTR is handled in drmCommand[Write|Read|None]. /Thomas No, we were using ioctl directly, i converted libdrm-radeon to use drmIoctl which handle errno=EINTR or EAGAIN, this to run fine but haven't checked how much restart i get. Cheers, Jerome -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Misreported VRAM
On Mon, Dec 07, 2009 at 06:54:13PM +, Mike Lothian wrote: I have a Radeon 4650 (RV730) : 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV730 PRO [Radeon HD 4650] [1002:9498] This should have 1GB DDR2 VRAM on board however my dmesg states differently So far we don't use VRAM beyond PCI aperture which is 256M on your system. I am planing on adding support for unvisible ram this week. Note that i don't think we have a driver which can take advantage of such amount of VRAM yet, except if you are driving 2 30 screen. Cheers, Jerome -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Misreported VRAM
2009/12/7 Jerome Glisse gli...@freedesktop.org: On Mon, Dec 07, 2009 at 06:54:13PM +, Mike Lothian wrote: I have a Radeon 4650 (RV730) : 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV730 PRO [Radeon HD 4650] [1002:9498] This should have 1GB DDR2 VRAM on board however my dmesg states differently So far we don't use VRAM beyond PCI aperture which is 256M on your system. I am planing on adding support for unvisible ram this week. Note that i don't think we have a driver which can take advantage of such amount of VRAM yet, except if you are driving 2 30 screen. Cheers, Jerome Ah ok Maybe a wee line saying this in the dmesg would stop others from reporting this if they ever notice it Cheers Mike -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Gallium3D Developers Workshop Now Online
Gallium3D Developers, The videos and slide decks from the Gallium3D Developers Workshop hosted by VMware on Nov 13th are now being posted online at: http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ More of the presentations will be posted to this page as they become available. Don't hesitate to contact me directly if you have any questions about the workshop material. Regards, Jens Owen -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25478] SIGSEGV in radeon_texture.c:524
http://bugs.freedesktop.org/show_bug.cgi?id=25478 --- Comment #2 from David Ronis david.ro...@mcgill.ca 2009-12-07 12:18:50 PST --- The patch in #25355 fixes the problem. Note that it hasn't been committed to master yet. Thanks -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Gallium3D Developers Workshop Now Online
Excellent news! Please update site as soon as possible. Topics are more than interesting. If you have some otherPDF documenation, book, or other materials (white papers,blueprints, etc.) you want to open to the public, pleasedo it since it is very important for us who are not at theepicenter of events and do not have resources to attendsuch conferences. Uros --- Every kind of peaceful cooperation among men is primarily based on mutual trust and only secondarily on institutions such as courts of justice and police. - Albert Einstein (1879 - 1955) From: j...@lunarg.com To: mesa3d-...@lists.sourceforge.net; dri-devel@lists.sourceforge.net Subject: Gallium3D Developers Workshop Now Online Date: Mon, 7 Dec 2009 12:49:43 -0700 Gallium3D Developers, The videos and slide decks from the Gallium3D Developers Workshop hosted by VMware on Nov 13th are now being posted online at: http://www.lunarg.com/wordpress/technologies/gallium-3d/gallium3d-online-developers-workshop/ More of the presentations will be posted to this page as they become available. Don't hesitate to contact me directly if you have any questions about the workshop material. Regards, Jens Owen -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009-- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian m...@fireburn.co.uk wrote: 2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old Is the drm loading properly? Can you open a bug and attach your xorg log and dmesg output? https://bugs.freedesktop.org Choose DRI and DRM/Radeon as the component. Alex -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24837] Broken ring info in debugfs
http://bugs.freedesktop.org/show_bug.cgi?id=24837 --- Comment #7 from Rafał Miłecki zaj...@gmail.com 2009-12-07 15:01:33 PST --- http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=d684076627a4561ea698bf7652a1a1baabdcdbdc -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/7 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian m...@fireburn.co.uk wrote: 2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old Is the drm loading properly? Can you open a bug and attach your xorg log and dmesg output? https://bugs.freedesktop.org Choose DRI and DRM/Radeon as the component. Alex Hmm it's working fine using the drm-next branch from the dri-2.6 Perhaps it was just stale patches in drm-radeon-testing -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[BISECTED] drm: random hang since 620f378 drm: prune modes when ...
After upgrading one of my machines to 2.6.32, I saw hangs after one to thirty
minutes after
booting, with random data written to parts of the frame buffer. I've bisected
it down
to 620f37811d drm: prune modes when output is disconnected., which was merged
in 2.6.32-rc1. Connecting a serial console does not reveal any output at the
time of
the crash.
The machine uses an Intel G45 chipset with the i915 kernel mode setting enabled.
I have no clue what that patch does or why reverting it fixes the problem but
2.6.32
with this revert applied has not shown these hangs yet.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -104,7 +104,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (connector-status == connector_status_disconnected) {
DRM_DEBUG_KMS(%s is disconnected\n,
drm_get_connector_name(connector));
- goto prune;
+ /* TODO set EDID to NULL */
+ return 0;
}
count = (*connector_funcs-get_modes)(connector);
@@ -132,7 +133,6 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
mode);
}
-prune:
drm_mode_prune_invalid(dev, connector-modes, true);
if (list_empty(connector-modes))
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM/ttm: Unreachable code in ttm_bo_add_ttm
Hi, Stanse found unreachable code in ttm_bo_add_ttm: http://decibel.fi.muni.cz/~xslaby/stanse/error.cgi?db=32id=714#l238 Excerpt from there: 230| case ttm_bo_type_user: 231| bo-ttm = ttm_tt_create(bdev, bo-num_pages 12, 232| page_flags | (1 1), 233| glob-dummy_read_page); 234| if (bo-ttm == ((void *)0)) 235| ret = -12; 236| break; 237| 238| ret = ttm_tt_set_user(bo-ttm, get_current(), |This node is unreachable prev next 239| bo-buffer_start, bo-num_pages); 240| if (ret != 0) 241| ttm_tt_destroy(bo-ttm); 242| break; regards, -- js -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/*/kms: how to prepare driver for modesetting
W dniu 3 grudnia 2009 11:20 użytkownik Jerome Glisse gli...@freedesktop.org napisał: The first design i thought for PM long time ago was : func_compute_clock func_set_clock func_irq_powersave func_compute_clock is call any time there is a mode change to compute new minimum clock. func_set_clock is call after func_compute_clock (if we need to upclock gpu to have enough bandwidth for a new video mode) or from func_irq_powersave. func_set_clock would have to take all necessary lock to ensure exclusive hw access. func_irq_powersave is the function responsible for downclocking or not the GPU, it's call from irq handler, and it would call func_set_clock to do the work if necessary Do you think it's alright to do modeset on downclocked GPU? With my patch I upclocked before every modeset operation, but not sure anymore if that is necessary... -- Rafał -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM/ttm: Unreachable code in ttm_bo_add_ttm
On Mon, 7 Dec 2009, Jiri Slaby wrote:
Hi,
Stanse found unreachable code in ttm_bo_add_ttm:
http://decibel.fi.muni.cz/~xslaby/stanse/error.cgi?db=32id=714#l238
Excerpt from there:
230| case ttm_bo_type_user:
231| bo-ttm = ttm_tt_create(bdev, bo-num_pages 12,
232| page_flags | (1 1),
233| glob-dummy_read_page);
234| if (bo-ttm == ((void *)0))
235| ret = -12;
236| break;
237|
238| ret = ttm_tt_set_user(bo-ttm, get_current(),
|This node is unreachable prev next
239| bo-buffer_start, bo-num_pages);
240| if (ret != 0)
241| ttm_tt_destroy(bo-ttm);
242| break;
Thanks,
I've pushed this patch.
From 447aeb907e417e0e837b4a4026d5081c88b6e8ca Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Tue, 8 Dec 2009 09:25:45 +1000
Subject: [PATCH] drm/ttm: fix unreachable code.
None of the in-tree drivers use user objects yet so this wasn't hitting
us.
Stanse found unreachable code in ttm_bo_add_ttm:
http://decibel.fi.muni.cz/~xslaby/stanse/error.cgi?db=32id=714#l238
Reported-by: Jiri Slaby jirisl...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 87c0625..e13fd23 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -275,9 +275,10 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo,
bool zero_alloc)
bo-ttm = ttm_tt_create(bdev, bo-num_pages PAGE_SHIFT,
page_flags | TTM_PAGE_FLAG_USER,
glob-dummy_read_page);
- if (unlikely(bo-ttm == NULL))
+ if (unlikely(bo-ttm == NULL)) {
ret = -ENOMEM;
- break;
+ break;
+ }
ret = ttm_tt_set_user(bo-ttm, current,
bo-buffer_start, bo-num_pages);
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25502] New: Problems running Warcraft 3 under wine using mesa
http://bugs.freedesktop.org/show_bug.cgi?id=25502 Summary: Problems running Warcraft 3 under wine using mesa Product: DRI Version: DRI CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: normal Priority: low Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: m...@fireburn.co.uk CC: m...@fireburn.co.uk I've created a chroot to finally get around the problem of gentoo having out of date 32bit libdrm and mesa libraries Now however I'm facing bugs (or incomplete featuers), which I believe originate in the mesa stack (rather than the wine code itself) fixme:mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer err:ole:CoCreateInstance apartment not initialised err:winediag:X11DRV_WineGL_InitOpenglInfo Direct rendering is disabled, most likely your OpenGL drivers haven't been installed correctly fixme:advapi:SetSecurityInfo stub X Error of failed request: GLXBadDrawable Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 1021 Current serial number in output stream: 1021 fixme:mixer:ALSA_MixerInit No master control found on HDA ATI HDMI, disabling mixer err:ole:CoCreateInstance apartment not initialised err:winediag:X11DRV_WineGL_InitOpenglInfo Direct rendering is disabled, most likely your OpenGL drivers haven't been installed correctly fixme:advapi:SetSecurityInfo stub fixme:d3d_caps:wined3d_guess_vendor Received unrecognized GL_VENDOR Advanced Micro Devices, Inc.. Returning VENDOR_WINE. fixme:d3d:check_fbo_compat Format WINED3DFMT_B8G8R8_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:d3d:check_fbo_compat Format WINED3DFMT_B8G8R8A8_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:d3d:check_fbo_compat Format WINED3DFMT_B8G8R8X8_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:d3d:check_fbo_compat Format WINED3DFMT_B5G6R5_UNORM rtInternal format is not supported as FBO color attachment. fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16_UNORM rtInternal format is not supported as FBO color attachment. fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16B16A16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:win:EnumDisplayDevicesW ((null),0,0x33f25c,0x), stub! fixme:d3d_caps:wined3d_guess_vendor Received unrecognized GL_VENDOR Advanced Micro Devices, Inc.. Returning VENDOR_WINE. fixme:d3d:check_fbo_compat Format WINED3DFMT_B8G8R8_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:d3d:check_fbo_compat Format WINED3DFMT_B8G8R8A8_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:d3d:check_fbo_compat Format WINED3DFMT_B8G8R8X8_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:d3d:check_fbo_compat Format WINED3DFMT_B5G6R5_UNORM rtInternal format is not supported as FBO color attachment. fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16_UNORM rtInternal format is not supported as FBO color attachment. fixme:d3d:check_fbo_compat Format WINED3DFMT_R16G16B16A16_UNORM with rendertarget flag is not supported as FBO color attachment, and no fallback specified. fixme:win:EnumDisplayDevicesW ((null),0,0x33f634,0x), stub! X Error of failed request: GLXBadDrawable Major opcode of failed request: 151 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 1683 Current serial number in output stream: 1683 At this point I'm told there is no cd in the drive (despite using the official online installer) After a few retries the game loads but renders horrifically slowly When I exit out the terminal if filled with: err:d3d:context_check_fbo_status FBO 0 is incomplete, driver bug? fixme:d3d:debug_fbostatus Unrecognied FBO status 0x fixme:d3d:context_check_fbo_status FBO status unrecognized (0) There is nothing strange in my dmesg but it has been attached anyway lspci -nn output 00:00.0 Host bridge [0600]: ATI Technologies Inc RS690 Host Bridge [1002:7910] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Graphics Port 0) [1002:7913] 00:07.0 PCI bridge [0604]: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3) [1002:7917] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] 00:13.0 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] 00:13.1 USB Controller [0c03]: ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] 00:13.2 USB Controller [0c03]: ATI Technologies Inc
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/7 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian m...@fireburn.co.uk wrote: 2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old Is the drm loading properly? Can you open a bug and attach your xorg log and dmesg output? https://bugs.freedesktop.org Choose DRI and DRM/Radeon as the component. Alex I've now reported another bug which is the main reason for me messing with mesa libdrm, the latest kernel code and 32bit chroots in the first place - Warcraft 3 :-D -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/*/kms: how to prepare driver for modesetting
2009/12/7 Rafał Miłecki zaj...@gmail.com: W dniu 3 grudnia 2009 11:20 użytkownik Jerome Glisse gli...@freedesktop.org napisał: The first design i thought for PM long time ago was : func_compute_clock func_set_clock func_irq_powersave func_compute_clock is call any time there is a mode change to compute new minimum clock. func_set_clock is call after func_compute_clock (if we need to upclock gpu to have enough bandwidth for a new video mode) or from func_irq_powersave. func_set_clock would have to take all necessary lock to ensure exclusive hw access. func_irq_powersave is the function responsible for downclocking or not the GPU, it's call from irq handler, and it would call func_set_clock to do the work if necessary Do you think it's alright to do modeset on downclocked GPU? With my patch I upclocked before every modeset operation, but not sure anymore if that is necessary... For engine clock it should be fine. for mem you'll need to make sure memory bandwidth is adequate. Alex -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25505] New: mplayer -vo gl:yuv=2 fails to compile its fragment program
http://bugs.freedesktop.org/show_bug.cgi?id=25505 Summary: mplayer -vo gl:yuv=2 fails to compile its fragment program Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: astralst...@gen2.org Mplayer fails to initialize its fragment program, thus one can't use the new excellent shader scalers. Consequently yuv=3 and yuv=4 also fail. Mesa is git master, Installed time Tue Dec 08 01:26:46 CET 2009 Mplayer log follows. Mplayer was modified in the process with: -extra debug patch to print the error code - patch that disables OPTION ARB_precision_hint_fastest - with it it also fails $ mplayer -vo gl:yuv=2 -msglevel vo=8 *.avi MPlayer SVN-r29963-4.4.1 (C) 2000-2009 MPlayer Team Playing 1.avi. AVI file format detected. [aviheader] Video stream found, -vid 0 [aviheader] Audio stream found, -aid 1 VIDEO: [XVID] 640x360 24bpp 25.000 fps 1195.5 kbps (145.9 kbyte/s) [gl] using extended formats. Use -vo gl:nomanyfmts if playback fails. [gl] Using 0 as slice height (0 means image height). X11 opening display: :0.0 vo: X11 color mask: FF (R:FF G:FF00 B:FF) vo: X11 running at 1920x1200 with depth 24 and 32 bpp (:0.0 = local display) [x11] Detected wm supports NetWM. [x11] Detected wm supports FULLSCREEN state. [x11] Detected wm supports ABOVE state. [x11] Detected wm supports BELOW state. [x11] Current fstype setting honours FULLSCREEN ABOVE BELOW X atoms == Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) == == Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 44100 Hz, 2 ch, s16le, 160.0 kbit/11.34% (ratio: 2-176400) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [alsa] 44100Hz 2ch s32le (4 bytes per sample) Starting playback... Movie-Aspect is 1,78:1 - prescaling to correct movie aspect. VO: [gl] 640x360 = 640x360 Planar YV12 [gl] GLX chose visual with ID 0xcb OpenGL extensions string: GL_ARB_depth_texture GL_ARB_depth_clamp GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_provoking_vertex GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_MESAX_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_framebuffer_object GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_vertex_array GL_EXT_vertex_array_bgra GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_separate_stencil GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_depth_clamp GL_NV_light_max_exponent GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_import_context GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_copy_sub_buffer GLX_MESA_swap_frame_usage GLX_OML_swap_method
[Bug 25505] mplayer -vo gl:yuv=2 fails to compile its fragment program
http://bugs.freedesktop.org/show_bug.cgi?id=25505 --- Comment #1 from Radosław Szkodziński astralst...@gen2.org 2009-12-07 16:41:51 PST --- Created an attachment (id=31830) -- (http://bugs.freedesktop.org/attachment.cgi?id=31830) Xorg log with card info Short story - card is RV670 - Mobility Radeon HD 3850 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25505] mplayer -vo gl:yuv=2 fails to compile its fragment program
http://bugs.freedesktop.org/show_bug.cgi?id=25505 Radosław Szkodziński astralst...@gen2.org changed: What|Removed |Added Attachment #31830|application/octet-stream|text/plain mime type|| -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25505] mplayer -vo gl:yuv=2 fails to compile its fragment program
http://bugs.freedesktop.org/show_bug.cgi?id=25505
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||NOTOURBUG
--- Comment #2 from Ian Romanick i...@freedesktop.org 2009-12-07 18:01:13
PST ---
(In reply to comment #0)
!!ARBfp1.0
TEMP coord, coord2, cdelta, parmx, parmy, a, b, yuv;TEX yuv.r,
fragment.texcoord[0], texture[0], 2D;TEX yuv.g, fragment.texcoord[1],
texture[1], 2D;TEX yuv.b, fragment.texcoord[2], texture[2], 2D;PARAM ycoef =
{1,1640, 1,1640, 1,1640};PARAM ucoef = {0,, -0,3910, 2,0180};PARAM vcoef =
{1,5960, -0,8130, 0,};PARAM offsets = {-0,8742, 0,5313, -1,0860};TEMP
res;MAD res.rgb, yuv., ycoef, offsets;MAD res.rgb, yuv., ucoef,
res;MAD
result.color.rgb, yuv., vcoef, res;END
The commas in the floating point constants (i.e., 1,1640) are invalid. This
program should not compile on any driver.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25506] New: radeon kms causes 33 second boot delay on kernel v2.6.32
http://bugs.freedesktop.org/show_bug.cgi?id=25506 Summary: radeon kms causes 33 second boot delay on kernel v2.6.32 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: ste...@uplinklabs.net Attached is a dmesg from a system running Linux 2.6.32. The system experiences a horrifying 33 second boot delay, during which the screen is apparently off, not just blanked. Using 'radeon.modeset=0' eliminates the delay. I figured a 'git bisect v2.6.32 v2.6.31 -- drivers/gpu/drm' would catch it. Hopefully this bisection helps pin down the underlying problem: # bad: [22763c5c] Linux 2.6.32 # good: [74fca6a4] Linux 2.6.31 # bad: [df748b02] drm/ttm: fix refcounting in ttm global code. # good: [a513c184] drm/radeon/kms: Don't try to process irq when we a # good: [aadd4e17] drm/radeon: some r420s have a CP race with the DMA # good: [74bf2ad5] drm/kms: make fb helper work for all drivers. # bad: [62a8ea3f] drm/radeon/kms: Remove old init path as no hw use # good: [f0ed1f65] drm/radeon/kms: Convert R520 to new init path and # skip: [d4550907] drm/radeon/kms: Convert R100 to new init path (V2) # good: [3bc68535] drm/radeon/kms: Convert RS690/RS740 to new init pa # bad: [c010f800] drm/radeon/kms: Convert RS600 to new init path Any ideas? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix avivo tiling regression since radeon object rework
From: Dave Airlie airl...@redhat.com
The object rework moved the tiling flag setup around wrongly,
so tiling we getting setup then overwritten by fb format.
Fixes regression with drm-radeon-next on rv530 laptop tiling test.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/atombios_crtc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index fba3c96..6d82417 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -599,8 +599,6 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
}
radeon_bo_get_tiling_flags(rbo, tiling_flags, NULL);
radeon_bo_unreserve(rbo);
- if (tiling_flags RADEON_TILING_MACRO)
- fb_format |= AVIVO_D1GRPH_MACRO_ADDRESS_MODE;
switch (crtc-fb-bits_per_pixel) {
case 8:
@@ -630,6 +628,9 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
return -EINVAL;
}
+ if (tiling_flags RADEON_TILING_MACRO)
+ fb_format |= AVIVO_D1GRPH_MACRO_ADDRESS_MODE;
+
if (tiling_flags RADEON_TILING_MICRO)
fb_format |= AVIVO_D1GRPH_TILED;
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: fix memory leak noticed by kmemleak.
From: Dave Airlie airl...@redhat.com
If we don't need the zone we need to free it.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/ttm/ttm_memory.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 8bfde5f..f5245c0 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -323,8 +323,10 @@ static int ttm_mem_init_dma32_zone(struct ttm_mem_global
*glob,
* No special dma32 zone needed.
*/
- if (mem = ((uint64_t) 1ULL 32))
+ if (mem = ((uint64_t) 1ULL 32)) {
+ kfree(zone);
return 0;
+ }
/*
* Limit max dma32 memory to 4GB for now
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25506] radeon kms causes 33 second boot delay on kernel v2.6.32
http://bugs.freedesktop.org/show_bug.cgi?id=25506 --- Comment #1 from Steven Noonan ste...@uplinklabs.net 2009-12-07 22:27:50 PST --- Created an attachment (id=31831) -- (http://bugs.freedesktop.org/attachment.cgi?id=31831) dmesg from v2.6.32 radeon kms 33s hang -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/*/kms: how to prepare driver for modesetting
W dniu 8 grudnia 2009 00:55 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/7 Rafał Miłecki zaj...@gmail.com: W dniu 3 grudnia 2009 11:20 użytkownik Jerome Glisse gli...@freedesktop.org napisał: The first design i thought for PM long time ago was : func_compute_clock func_set_clock func_irq_powersave func_compute_clock is call any time there is a mode change to compute new minimum clock. func_set_clock is call after func_compute_clock (if we need to upclock gpu to have enough bandwidth for a new video mode) or from func_irq_powersave. func_set_clock would have to take all necessary lock to ensure exclusive hw access. func_irq_powersave is the function responsible for downclocking or not the GPU, it's call from irq handler, and it would call func_set_clock to do the work if necessary Do you think it's alright to do modeset on downclocked GPU? With my patch I upclocked before every modeset operation, but not sure anymore if that is necessary... For engine clock it should be fine. for mem you'll need to make sure memory bandwidth is adequate. So Jerome's solution is not really correct as it does not include that? Then we're back to something similar I've implemented: we have to disable PM for a time of modesetting and then when it's done and when we know needed details to calculate bandwidth - start it again? -- Rafał -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
