[Bug 26887] fence errors with rs785 and kernel 2.6.33
http://bugs.freedesktop.org/show_bug.cgi?id=26887 Marc marvi...@gmx.de changed: What|Removed |Added Severity|normal |critical --- Comment #6 from Marc marvi...@gmx.de 2010-03-10 01:27:35 PST --- I also tested the kernel from fredora 13a to see if I have a problem with my config, but it also shows fence errors. Other failed tests: Sideport - UMA, limit memory from 4G to 2G. As this bug happens on a released kernel and also crashes X sometimes, I changed the severity to critical. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
savage4 + dri fails to un-hibernate
with dri enabled, after un-hibernating machine mouse cursor gets split into individual lines , and can be moved only in corner of the screen. keyboard becomes unresponsive, one cannot switch to vt. with dri disabled, un-hibernating is fine. -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4
On Tue, Mar 9, 2010 at 4:45 PM, Jerome Glisse jgli...@redhat.com wrote:
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In this patch the CP is use as a first indicator
of GPU lockup. If CP doesn't make progress during 1second we assume
we are facing a GPU lockup.
To avoid overhead of testing GPU lockup frequently due to fence
taking time to be signaled we query the lockup callback every
500msec. There is plenty code comment explaining the design choise
inside the code.
This have been tested mostly on R3XX/R5XX hw, in normal running
destkop (compiz firefox, quake3 running) the lockup callback wasn't
call once (1 hour session). Also tested with forcing GPU lockup and
lockup was reported after the 1s CP activity timeout.
V2 switch to 500ms timeout so GPU lockup get call at least 2 times
in less than 2sec.
V3 store last jiffies in fence struct so on ERESTART, EBUSY we keep
track of how long we already wait for a given fence
V4 make sure we got up to date cp read pointer so we don't have
false positive
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c | 6 ++
drivers/gpu/drm/radeon/r100.c | 86 +++
drivers/gpu/drm/radeon/r300.c | 28 -
drivers/gpu/drm/radeon/r600.c | 34 ++-
drivers/gpu/drm/radeon/radeon.h | 104
+++--
drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 102 +---
drivers/gpu/drm/radeon/rv770.c | 6 --
8 files changed, 280 insertions(+), 106 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index bd2e7aa..8988df7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -490,6 +490,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
return 0;
}
+bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
+{
+ /* FIXME: implement for evergreen */
+ return false;
+}
+
int evergreen_gpu_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 91eb762..e4487f3 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1772,6 +1772,92 @@ int r100_rb2d_reset(struct radeon_device *rdev)
return -1;
}
+void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct radeon_cp
*cp)
+{
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+}
+
+/**
+ * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
+ * @rdev: radeon device structure
+ * @lockup: r100_gpu_lockup structure holding CP lockup tracking
informations
+ * @cp: radeon_cp structure holding CP information
+ *
+ * We don't need to initialize the lockup tracking information as we will
either
+ * have CP rptr to a different value of jiffies wrap around which will force
+ * initialization of the lockup tracking informations.
+ *
+ * A possible false positivie is if we get call after while and last_cp_rptr
==
+ * the current CP rptr, even if it's unlikely it might happen. To avoid this
+ * if the elapsed time since last call is bigger than 2 second than we return
+ * false and update the tracking information. Due to this the caller must
call
+ * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
reported
+ * the fencing code should be cautious about that.
+ *
+ * Caller should write to the ring to force CP to do something so we don't
get
+ * false positive when CP is just gived nothing to do.
+ *
+ **/
+bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct
r100_gpu_lockup *lockup, struct radeon_cp *cp)
+{
+ unsigned long cjiffies, elapsed;
+
+ cjiffies = jiffies;
+ if (!time_after(cjiffies, lockup-last_jiffies)) {
time_after(0x0010, 0xfeff) returns true. time_after macro is
defined to deal correctly with wrapping. Only time when it returns
false is when difference of times is more than the half of maximum
jiffies.
+ /* likely a wrap around */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (cp-rptr != lockup-last_cp_rptr) {
+ /* CP is still working no lockup */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ elapsed = jiffies_to_msecs(cjiffies - lockup-last_jiffies);
This
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Wed, Mar 10, 2010 at 7:50 AM, Paul Mundt let...@linux-sh.org wrote: On Tue, Mar 09, 2010 at 10:08:28PM +0100, Rafael J. Wysocki wrote: On Tuesday 09 March 2010, James Simmons wrote: Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). Yeah, I know that. I'm note sure how to check that a device is graphic card though :| Well, that's the outside of the graphics driver part of my question. :-) if ((pdev-class 8) == PCI_CLASS_DISPLAY_VGA) I'm not sure if searching through all PCI devices really is an option. Why not? The VGA arbitration code tracks a list of VGA class devices, so could easily be queried. It looks like it might need a bit more work for PCI hotplug, but it should already have all of the infrastructure you need for getting at the pdev for the suspend/resume case. It would be better to add interface that can be used to query if a graphic device supports KMS. This should support multi-gpu setups at least. I don't think anything prevents running mixed system where secundary gpu is driven by UMS code in X. Are you sure that all vga class devices have private device data that matches private drm_device structure? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26994] New: Openchrome r839 does not build. Changes required in via_drm.h
http://bugs.freedesktop.org/show_bug.cgi?id=26994 Summary: Openchrome r839 does not build. Changes required in via_drm.h Product: DRI Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: high Component: DRM/Via AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: gvli...@gmx.com This is related to ticket 357 in Openchrome. http://www.openchrome.org/trac/ticket/357#comment:9 The latest SVN trunk openchrome does not build in Ubuntu 9.04 Jaunty (kernel 2.6.28). The solution suggested by openchrome guys is to add stdint.h in libdrm. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sun, 07 Mar 2010 12:39:15 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote: On Sun, 07 Mar 2010 00:24:24 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote: On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv wrote: looks this like my problems that i have reported some days ago with Subject Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and intel-gfx list? i have still this issue, but i dont know what you need for informations to fix the issues? with ati driver i dont have problems, only here with intel driver on my Thinkpad X200t with intel HDA Graphics card I now see that compiz hangs in same way. Attached are backtrace of the compiz, and backtrace of etracer which did start full screen but became hung on resolution change. Best regards, Maxim Levitsky Other info that might help: I took a look at X and found that it was in normal waiting state sleeping waiting for input. Also, I found when 'unstable' mesa would appear to work when I start the X while 'stable' one is used. It was compiz. When compiz is running using stable mesa, an game does change the resolution 'usualy' without hang even if uses unstable mesa. Best regards, Maxim Levitsky i found that the kernel updates for 2.6.34-rc1 did make the hang time out... this has to be some vblank issue, i assume... Note that I did try git master of linus tree, and that didn't help with the hang at all (now pulled it again, but don't see any changes in drm code) Best regards, Maxim Levisky yeah. i'm sorry. My issues vanished with current git versions of libdrm,mesa,xserver,xf86-video-intel ... while trying to find out(in vain) which part of the stack did fix the issue, i noticed that the xserver-patches in jesse's tree was which changed hung into timeout... hth, Flo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] Install headers to $(includedir)/libdrm
On Fri, Feb 26, 2010 at 19:07:24 +0100, Julien Cristau wrote: Avoids conflicts with kernel headers. Signed-off-by: Julien Cristau jcris...@debian.org --- This was suggested by Eric so distros can let the kernel install drm headers, but provide updated headers from libdrm so we can build new drivers regardless of the kernel version. any comments on this? Cheers, Julien -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26994] xf86-video-openchrome does not build against =libdrm-2.4.17
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Bartosz Brachaczek b.brachac...@gmail.com changed:
What|Removed |Added
CC||b.brachac...@gmail.com
URL||http://www.openchrome.org/tr
||ac/ticket/357
Component|DRM/Via |libdrm
OS/Version|Linux (All) |All
Summary|Openchrome r839 does not|xf86-video-openchrome does
|build. Changes required in |not build against =libdrm-
|via_drm.h |2.4.17
--- Comment #1 from Bartosz Brachaczek b.brachac...@gmail.com 2010-03-10
05:26:01 PST ---
(In reply to comment #0)
The solution suggested by openchrome guys is to add stdint.h in
libdrm.
Actually, gang65 suggested to replace uint{32,64}_t with _u{32,64} in
drm_mode_crtc_page_flip struct in include/drm/drm_mode.h.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26994] xf86-video-openchrome does not build against =libdrm-2.4.17
http://bugs.freedesktop.org/show_bug.cgi?id=26994 --- Comment #2 from Bartosz Brachaczek b.brachac...@gmail.com 2010-03-10 05:33:29 PST --- Created an attachment (id=33920) -- (http://bugs.freedesktop.org/attachment.cgi?id=33920) correct patch for this issue -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26994] xf86-video-openchrome does not build against =libdrm-2.4.17
http://bugs.freedesktop.org/show_bug.cgi?id=26994 Bartosz Brachaczek b.brachac...@gmail.com changed: What|Removed |Added Keywords||patch -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15276] latest git kernel: general protection fault: 0000 [#1]
http://bugzilla.kernel.org/show_bug.cgi?id=15276 --- Comment #52 from Jérôme Glisse gli...@freedesktop.org 2010-03-10 15:41:55 --- I pushed a tree with a rework of GPU reset and GPU lockup detection, some user indicate that this work better than the current code, please give it a try : Full tree: git://git.kernel.org/pub/scm/linux/kernel/git/glisse/drm-radeon.git branch drm-radeon-next Or apply this 3 patch: http://patchwork.kernel.org/patch/84310/ http://patchwork.kernel.org/patch/84312/ http://patchwork.kernel.org/patch/84311/ Thanks for testing -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Just wanted to bring up the experince of moving linux-fbdev from sf.net to vger. The reason we did the move was because of the amount of spam we had to deal with. Now we have no spam. Of course the draw back is that the old list still exist which means the spam still comes in thus it has to be dealt with. Not too big of a deal. The real issue is people still join the old mailing list and try to post there. Perhaps their is a way to forward subscriptions or send a message to the subscriber to tell them where to really join? Then you have to send real mail to the new list. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] libdrm_radeon: Optimize reloc writing to do less looping.
Bit has table will be first checked from BO if we can quarentee this BO is not
in this cs already.
To quarentee that there is no other cs with same id number of CS that can have
id is limited to 32. Adding and remocing reference in bo is done with atomic
operations to allow parallel access to a bo from multiple contexts.
This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
radeon/radeon_bo_gem.c |1 +
radeon/radeon_cs.c |6 ++
radeon/radeon_cs.h |2 +-
radeon/radeon_cs_gem.c | 133 ---
radeon/radeon_cs_int.h |1 +
5 files changed, 111 insertions(+), 32 deletions(-)
diff --git a/radeon/radeon_bo_gem.c b/radeon/radeon_bo_gem.c
index bc8058d..1b33bdb 100644
--- a/radeon/radeon_bo_gem.c
+++ b/radeon/radeon_bo_gem.c
@@ -80,6 +80,7 @@ static struct radeon_bo *bo_open(struct radeon_bo_manager
*bom,
bo-base.domains = domains;
bo-base.flags = flags;
bo-base.ptr = NULL;
+bo-base.referenced_in_cs = 0;
bo-map_count = 0;
if (handle) {
struct drm_gem_open open_arg;
diff --git a/radeon/radeon_cs.c b/radeon/radeon_cs.c
index cc9be39..d0e922b 100644
--- a/radeon/radeon_cs.c
+++ b/radeon/radeon_cs.c
@@ -88,3 +88,9 @@ void radeon_cs_space_set_flush(struct radeon_cs *cs, void
(*fn)(void *), void *d
csi-space_flush_fn = fn;
csi-space_flush_data = data;
}
+
+uint32_t radeon_cs_get_id(struct radeon_cs *cs)
+{
+struct radeon_cs_int *csi = (struct radeon_cs_int *)cs;
+return csi-id;
+}
diff --git a/radeon/radeon_cs.h b/radeon/radeon_cs.h
index 49d5d9a..7f6ee68 100644
--- a/radeon/radeon_cs.h
+++ b/radeon/radeon_cs.h
@@ -85,7 +85,7 @@ extern int radeon_cs_write_reloc(struct radeon_cs *cs,
uint32_t read_domain,
uint32_t write_domain,
uint32_t flags);
-
+extern uint32_t radeon_cs_get_id(struct radeon_cs *cs);
/*
* add a persistent BO to the list
* a persistent BO is one that will be referenced across flushes,
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..83aabea 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -32,6 +32,7 @@
#include assert.h
#include errno.h
#include stdlib.h
+#include pthread.h
#include sys/mman.h
#include sys/ioctl.h
#include radeon_cs.h
@@ -68,6 +69,66 @@ struct cs_gem {
struct radeon_bo_int**relocs_bo;
};
+
+#if !defined(__GNUC__) || __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ 2)
+/* no built in sync support in compiler define place holders */
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a += val;
+ return val;
+}
+
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a -= val;
+ return val;
+}
+#endif
+
+static pthread_mutex_t id_mutex = PTHREAD_MUTEX_INITIALIZER;
+static uint32_t cs_id_source = 0;
+
+/**
+ * result is undefined if called with ~0
+ */
+static uint32_t get_first_zero(const uint32_t n)
+{
+/* __builtin_ctz returns number of trailing zeros. */
+return 1 __builtin_ctz(~n);
+}
+
+/**
+ * Returns a free id for cs.
+ * If there is no free id we return zero
+ **/
+static uint32_t generate_id(void)
+{
+uint32_t r = 0;
+pthread_mutex_lock( id_mutex );
+/* check for free ids */
+if (cs_id_source != ~r) {
+/* find first zero bit */
+r = get_first_zero(cs_id_source);
+
+/* set id as reserved */
+cs_id_source |= r;
+}
+pthread_mutex_unlock( id_mutex );
+return r;
+}
+
+/**
+ * Free the id for later reuse
+ **/
+static void free_id(uint32_t id)
+{
+pthread_mutex_lock( id_mutex );
+
+cs_id_source = ~id;
+
+pthread_mutex_unlock( id_mutex );
+}
+
static struct radeon_cs_int *cs_gem_create(struct radeon_cs_manager *csm,
uint32_t ndw)
{
@@ -90,6 +151,7 @@ static struct radeon_cs_int *cs_gem_create(struct
radeon_cs_manager *csm,
}
csg-base.relocs_total_size = 0;
csg-base.crelocs = 0;
+csg-base.id = generate_id();
csg-nrelocs = 4096 / (4 * 4) ;
csg-relocs_bo = (struct radeon_bo_int**)calloc(1,
csg-nrelocs*sizeof(void*));
@@ -141,38 +203,43 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
if (write_domain == RADEON_GEM_DOMAIN_CPU) {
return -EINVAL;
}
-/* check if bo is already referenced */
-for(i = 0; i cs-crelocs; i++) {
-idx = i * RELOC_SIZE;
-reloc = (struct cs_reloc_gem*)csg-relocs[idx];
-if (reloc-handle == bo-handle) {
-/* Check domains must be in read or write. As we check already
- * checked that in argument one of the read or write domain was
- * set we only need to check that if previous reloc as the read
- * domain set then the read_domain should also
[PATCH 1/2] libdrm: Move intel_atomic.h to libdrm core for sharing.
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
Makefile.am |2 +-
configure.ac |2 +-
intel/intel_atomic.h | 56 +-
xf86atomic.h | 93 ++
4 files changed, 96 insertions(+), 57 deletions(-)
create mode 100644 xf86atomic.h
diff --git a/Makefile.am b/Makefile.am
index ee3ccc7..295121f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -59,7 +59,7 @@ libdrm_la_SOURCES = \
libdrm_lists.h
libdrmincludedir = ${includedir}
-libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
+libdrminclude_HEADERS = xf86drm.h xf86drmMode.h xf86atomic.h
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/configure.ac b/configure.ac
index aaa8efa..953a758 100644
--- a/configure.ac
+++ b/configure.ac
@@ -198,7 +198,7 @@ if test x$INTEL != xno; then
])
if test x$drm_cv_atomic_primitives = xIntel; then
- AC_DEFINE(HAVE_INTEL_ATOMIC_PRIMITIVES, 1,
+ AC_DEFINE(HAVE_LIBDRM_ATOMIC_PRIMITIVES, 1,
[Enable if your compiler supports the Intel __sync_*
atomic primitives])
fi
if test x$drm_cv_atomic_primitives = xlibatomic-ops; then
diff --git a/intel/intel_atomic.h b/intel/intel_atomic.h
index 12bb96b..dcb4ec8 100644
--- a/intel/intel_atomic.h
+++ b/intel/intel_atomic.h
@@ -34,60 +34,6 @@
#ifndef INTEL_ATOMICS_H
#define INTEL_ATOMICS_H
-#ifdef HAVE_CONFIG_H
-#include config.h
-#endif
-
-#if HAVE_INTEL_ATOMIC_PRIMITIVES
-
-#define HAS_ATOMIC_OPS 1
-
-typedef struct {
- int atomic;
-} atomic_t;
-
-# define atomic_read(x) ((x)-atomic)
-# define atomic_set(x, val) ((x)-atomic = (val))
-# define atomic_inc(x) ((void) __sync_fetch_and_add ((x)-atomic, 1))
-# define atomic_dec_and_test(x) (__sync_fetch_and_add ((x)-atomic, -1) == 1)
-# define atomic_cmpxchg(x, oldv, newv) __sync_val_compare_and_swap
((x)-atomic, oldv, newv)
-
-#endif
-
-#if HAVE_LIB_ATOMIC_OPS
-#include atomic_ops.h
-
-#define HAS_ATOMIC_OPS 1
-
-typedef struct {
- AO_t atomic;
-} atomic_t;
-
-# define atomic_read(x) AO_load_full((x)-atomic)
-# define atomic_set(x, val) AO_store_full((x)-atomic, (val))
-# define atomic_inc(x) ((void) AO_fetch_and_add1_full((x)-atomic))
-# define atomic_dec_and_test(x) (AO_fetch_and_sub1_full((x)-atomic) == 1)
-# define atomic_cmpxchg(x, oldv, newv) AO_compare_and_swap_full((x)-atomic,
oldv, newv)
-
-#endif
-
-#if defined(__sun) !defined(HAS_ATOMIC_OPS) /* Solaris OpenSolaris */
-
-#include sys/atomic.h
-#define HAS_ATOMIC_OPS 1
-
-typedef struct { uint_t atomic; } atomic_t;
-
-# define atomic_read(x) (int) ((x)-atomic)
-# define atomic_set(x, val) ((x)-atomic = (uint_t)(val))
-# define atomic_inc(x) (atomic_inc_uint ((x)-atomic))
-# define atomic_dec_and_test(x) (atomic_dec_uint_nv((x)-atomic) == 1)
-# define atomic_cmpxchg(x, oldv, newv) atomic_cas_uint ((x)-atomic, oldv,
newv)
-
-#endif
-
-#if ! HAS_ATOMIC_OPS
-#error libdrm-intel requires atomic operations, please define them for your
CPU/compiler.
-#endif
+#include xf86atomic.h
#endif
diff --git a/xf86atomic.h b/xf86atomic.h
new file mode 100644
index 000..627dcf2
--- /dev/null
+++ b/xf86atomic.h
@@ -0,0 +1,93 @@
+/*
+ * Copyright © 2009 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Chris Wilson ch...@chris-wilson.co.uk
+ *
+ */
+
+/**
+ * @file intel_atomics.h
+ *
+ * Private definitions for atomic operations
+ */
+
+#ifndef LIBDRM_ATOMICS_H
+#define LIBDRM_ATOMICS_H
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#if HAVE_LIBDRM_ATOMIC_PRIMITIVES
+
+#define HAS_ATOMIC_OPS 1
+
+typedef struct {
+ int atomic;
+} atomic_t;
+
+# define atomic_read(x) ((x)-atomic)
+# define
Re: [PATCH 2/2] libdrm_radeon: Optimize reloc writing to do less looping.
On Wed, 2010-03-10 at 18:20 +0200, Pauli Nieminen wrote:
Bit has table will be first checked from BO if we can quarentee this BO is not
in this cs already.
To quarentee that there is no other cs with same id number of CS that can have
id is limited to 32. Adding and remocing reference in bo is done with atomic
operations to allow parallel access to a bo from multiple contexts.
This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
Signed-off-by: Pauli Nieminen suok...@gmail.com
[...]
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..83aabea 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -68,6 +69,66 @@ struct cs_gem {
struct radeon_bo_int**relocs_bo;
};
+
+#if !defined(__GNUC__) || __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__
2)
+/* no built in sync support in compiler define place holders */
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a += val;
+ return val;
+}
+
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a -= val;
+ return val;
+}
+#endif
This doesn't look like it could build... presumably the latter should be
called __sync_sub_and_fetch()?
Do these stand any chance of working properly in circumstances where
atomicity is actually important though?
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On 21 November 2009 05:27, Dave Airlie airl...@gmail.com wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? Yes it could work. No it doesn't work. Now if a user runs fbset, I'm not sure what the right answer is, a) pick a head in advance via sysfs maybe and set it on that. b) try and set the mode on both heads cloned (what to do if there is no common mode is another issue). I would say it's time to support multihead with fbset properly. That is people would need new fbset which sees both (all) heads, and fbset can then choose the head itself (and people can make it do something different when they don't like the default). It should also support setting up rotation on each head. For old fbset setting something visible is probably good enough. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. Before we go there you have to reflect on what the original reason was to have a framebuffer layer. The point to have a VT console terminal on platforms that lacked hardware that supported native text mode hardware. In other words had no vga text mode. A VT terminal is just a keyboard and a display. In fact in the old days you had to write framebuffer console drivers with things like con_putcs, con_write. Then the api was changed to make driver writing simple. The struct fb_info represented your graphics card. Of course at that time we also had hardware that supported more than one crtc which made things more complex. This was reflected in the new api. Struct fb_info was moved in the direction to represent the display. Remember the terminal only really cares about the display. Inside struct fb_info we have a void *par that was a pointer to some structure that represented the graphics card itself. So in the case of multi-head systems you could have two struct fb_info and one shared *par. That way if you wanted to changed the resolution on one screen the check_var function could using the *par to test if the hardware could support both resolutions at the same time. Note also there is exist a sysfs that allows you to migrate your second fbdev devices to a new terminal. Also problems exist in the upper console layers that prohibit true multi-desktop systems. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
My main problem with calling the drm underneath the fbdev is it seems like a layering violation. Then again some of code in the kernel is also contributing to this violation. I'd really like to make fbdev more like an in-kernel version of what X driver have to do, and leave all the initial modepicking etc to the fbdev interface layer. If we take the layering as fbcon - fbdev - kms - hw I feel calling ioctls on the KMS layer from userspace to do stuff for fbcon or fbdev is wrong, and we should rather expose a more intelligent set of ioctls via the fbdev device node. This points at quite a bit of typing. I agree. We had the same issue with fbdev and fbcon. From the fbcon layer you can call stty to change the resolution. In that case the mode change came from fbcon to fbdev. Easy problem to handle. Well some people still wanted to be able to able to change their console resolution with fbset. Not only change the resolution on one VC (virtual consoel) but in some cases change the resolution on all the VCs mapped to that fbdev. Now some times the user wanted to change the resolution for say a game (using SDL for example) and then expected the fbcon resolution to be restored when they exited. In that case we wanted the resolution change not to be propagated up to the fbcon layer. The way the fbdev changes are propagated with a notifier chain. Now the issue of mirroring is another thing which was never settled on. Considering now the KMS layer is not so bad as it seems. The fbdev emulation layer already changes the drm mode (fbdev - kms) plus in that case you get the benefit of automatically sending a signal to the fbcon layer to keep it in sync. In the case of kms - fbdev you need to update the fbdev state. This could be done pretty easily plus if done right would update the fbcon state as well. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org wrote: At the moment the problem with fbset is what to do with it in the dual head case. Currently we create an fb console that is lowest common size of the two heads and set native modes on both, Does that mean that fbset is supposed to work (set resolution) on drmfb? No we've never hooked it up but it could be made work. I had it to the point of almost working. I plan on working on getting it working again. Schemes which would make a multihead setup look like a single screen get complicated quite easily. Perhaps an option to turn off some outputs so that the native resolution of one output is used (instead of clone) would work. I've only really got two answer for this: (a) hook up another /dev/dri/card_fb device and use the current KMS ioctls to control the framebuffer, have the drm callback into fbdev/fbcon to mention resizes etc. Or add one or two info gathering ioctls and allow use of the /dev/dri/control device to control stuff. (b) add a lot of ioctls to KMS fbdev device, which implement some sort of sane multi-output settings. Now the second sounds like a lot of work if not the correct solution, you basically needs a way to pretty much expose what the KMS ioctls expose on the fb device, and then upgrade fbset to make sense of it all. Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. Only because that is the only way to do it. The other options was to have x86emul in the kernel. That was not going to happen. I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. Still would have to deal with the issue of keeping the graphical console in sync with the changes. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. Designing an unified multihead fbdev extension interface would probably take quite a bit of typing and time. It would also help to have something working to compare to. IMNSHO the fbdev to ctrc mapping should be the standard way to handle the fbdev layer. Plus it is a KISS approach. Mirroring would need to be finally dealt with. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] libdrm: Move intel_atomic.h to libdrm core for sharing.
On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen suok...@gmail.com wrote:
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
Makefile.am | 2 +-
configure.ac | 2 +-
intel/intel_atomic.h | 56 +-
xf86atomic.h | 93
++
4 files changed, 96 insertions(+), 57 deletions(-)
create mode 100644 xf86atomic.h
diff --git a/Makefile.am b/Makefile.am
index ee3ccc7..295121f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -59,7 +59,7 @@ libdrm_la_SOURCES = \
libdrm_lists.h
libdrmincludedir = ${includedir}
-libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
+libdrminclude_HEADERS = xf86drm.h xf86drmMode.h xf86atomic.h
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/configure.ac b/configure.ac
index aaa8efa..953a758 100644
--- a/configure.ac
+++ b/configure.ac
@@ -198,7 +198,7 @@ if test x$INTEL != xno; then
])
if test x$drm_cv_atomic_primitives = xIntel; then
- AC_DEFINE(HAVE_INTEL_ATOMIC_PRIMITIVES, 1,
+ AC_DEFINE(HAVE_LIBDRM_ATOMIC_PRIMITIVES, 1,
[Enable if your compiler supports the Intel __sync_*
atomic primitives])
fi
if test x$drm_cv_atomic_primitives = xlibatomic-ops; then
diff --git a/intel/intel_atomic.h b/intel/intel_atomic.h
index 12bb96b..dcb4ec8 100644
--- a/intel/intel_atomic.h
+++ b/intel/intel_atomic.h
@@ -34,60 +34,6 @@
#ifndef INTEL_ATOMICS_H
#define INTEL_ATOMICS_H
-#ifdef HAVE_CONFIG_H
-#include config.h
-#endif
-
-#if HAVE_INTEL_ATOMIC_PRIMITIVES
-
-#define HAS_ATOMIC_OPS 1
-
-typedef struct {
- int atomic;
-} atomic_t;
-
-# define atomic_read(x) ((x)-atomic)
-# define atomic_set(x, val) ((x)-atomic = (val))
-# define atomic_inc(x) ((void) __sync_fetch_and_add ((x)-atomic, 1))
-# define atomic_dec_and_test(x) (__sync_fetch_and_add ((x)-atomic, -1) ==
1)
-# define atomic_cmpxchg(x, oldv, newv) __sync_val_compare_and_swap
((x)-atomic, oldv, newv)
-
-#endif
-
-#if HAVE_LIB_ATOMIC_OPS
-#include atomic_ops.h
-
-#define HAS_ATOMIC_OPS 1
-
-typedef struct {
- AO_t atomic;
-} atomic_t;
-
-# define atomic_read(x) AO_load_full((x)-atomic)
-# define atomic_set(x, val) AO_store_full((x)-atomic, (val))
-# define atomic_inc(x) ((void) AO_fetch_and_add1_full((x)-atomic))
-# define atomic_dec_and_test(x) (AO_fetch_and_sub1_full((x)-atomic) == 1)
-# define atomic_cmpxchg(x, oldv, newv)
AO_compare_and_swap_full((x)-atomic, oldv, newv)
-
-#endif
-
-#if defined(__sun) !defined(HAS_ATOMIC_OPS) /* Solaris OpenSolaris */
-
-#include sys/atomic.h
-#define HAS_ATOMIC_OPS 1
-
-typedef struct { uint_t atomic; } atomic_t;
-
-# define atomic_read(x) (int) ((x)-atomic)
-# define atomic_set(x, val) ((x)-atomic = (uint_t)(val))
-# define atomic_inc(x) (atomic_inc_uint ((x)-atomic))
-# define atomic_dec_and_test(x) (atomic_dec_uint_nv((x)-atomic) == 1)
-# define atomic_cmpxchg(x, oldv, newv) atomic_cas_uint ((x)-atomic, oldv,
newv)
-
-#endif
-
-#if ! HAS_ATOMIC_OPS
-#error libdrm-intel requires atomic operations, please define them for your
CPU/compiler.
-#endif
+#include xf86atomic.h
#endif
diff --git a/xf86atomic.h b/xf86atomic.h
new file mode 100644
index 000..627dcf2
--- /dev/null
+++ b/xf86atomic.h
@@ -0,0 +1,93 @@
+/*
+ * Copyright © 2009 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Chris Wilson ch...@chris-wilson.co.uk
+ *
+ */
+
+/**
+ * @file intel_atomics.h
This needs to be updated.
+ *
+ * Private definitions for atomic operations
+ */
+
+#ifndef LIBDRM_ATOMICS_H
+#define
Re: [PATCH 2/2] libdrm_radeon: Optimize reloc writing to do less looping.
2010/3/10 Michel Dänzer mic...@daenzer.net:
On Wed, 2010-03-10 at 18:20 +0200, Pauli Nieminen wrote:
Bit has table will be first checked from BO if we can quarentee this BO is
not
in this cs already.
To quarentee that there is no other cs with same id number of CS that can
have
id is limited to 32. Adding and remocing reference in bo is done with atomic
operations to allow parallel access to a bo from multiple contexts.
This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
Signed-off-by: Pauli Nieminen suok...@gmail.com
[...]
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..83aabea 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -68,6 +69,66 @@ struct cs_gem {
struct radeon_bo_int **relocs_bo;
};
+
+#if !defined(__GNUC__) || __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__
2)
+/* no built in sync support in compiler define place holders */
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a += val;
+ return val;
+}
+
+uint32_t __sync_add_and_fetch(uint32_t *a, uint32_t val)
+{
+ *a -= val;
+ return val;
+}
+#endif
This doesn't look like it could build... presumably the latter should be
called __sync_sub_and_fetch()?
sorry .wrong patch coming from somewhere :/
Do these stand any chance of working properly in circumstances where
atomicity is actually important though?
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] libdrm_radeon: Optimize cs_gem_reloc to do less looping.
bo-referenced_in_cs is checked if bo is already in cs. Adding and removing
reference in bo is done with atomic operations to allow parallel access to a
bo from multiple contexts.
cs-id generation code quarentees there is not duplicated ids which limits
number of cs-ids to 32. If there is more cs objects rest will get id 0.
This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
radeon/radeon_bo_gem.c |1 +
radeon/radeon_bo_int.h |4 +-
radeon/radeon_cs.c |6 ++
radeon/radeon_cs.h |2 +-
radeon/radeon_cs_gem.c | 123
radeon/radeon_cs_int.h |1 +
xf86atomic.h |6 ++
7 files changed, 110 insertions(+), 33 deletions(-)
diff --git a/radeon/radeon_bo_gem.c b/radeon/radeon_bo_gem.c
index bc8058d..fb51f4a 100644
--- a/radeon/radeon_bo_gem.c
+++ b/radeon/radeon_bo_gem.c
@@ -80,6 +80,7 @@ static struct radeon_bo *bo_open(struct radeon_bo_manager
*bom,
bo-base.domains = domains;
bo-base.flags = flags;
bo-base.ptr = NULL;
+atomic_set(bo-base.referenced_in_cs, 0);
bo-map_count = 0;
if (handle) {
struct drm_gem_open open_arg;
diff --git a/radeon/radeon_bo_int.h b/radeon/radeon_bo_int.h
index 9589ead..9c0ae68 100644
--- a/radeon/radeon_bo_int.h
+++ b/radeon/radeon_bo_int.h
@@ -1,6 +1,8 @@
#ifndef RADEON_BO_INT
#define RADEON_BO_INT
+#include xf86atomic.h
+
struct radeon_bo_manager {
struct radeon_bo_funcs *funcs;
int fd;
@@ -17,7 +19,7 @@ struct radeon_bo_int {
unsignedcref;
struct radeon_bo_manager*bom;
uint32_tspace_accounted;
-uint32_treferenced_in_cs;
+atomic_treferenced_in_cs;
};
/* bo functions */
diff --git a/radeon/radeon_cs.c b/radeon/radeon_cs.c
index cc9be39..d0e922b 100644
--- a/radeon/radeon_cs.c
+++ b/radeon/radeon_cs.c
@@ -88,3 +88,9 @@ void radeon_cs_space_set_flush(struct radeon_cs *cs, void
(*fn)(void *), void *d
csi-space_flush_fn = fn;
csi-space_flush_data = data;
}
+
+uint32_t radeon_cs_get_id(struct radeon_cs *cs)
+{
+struct radeon_cs_int *csi = (struct radeon_cs_int *)cs;
+return csi-id;
+}
diff --git a/radeon/radeon_cs.h b/radeon/radeon_cs.h
index 49d5d9a..7f6ee68 100644
--- a/radeon/radeon_cs.h
+++ b/radeon/radeon_cs.h
@@ -85,7 +85,7 @@ extern int radeon_cs_write_reloc(struct radeon_cs *cs,
uint32_t read_domain,
uint32_t write_domain,
uint32_t flags);
-
+extern uint32_t radeon_cs_get_id(struct radeon_cs *cs);
/*
* add a persistent BO to the list
* a persistent BO is one that will be referenced across flushes,
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..ef5d3d5 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -32,6 +32,7 @@
#include assert.h
#include errno.h
#include stdlib.h
+#include pthread.h
#include sys/mman.h
#include sys/ioctl.h
#include radeon_cs.h
@@ -41,6 +42,7 @@
#include radeon_bo_gem.h
#include drm.h
#include xf86drm.h
+#include xf86atomic.h
#include radeon_drm.h
struct radeon_cs_manager_gem {
@@ -68,6 +70,50 @@ struct cs_gem {
struct radeon_bo_int**relocs_bo;
};
+static pthread_mutex_t id_mutex = PTHREAD_MUTEX_INITIALIZER;
+static uint32_t cs_id_source = 0;
+
+/**
+ * result is undefined if called with ~0
+ */
+static uint32_t get_first_zero(const uint32_t n)
+{
+/* __builtin_ctz returns number of trailing zeros. */
+return 1 __builtin_ctz(~n);
+}
+
+/**
+ * Returns a free id for cs.
+ * If there is no free id we return zero
+ **/
+static uint32_t generate_id(void)
+{
+uint32_t r = 0;
+pthread_mutex_lock( id_mutex );
+/* check for free ids */
+if (cs_id_source != ~r) {
+/* find first zero bit */
+r = get_first_zero(cs_id_source);
+
+/* set id as reserved */
+cs_id_source |= r;
+}
+pthread_mutex_unlock( id_mutex );
+return r;
+}
+
+/**
+ * Free the id for later reuse
+ **/
+static void free_id(uint32_t id)
+{
+pthread_mutex_lock( id_mutex );
+
+cs_id_source = ~id;
+
+pthread_mutex_unlock( id_mutex );
+}
+
static struct radeon_cs_int *cs_gem_create(struct radeon_cs_manager *csm,
uint32_t ndw)
{
@@ -90,6 +136,7 @@ static struct radeon_cs_int *cs_gem_create(struct
radeon_cs_manager *csm,
}
csg-base.relocs_total_size = 0;
csg-base.crelocs = 0;
+csg-base.id = generate_id();
csg-nrelocs = 4096 / (4 * 4) ;
csg-relocs_bo = (struct radeon_bo_int**)calloc(1,
csg-nrelocs*sizeof(void*));
@@ -141,38 +188,45 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
if (write_domain == RADEON_GEM_DOMAIN_CPU) {
return
[PATCH 1/2] libdrm: Move intel_atomic.h to libdrm core for sharing. (V2)
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
V2: Fix remaining references to intel_atomic.h and libdrm-intel.
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
Makefile.am |2 +-
configure.ac |2 +-
intel/intel_atomic.h | 56 +-
xf86atomic.h | 93 ++
4 files changed, 96 insertions(+), 57 deletions(-)
create mode 100644 xf86atomic.h
diff --git a/Makefile.am b/Makefile.am
index ee3ccc7..295121f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -59,7 +59,7 @@ libdrm_la_SOURCES = \
libdrm_lists.h
libdrmincludedir = ${includedir}
-libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
+libdrminclude_HEADERS = xf86drm.h xf86drmMode.h xf86atomic.h
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/configure.ac b/configure.ac
index aaa8efa..953a758 100644
--- a/configure.ac
+++ b/configure.ac
@@ -198,7 +198,7 @@ if test x$INTEL != xno; then
])
if test x$drm_cv_atomic_primitives = xIntel; then
- AC_DEFINE(HAVE_INTEL_ATOMIC_PRIMITIVES, 1,
+ AC_DEFINE(HAVE_LIBDRM_ATOMIC_PRIMITIVES, 1,
[Enable if your compiler supports the Intel __sync_*
atomic primitives])
fi
if test x$drm_cv_atomic_primitives = xlibatomic-ops; then
diff --git a/intel/intel_atomic.h b/intel/intel_atomic.h
index 12bb96b..dcb4ec8 100644
--- a/intel/intel_atomic.h
+++ b/intel/intel_atomic.h
@@ -34,60 +34,6 @@
#ifndef INTEL_ATOMICS_H
#define INTEL_ATOMICS_H
-#ifdef HAVE_CONFIG_H
-#include config.h
-#endif
-
-#if HAVE_INTEL_ATOMIC_PRIMITIVES
-
-#define HAS_ATOMIC_OPS 1
-
-typedef struct {
- int atomic;
-} atomic_t;
-
-# define atomic_read(x) ((x)-atomic)
-# define atomic_set(x, val) ((x)-atomic = (val))
-# define atomic_inc(x) ((void) __sync_fetch_and_add ((x)-atomic, 1))
-# define atomic_dec_and_test(x) (__sync_fetch_and_add ((x)-atomic, -1) == 1)
-# define atomic_cmpxchg(x, oldv, newv) __sync_val_compare_and_swap
((x)-atomic, oldv, newv)
-
-#endif
-
-#if HAVE_LIB_ATOMIC_OPS
-#include atomic_ops.h
-
-#define HAS_ATOMIC_OPS 1
-
-typedef struct {
- AO_t atomic;
-} atomic_t;
-
-# define atomic_read(x) AO_load_full((x)-atomic)
-# define atomic_set(x, val) AO_store_full((x)-atomic, (val))
-# define atomic_inc(x) ((void) AO_fetch_and_add1_full((x)-atomic))
-# define atomic_dec_and_test(x) (AO_fetch_and_sub1_full((x)-atomic) == 1)
-# define atomic_cmpxchg(x, oldv, newv) AO_compare_and_swap_full((x)-atomic,
oldv, newv)
-
-#endif
-
-#if defined(__sun) !defined(HAS_ATOMIC_OPS) /* Solaris OpenSolaris */
-
-#include sys/atomic.h
-#define HAS_ATOMIC_OPS 1
-
-typedef struct { uint_t atomic; } atomic_t;
-
-# define atomic_read(x) (int) ((x)-atomic)
-# define atomic_set(x, val) ((x)-atomic = (uint_t)(val))
-# define atomic_inc(x) (atomic_inc_uint ((x)-atomic))
-# define atomic_dec_and_test(x) (atomic_dec_uint_nv((x)-atomic) == 1)
-# define atomic_cmpxchg(x, oldv, newv) atomic_cas_uint ((x)-atomic, oldv,
newv)
-
-#endif
-
-#if ! HAS_ATOMIC_OPS
-#error libdrm-intel requires atomic operations, please define them for your
CPU/compiler.
-#endif
+#include xf86atomic.h
#endif
diff --git a/xf86atomic.h b/xf86atomic.h
new file mode 100644
index 000..de8e220
--- /dev/null
+++ b/xf86atomic.h
@@ -0,0 +1,93 @@
+/*
+ * Copyright © 2009 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Chris Wilson ch...@chris-wilson.co.uk
+ *
+ */
+
+/**
+ * @file xf86atomics.h
+ *
+ * Private definitions for atomic operations
+ */
+
+#ifndef LIBDRM_ATOMICS_H
+#define LIBDRM_ATOMICS_H
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#if HAVE_LIBDRM_ATOMIC_PRIMITIVES
+
+#define HAS_ATOMIC_OPS 1
+
+typedef struct {
+ int atomic;
+}
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Ah, the power of flags. We had the same issue with user requesting a mode change or fbcon asking for a different mode. We handled it with the flag FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will have to deal also with the ability to change the resolution with tools like stty. I can easily see how to do this plus give you more memory like you want :-) For the oops are you talking about printing oops to the screen while X is running ? Otherwise if you experience a oops and go back to console mode you should be able to view it. The console text buffer is independent of the graphics card memory system. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26997] New: r600: broken mipmap generation
http://bugs.freedesktop.org/show_bug.cgi?id=26997 Summary: r600: broken mipmap generation 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: wielkie...@gmail.com Automatic mipmap generation (by setting GL_MIPMAP_GENERATION texture parameter to GL_TRUE) with r600_dri is broken when texture dimensions are not powers of two. Level 0 mipmap (original image) is right, but another levels contain garbage. When minification filter is set to some mipmap mode, it clearly shows this issue. Changing texture dimensions to powers of two resolves the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 1:47 PM, James Simmons jsimm...@infradead.org wrote: Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. The only problem with that is that it eats a lot of memory for the console which limits X when it starts. On cards with limited vram , you might not have enough memory left for any meaningful acceleration when X starts. It would be nice to find a way to reclaim the console memory for X, but I'm not sure that can be done and still provide a good way to provide oops support. Ah, the power of flags. We had the same issue with user requesting a mode change or fbcon asking for a different mode. We handled it with the flag FBINFO_MISC_USEREVENT. Since you are using KMS as the backend for fbcon you will have to deal also with the ability to change the resolution with tools like stty. I can easily see how to do this plus give you more memory like you want :-) For the oops are you talking about printing oops to the screen while X is running ? Otherwise if you experience a oops and go back to console mode you should be able to view it. The console text buffer is independent of the graphics card memory system. Right now we keep the console buffer pinned in vram and we switch to it when there is an oops or when you switch VTs. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote: I don't think so. There is another driver which does this - vesa/uvesa. For these it is not possible to change the resolution from fbdev, it just provides some framebuffer on top of which fb applications or fbcons run. Only because that is the only way to do it. The other options was to have x86emul in the kernel. That was not going to happen. I guess equivalent of xrandr would be what people would want but the current fbdev capabilities are far from that. Since KMS provides these capabilities already I would think adding a tool that manipulates KMS directly (kmset?) is the simplest way. Still would have to deal with the issue of keeping the graphical console in sync with the changes. There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. omapfb is another multihead fb driver and it's more complex than matroxfb. Trying to make it perform various tricks through the fbdev API (and a bunch of custom ioctls, and a bunch of sysfs knobs) is something I've been doing but I would not recommend it for anyone who has the option of using a better API. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Wednesday 10 March 2010, Matthew Garrett wrote: As far as the ACPI video driver goes, acpi_get_physical_pci_device() will give you something to work with. Hmm. Did you mean acpi_get_physical_device()? Which acpi_device should I call that for? For the console-switching case, I think the most reasonable plan is probably to add a flag to the console drivers to indicate whether or not they support reprogramming the hardware themselves, and then walk all active console drivers. There'd need to be a way for fb drivers to tell fbcon that they can handle it. Yes, that sounds reasonable. Rafael -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix pal tv-out support on legacy IGP chips
From b2757f48c0c45ff08934d125b913777b8adaee0b Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 10 Mar 2010 18:33:03 -0500
Subject: [PATCH] drm/radeon/kms: fix pal tv-out support on legacy IGP chips
Based on ddx patch by Andrzej Hajda.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_legacy_tv.c | 29 -
1 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
index fdce15b..0320403 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -57,6 +57,10 @@
#define NTSC_TV_PLL_N_14 693
#define NTSC_TV_PLL_P_14 7
+#define PAL_TV_PLL_M_14 19
+#define PAL_TV_PLL_N_14 353
+#define PAL_TV_PLL_P_14 5
+
#define VERT_LEAD_IN_LINES 2
#define FRAC_BITS 0xe
#define FRAC_MASK 0x3fff
@@ -205,9 +209,24 @@ static const struct radeon_tv_mode_constants
available_tv_modes[] = {
630627, /* defRestart */
347,/* crtcPLL_N */
14, /* crtcPLL_M */
- 8, /* crtcPLL_postDiv */
+ 8, /* crtcPLL_postDiv */
1022, /* pixToTV */
},
+ { /* PAL timing for 14 Mhz ref clk */
+ 800,/* horResolution */
+ 600,/* verResolution */
+ TV_STD_PAL, /* standard */
+ 1131, /* horTotal */
+ 742,/* verTotal */
+ 813,/* horStart */
+ 840,/* horSyncStart */
+ 633,/* verSyncStart */
+ 708369, /* defRestart */
+ 211,/* crtcPLL_N */
+ 9, /* crtcPLL_M */
+ 8, /* crtcPLL_postDiv */
+ 759,/* pixToTV */
+ },
};
#define N_AVAILABLE_MODES ARRAY_SIZE(available_tv_modes)
@@ -242,7 +261,7 @@ static const struct radeon_tv_mode_constants
*radeon_legacy_tv_get_std_mode(stru
if (pll-reference_freq == 2700)
const_ptr = available_tv_modes[1];
else
- const_ptr = available_tv_modes[1]; /* FIX ME */
+ const_ptr = available_tv_modes[3];
}
return const_ptr;
}
@@ -685,9 +704,9 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
n = PAL_TV_PLL_N_27;
p = PAL_TV_PLL_P_27;
} else {
- m = PAL_TV_PLL_M_27;
- n = PAL_TV_PLL_N_27;
- p = PAL_TV_PLL_P_27;
+ m = PAL_TV_PLL_M_14;
+ n = PAL_TV_PLL_N_14;
+ p = PAL_TV_PLL_P_14;
}
}
--
1.5.6.3
0001-drm-radeon-kms-fix-pal-tv-out-support-on-legacy-IGP.patch
Description: application/mbox
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. Yes the mapping issue were never address. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. Actually that is what I had in mind when I reworked the fbdev api. Plus with the linux console project I got multiple VTs working at the same time. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. Not true. You can map different displays to different vcs. Give con2fb a try some time :-) Now there is the issue of more than one keyboard being mapped at a time. BTW I did getting multipe VT working at the same time working in the past. It requires some cleanup on the console layer. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. I guess it's also possible that somebody would want the fbdev/fbcons cover multiple screens. This is not particularly useful with fbcons (although curses WMs exist) but might be somewhat useful for graphical fbdev applications. I really can't see fbcon need that. Multiple views of the kernel virtual consoles on different heads might be nice toy but it's probably too hard to be worth trying. And there are always applications like jfbterm which could be perhaps slightly adapted to use one of the other devices instead of a vc. It already exist. I guess it is one of those best kept secrets. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Yuck. See my other post about what fbdev really means in its historical context. The struct fb_info really maps better to drm_crtc than to drm_framebuffer. In fact take the case of the matrox fbdev driver. It creates two framebuffer devices even tho it used one static framebuffer. What the driver does is splits the framebuffer in two and assigned each part to a CRTC. So you get the layering naturally. On fbset - fbev layer you can choose from the resolutions available in the current output setup, in kmset or whatever - drm layer you can set up the outputs, merge multiple outputs into single cloned fbdev or separate them, .. It's obviously nice if you can set the resolution on all of fbcons, fbdev and drm layers but getting it work on at least one layer with proper propagation up and down also works. BTW I don't know any application which sets linux console (or xterm for that matter) resolution through the terminal API. I agree. The mode setting should be done in one layer. Its a matter of doing the proper emulation of the fbdev layer. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
My goal
Okay all the discussion about multiple display brings me to why I'm doing this. I'm attempting to revive the linux console project. I'm in a position to again work on this project. About 4 years ago the eproject managed to get multi-seat working. My goal is to get there again. My first goal is to get my netbook to act has a multiseat system for two. With a plugged in external montior and a USB keyboard run two concurrent X sessions both running OpenGL applications at the same time. I set out to do this 10 years ago and I want to finally accomplish this. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: My goal
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons jsimm...@infradead.org wrote: Okay all the discussion about multiple display brings me to why I'm doing this. I'm attempting to revive the linux console project. I'm in a position to again work on this project. About 4 years ago the eproject managed to get multi-seat working. My goal is to get there again. My first goal is to get my netbook to act has a multiseat system for two. With a plugged in external montior and a USB keyboard run two concurrent X sessions both running OpenGL applications at the same time. I set out to do this 10 years ago and I want to finally accomplish this. Hi James, I had a plan (with a picture) but we lost the picture in a disk crash. But it basically sounded like this. Currently we have two device nodes per drm device, a control node and a legacy card node. The control node is there in theory to support multi-seat. The plan was some sort of userspace multi-seat manager (in gdm or otherwise), would use the control node to divide up the modesetting resources and create a number of seat nodes. These seat nodes would operate like the current legacy node except they would only show the user the modesetting resources assigned to them. The control node could also be used to create a node with no mode resources for GPGPU work. You can see the start of this in the drm, look for mode_group. Once the kernel was generating the seat nodes, it would be a matter of giving that path to the X server KMS driver and it would open that instead of the legacy device node, and same for the second X server. This would require of course starting X servers with -sharevts and -novtswitch most likely. Dave. , -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Thu, Mar 11, 2010 at 02:22:14AM +, James Simmons wrote: There are other drivers that support multihead already (matroxfb, any other?) and have their own driver-specific inteface. Each crtc is treated as a seperate fbdev device. I don't recall any special ioctls. Maybe for mirroring which was never standardized. matroxfb does have a bunch of custom ioctls to change the crtc-output mapping. Yes the mapping issue were never address. I don't think the CRTC=fb_info makes much sense if the main use case is fbcon. Actually that is what I had in mind when I reworked the fbdev api. Plus with the linux console project I got multiple VTs working at the same time. fbcon will use a single fb device and so you can't see the console on multiple heads anyway which makes the whole thing somewhat pointless. And if you're trying to do something more complex you will be a lot better off bypassing fbdev altogether. Not true. You can map different displays to different vcs. Give con2fb a try some time :-) I know about it but only one VT can be active at any given time. Now there is the issue of more than one keyboard being mapped at a time. BTW I did getting multipe VT working at the same time working in the past. It requires some cleanup on the console layer. Well if you think that cleanup is possible and worth the effort then it might make sense. The crtc-output mapping is still unresolved though and it depends on hardware which combinations are supported. If for example the hardware can't drive multiple outputs with the same CRTC or if the outputs require totally different timings then you can't clone the same VT to multiple outputs. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Regression in i915 on 2.6.34-rc1
Dear Dave and others: I seem to hit a sudden regression in 2.6.34-rc1: the modeset fails. On this box it also means, no way to start X, which is unfortunate. Here's a quote from bad dmesg (truncated front and back for brievity): Linux agpgart interface v0.103 agpgart-intel :00:00.0: Intel HD Graphics Chipset agpgart-intel :00:00.0: detected 131068K stolen memory agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000 tpm_tis 00:09: 1.2 TPM (device-id 0xB, rev-id 16) Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled udev: starting version 151 [drm] Initialized drm 1.1.0 20060810 i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 i915 :00:02.0: setting latency timer to 64 alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 i915 :00:02.0: irq 33 for MSI/MSI-X [drm] set up 127M of stolen space [drm:i915_gem_init_ringbuffer] *ERROR* Ring head not reset to zero ctl head tail start [drm:i915_gem_init_ringbuffer] *ERROR* Ring head forced to zero ctl head tail start [drm:i915_gem_init_ringbuffer] *ERROR* Ring initialization failed ctl head tail start [drm:i915_driver_load] *ERROR* failed to init modeset i915: probe of :00:02.0 failed with error -5 dracut: Starting plymouth daemon Here's old one from 2.6.33: Linux agpgart interface v0.103 agpgart-intel :00:00.0: Intel Ironlake/D Chipset agpgart-intel :00:00.0: detected 131068K stolen memory agpgart-intel :00:00.0: AGP aperture is 256M @ 0xd000 [drm] Initialized drm 1.1.0 20060810 Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled .. ACPI: Power Button [PWRF] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 i915 :00:02.0: setting latency timer to 64 i915 :00:02.0: irq 31 for MSI/MSI-X [drm] set up 127M of stolen space Console: switching to colour frame buffer device 210x65 fb0: inteldrmfb frame buffer device registered panic notifier [Firmware Bug]: ACPI: ACPI brightness control misses _BQC function acpi device:1d: registered as cooling_device5 input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input3 ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 dracut: Starting plymouth daemon So... No idea what went bad, so far, sorry. I'll try to bisect or otherwise find out. Just letting you know. -- Pete -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27009] New: [REGR] radeon_tex_copy.c:73: do_copy_texsubimage: Assertion `rrb rrb-bo' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=27009 Summary: [REGR] radeon_tex_copy.c:73: do_copy_texsubimage: Assertion `rrb rrb-bo' failed. Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: zaj...@gmail.com CC: m.cenc...@gmail.com Get it on starting The Sims 3. Reverting fixes it. I use r600, but that's general probably? commit a68e8a4eaadfe2a1e4999d5e378c7d9fa99dc656 Author: Maciej Cencora m.cenc...@gmail.com Date: Wed Mar 10 20:53:21 2010 +0100 radeon: fix glCopyTex(Sub)Image if user FBO is bound Fixes piglit/fbo-blit and wine d3d9 unit test. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 27009] [REGR] radeon_tex_copy.c:73: do_copy_texsubimage: Assertion `rrb rrb-bo' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=27009 --- Comment #1 from Rafał Miłecki zaj...@gmail.com 2010-03-10 23:44:58 PST --- I performed make realclean make distclean before every compilation. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
