Re: New proposed DRM interface design
On Sunday, September 5, 2004 8:31 am, Alan Cox wrote:
The only glue structure you need for most of this is
struct fb_device
{
struct fb_info *fb; /* NULL or frame buffer device */
struct dri_whatever *dri; /* As yet not nicely extracted DRI
object */
atomic_t refcnt;
void *private
};
Right now the drvdata for most PCI/AGP frame buffers is set to the
fb_info. If that is set to the shared object then you can attach DRI and
or FB first and they can find and call each others methods.
It might also need a single lock just to avoid DRI deciding to go away
while fb is calling dri and the reverse although I think the refcnt is
easier and cheaper.
With that in place if X tells DRI 640x480 starting here then DRI can
tell fb 640x480 starting here. Similarly fb and dri can find each
other for acceleration and the kernel can become a DRI client for
console acceleration.
Once you have this object you can start attaching memory managers and
mode setup pointers to the shared structure so that they live
independantly.
So then this structure would represent a merged driver? That is, you'd have a
driver that attaches to display devices and creates this structure to manage
fb and dri?
Jesse
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
On Monday, September 13, 2004 11:11 am, Jon Smirl wrote: The IA64 people want a file/ioctl interface on the /dev/vga0 devices so that they can issue control calls to the active device in each VGA space I think ppc and sparc want this too, we'll use it for issuing legacy in/out. Thanks, Jesse --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [SDL] [PATCH] fix FB_VideoQuit for ia64
On Sunday, January 16, 2005 2:24 pm, Stephane Marchesin wrote: Jesse Barnes wrote: I figured other projects might have similar problems, thanks for checking dri. Please note that I didn't actually check the dri. I just happened to get an MCA from time to time at mesa solo startup and your post on the SDL list showed a possible reason to me. I already audited the xserver tree (not Xorg, but xserver, the one with kdrive and the other simple X servers) and it seems ok. So, I looked at the radeon r200 dri drivers and found no other suspicious memset. Can't really say for others drivers since I'm not too confident in my understanding of these. Btw, will this happen only with memset (and not with memcpy for example) ? I think any of the highly optimized mem* routines will do it. I don't know the exact cause offhand though--might be prefetching or multiword accesses or something. Jesse --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 2419] New: Solo crashes on ia64 on startup
On Saturday, January 29, 2005 4:38 pm, [EMAIL PROTECTED] wrote: When I use solo on ia64, it sometimes causes an MCA upon startup. That's because a memset is done on the framebuffer memory during init. Please refer to this message from Jesse Barnes to know why this is bad : http://sourceforge.net/mailarchive/forum.php?thread_id=6354420forum_id=717 7 Here is a patch that fixes this by changing the memset into a for() loop doing memory access one byte at a time : http://icps.u-strasbg.fr/~marchesin/dri/ia64_solo_memset.patch Is it just radeon that suffers from this problem? How about r128 or the other drivers? (I don't have the tree in front of me just now or I'd do a quick audit.) Thanks, Jesse --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 2419] New: Solo crashes on ia64 on startup
On Monday, January 31, 2005 12:00 pm, Stephane Marchesin wrote: Yes, other drivers suffer from that too (at least r128, i810 and mga as far as I can see). However, as I said previously I don't understand them enough to touch them. Oh, I must have missed that message, sorry. It sure looks like the r128 case is almost exactly the same as the one you fixed in the radeon driver, in fact your patch almost applies but for the small amount of radeon specific context in it. i810 actually looks like it has the memset #if 0'd out, so is probably safe. And mga again looks nearly identical to the radeon case. Why don't we fix them all up at once? Jesse --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote: Stephane Marchesin wrote: Hi, I upgraded drm (non core) to current cvs (previous one was from 2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the module I get : [drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! Ok, it looks like drm cvs (core and non core) has been broken on ia64 since august. Patch attached. What is this code trying to do anyway? It looks like it's checking for overflow and trying to make sure that the offset is in I/O space? Are those checks really necessary? It also looks like drm_addbufs_pci uses virt_to_bus, which won't work on many non-x86 platforms. Hmm... the version in latest 2.6 kernel tree doesn't seem to have these problems, which one is the master copy? Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] fix write combining on ia64
Some ia64 platforms may not support write combining on all type of memory, so we need to consult the EFI memory map before we try to set the write combine attribute of a page. This patch will try to map a page write combined if it's not an AGP page and the EFI memory map says it's ok, otherwise it falls back to a regular, uncached mapping. Can someone please apply this to the drm tree? Thanks, Jesse Index: drm_vm.c === RCS file: /cvs/dri/drm/linux-core/drm_vm.c,v retrieving revision 1.49 diff -u -p -r1.49 drm_vm.c --- drm_vm.c12 Jan 2005 16:07:49 - 1.49 +++ drm_vm.c4 Mar 2005 19:03:31 - @@ -639,9 +639,13 @@ int drm_mmap(struct file *filp, struct v vma-vm_flags |= VM_IO; /* not in core dump */ } #if defined(__ia64__) - if (map-type != _DRM_AGP) + if (efi_range_is_wc(vma-vm_start, vma-vm_end - + vma-vm_start) (map-type != _DRM_AGP)) vma-vm_page_prot = - pgprot_writecombine(vma-vm_page_prot); + pgprot_writecombine(vma-vm_page_prot); + else + vma-vm_page_prot = + pgprot_noncached(vma-vm_page_prot); #endif offset = dev-driver-get_reg_ofs(dev); #ifdef __sparc__
Re: no scatter/gather memory ?
On Friday, March 4, 2005 10:31 am, Jesse Barnes wrote:
Seems like we need something like this instead?
Index: linux-core/drm_dma.c
===
RCS file: /cvs/dri/drm/linux-core/drm_dma.c,v
retrieving revision 1.39
diff -u -r1.39 drm_dma.c
--- linux-core/drm_dma.c31 Oct 2004 15:16:44 - 1.39
+++ linux-core/drm_dma.c4 Mar 2005 18:29:03 -
@@ -141,6 +141,9 @@
buf-filp = NULL;
buf-used = 0;
+ pci_unmap_page(dev-pdev, buf-bus_address, buf-total,
+ PCI_DMA_FROMDEVICE);
+
This is wrong since we may get here with AGP or other memory that wasn't
pci_map*'d in the first place. It should also use pci_unmap_single instead.
if (drm_core_check_feature(dev, DRIVER_DMA_QUEUE)
waitqueue_active(buf-dma_wait)) {
wake_up_interruptible(buf-dma_wait);
Index: linux-core/drm_bufs.c
===
RCS file: /cvs/dri/drm/linux-core/drm_bufs.c,v
retrieving revision 1.54
diff -u -r1.54 drm_bufs.c
--- linux-core/drm_bufs.c 5 Feb 2005 08:00:14 - 1.54
+++ linux-core/drm_bufs.c 4 Mar 2005 18:29:04 -
@@ -752,7 +752,9 @@
buf-used = 0;
buf-offset = (dma-byte_count + byte_count +
offset); buf-address = (void *)(page + offset);
- buf-bus_address = virt_to_bus(buf-address);
+ buf-bus_address = pci_map_page(dev-pdev, page,
offset, + buf-total,
+ PCI_DMA_TODEVICE);
buf-next = NULL;
This should be pci_map_single instead I think, since the buffer may be more
than one page like you said?
buf-bus_address = pci_map_single(dev-pdev,
bus-address,
buf-total,
PCI_DMA_BIDIRECTIONAL);
Jesse
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] use DRM_SOURCE_PATH from environment if available
This simple patch makes it a little easier to build against arbitrary drm trees. It'll pull in DRM_SOURCE_PATH from the environment if set, otherwise it'll default to it's current value. Jesse Index: configs/default === RCS file: /cvs/mesa/Mesa/configs/default,v retrieving revision 1.12 diff -u -r1.12 default --- configs/default 8 Dec 2004 15:16:36 - 1.12 +++ configs/default 4 Mar 2005 20:55:38 - @@ -11,7 +11,7 @@ MESA_TINY=0 # external projects -DRM_SOURCE_PATH=$(TOP)/../drm +DRM_SOURCE_PATH ?= $(TOP)/../drm # Compiler and flags CC = cc --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Trouble building linux-solo-ia64
I got this error when I tried to build linux-solo-ia64: gcc -c -I. -I../../../include -I../../../src/mesa -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/math -I../../../src/mesa/transform -I../../../src/mesa/swrast -I../../../src/mesa/swrast_setup -I../../../src/mesa/drivers/dri/common -I/home/jbarnes/working/r300/r300_driver/drm/libdrm -I/home/jbarnes/working/r300/r300_driver/drm/shared -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE-D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_GNU_SOURCE -DGLX_DIRECT_RENDERING -Wmissing-prototypes -g -std=c99 -Wundef -fPIC -ffast-math -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_GNU_SOURCE -DGLX_DIRECT_RENDERING ../../../src/mesa/drivers/dri/common/glcontextmodes.c -o ../../../src/mesa/drivers/dri/common/glcontextmodes.o ../../../src/mesa/drivers/dri/common/glcontextmodes.c:38:28: dri_interface.h: No such file or directory make[3]: *** [../../../src/mesa/drivers/dri/common/glcontextmodes.o] Error 1 make[3]: Leaving directory `/home/jbarnes/working/dri/Mesa/src/glx/mini' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/jbarnes/working/dri/Mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/jbarnes/working/dri/Mesa' make: *** [linux-solo-ia64] Error 2 So I modified src/glx/mini/Makefile to -Iinclude/GL/internal, is that the right fix? Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
On Friday, March 04, 2005 6:01 pm, Roland Scheidegger wrote: Paul Mackerras wrote: Note that that check is also wrong for ppc64. I think it is going to be wrong for most 64-bit platforms, since it is assuming that you can never have ram at a higher physical address than any I/O devices. On 64-bit platforms it is quite common to have some ram and some I/O below 4GB, and some more ram above 4GB. I don't see why we need the check anyway, unless some architecture (x86?) will actually panic if you try to ioremap a physical address that is below virt_to_phys(high_memory) or something. Wouldn't this check even break on x86 with PAE? Those boxes certainly have parts of their ram mapped above io memory too. Or does that high_memory variable stay below 4GB with PAE? I think the start of high memory will stay below 4G, but the check should probably be removed anyway. If we really want to make sure that a given offset is in I/O space, we should check that explicitly, and not rely on some 'top of real memory' type variable, since that's inherently non-portable. Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
more mesa-solo trouble w/r300 on ia64
Ok, so I've applied Stephane's fixes and sample_server comes up and miniglxtest no longer segfaults. However, after setting the mode, sample_server seems to die and wedge my display. miniglxtest just fails right away with this message: [EMAIL PROTECTED] miniglx]$ ./miniglxtest [miniglx] probed chipset 0x4e4b CreateNotify Authorize - magic 1 Unknown device ID 4E4B, please report. Assuming plain R300. Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes) *WARN_ONCE* File r300_state.c function r300Enable line 516 Don't know how to enable polygon offset point/line. Help me ! *** MapRequest Hang on... drawing 6 frames Redraw event drmRadeonCmdBuffer: -22 (exiting) DestroyNotify My system long indicates that radeon_do_cleanup_cp is failing when it calls drm_ati_pcigart_cleanup, then the card hangs. I have to hard reboot to get my machine back since sample_server isn't killable. Call Trace: [a001fc00] show_stack+0x80/0xa0 sp=e0b07232fbf0 bsp=e0b0723290f8 [a001fc50] dump_stack+0x30/0x60 sp=e0b07232fdc0 bsp=e0b0723290e0 [a002052a9cb0] drm_ati_pcigart_cleanup+0x1b0/0x200 [drm] sp=e0b07232fdc0 bsp=e0b0723290a0 [a00205193530] radeon_do_cleanup_cp+0xb0/0x240 [radeon] sp=e0b07232fdc0 bsp=e0b072329078 [a00205195d50] radeon_do_release+0x1d0/0x2e0 [radeon] sp=e0b07232fdc0 bsp=e0b072329040 [a002051ae8b0] radeon_driver_pretakedown+0x30/0x60 [radeon] sp=e0b07232fdc0 bsp=e0b072329020 [a0020529bd00] drm_takedown+0x380/0xa00 [drm] sp=e0b07232fdc0 bsp=e0b072328fc0 [a0020529ecb0] drm_release+0x910/0x1160 [drm] sp=e0b07232fdc0 bsp=e0b072328f38 [a00100140290] __fput+0x310/0x320 sp=e0b07232fe20 bsp=e0b072328ee8 [a001001402e0] fput+0x40/0x60 sp=e0b07232fe30 bsp=e0b072328ec8 [a0010013cf00] filp_close+0xc0/0x1a0 sp=e0b07232fe30 bsp=e0b072328e98 [a0010013d130] sys_close+0x150/0x1a0 sp=e0b07232fe30 bsp=e0b072328e20 [a001aa60] ia64_ret_from_syscall+0x0/0x20 sp=e0b07232fe30 bsp=e0b072328e20 [a0010640] __kernel_syscall_via_break+0x0/0x20 sp=e0b07233 bsp=e0b072328e20 [drm:drm_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! radeonfb: FIFO Timeout ! radeonfb: Idle Timeout ! radeonfb: FIFO Timeout ! radeonfb: Idle Timeout ! The above stack trace is due to a dump_stack I put in the error path right before no scatter/gather memory is printed in drm_ati_pcigart_cleanup(). Anything I should try before digging into the source a little further? Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: more mesa-solo trouble w/r300 on ia64
On Tuesday, March 8, 2005 12:01 am, Vladimir Dergachev wrote: Hi Jesse ! On Mon, 7 Mar 2005, Jesse Barnes wrote: Ok, so I've applied Stephane's fixes and sample_server comes up and miniglxtest no longer segfaults. However, after setting the mode, sample_server seems to die and wedge my display. miniglxtest just fails right away with this message: [EMAIL PROTECTED] miniglx]$ ./miniglxtest [miniglx] probed chipset 0x4e4b CreateNotify Authorize - magic 1 Unknown device ID 4E4B, please report. Assuming plain R300. ^ This is a bit odd - if the r300 driver does not know about the device why does the DRM driver load ? Also, are you using the drm driver from r300.sf.net ? The message below (error -22) might be indicative of wrong drm driver, try to insmod it with explicit path, like this: insmod ./drm.ko insmod ./radeon.ko Yeah, I'm using that driver and it seems to work ok with recent X.org bits (modulo some tiling issues that I saw--though sroland said that was to be expected on the particular tree I'm running). I'm updating my X tree now to see if that goes away. As for the solo stuff, Stephane suggested that I might have to port some of the X DDX bits to the solo driver code (mostly 2d setup stuff I guess?), could that explain what I'm seeing? Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] r300 warning fixes
This small patch fixes some warnings I saw when building on ia64. I think
it's safe to apply. It just moves some of the RING_LOCALS macros to below
the local stack variables to avoid mixing code declarations warnings and
adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets pulled
in.
Thanks,
Jesse
Index: drm/linux-core/drm_memory.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_memory.h,v
retrieving revision 1.2
diff -u -r1.2 drm_memory.h
--- drm/linux-core/drm_memory.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_memory.h 8 Mar 2005 18:40:03 -
@@ -35,6 +35,7 @@
#include linux/config.h
#include linux/highmem.h
+#include linux/vmalloc.h
#include drmP.h
/**
Index: drm/shared/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.17
diff -u -r1.17 r300_cmdbuf.c
--- drm/shared/r300_cmdbuf.c3 Mar 2005 04:40:21 - 1.17
+++ drm/shared/r300_cmdbuf.c8 Mar 2005 18:40:03 -
@@ -58,10 +58,10 @@
drm_radeon_cmd_buffer_t* cmdbuf,
int n)
{
- RING_LOCALS;
drm_clip_rect_t box;
int nr;
int i;
+ RING_LOCALS;
nr = cmdbuf-nbox - n;
if (nr R300_SIMULTANEOUS_CLIPRECTS)
@@ -242,9 +242,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int reg;
int sz;
+ RING_LOCALS;
sz = header.unchecked_state.count;
reg = (header.unchecked_state.reghi 8) |
header.unchecked_state.reglo;
@@ -281,9 +281,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int sz;
int addr;
+ RING_LOCALS;
sz = header.vpu.count;
addr = (header.vpu.adrhi 8) | header.vpu.adrlo;
@@ -344,9 +344,9 @@
static __inline__ int r300_emit_raw(drm_radeon_private_t* dev_priv,
drm_radeon_cmd_buffer_t* cmdbuf)
{
- RING_LOCALS;
unsigned int u;
int count;
+ RING_LOCALS;
if (4 cmdbuf-bufsz)
return DRM_ERR(EINVAL);
Index: drm/shared-core/r300_cmdbuf.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/r300_cmdbuf.c,v
retrieving revision 1.17
diff -u -r1.17 r300_cmdbuf.c
--- drm/shared-core/r300_cmdbuf.c 3 Mar 2005 04:40:21 - 1.17
+++ drm/shared-core/r300_cmdbuf.c 8 Mar 2005 18:40:03 -
@@ -58,10 +58,10 @@
drm_radeon_cmd_buffer_t* cmdbuf,
int n)
{
- RING_LOCALS;
drm_clip_rect_t box;
int nr;
int i;
+ RING_LOCALS;
nr = cmdbuf-nbox - n;
if (nr R300_SIMULTANEOUS_CLIPRECTS)
@@ -242,9 +242,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int reg;
int sz;
+ RING_LOCALS;
sz = header.unchecked_state.count;
reg = (header.unchecked_state.reghi 8) |
header.unchecked_state.reglo;
@@ -281,9 +281,9 @@
drm_radeon_cmd_buffer_t* cmdbuf,
drm_r300_cmd_header_t header)
{
- RING_LOCALS;
int sz;
int addr;
+ RING_LOCALS;
sz = header.vpu.count;
addr = (header.vpu.adrhi 8) | header.vpu.adrlo;
@@ -344,9 +344,9 @@
static __inline__ int r300_emit_raw(drm_radeon_private_t* dev_priv,
drm_radeon_cmd_buffer_t* cmdbuf)
{
- RING_LOCALS;
unsigned int u;
int count;
+ RING_LOCALS;
if (4 cmdbuf-bufsz)
return DRM_ERR(EINVAL);
[PATCH] r300 ia64 fixes
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for
pointing out the resource size mismatch. The patch just fixes that (PCI
resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and
adds the checking for write combining regions I posted earlier since I don't
think that's been applied.
Thanks,
Jesse
Index: drm/linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.2
diff -u -r1.2 drmP.h
--- drm/linux-core/drmP.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drmP.h 8 Mar 2005 18:40:03 -
@@ -55,6 +55,9 @@
#include linux/smp_lock.h/* For (un)lock_kernel */
#include linux/mm.h
#include linux/pagemap.h
+#ifdef __ia64__
+#include linux/efi.h
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include asm/pgtable.h /* For pte_wrprotect */
#endif
@@ -850,7 +853,7 @@
unsigned int cmd, unsigned long arg);
extern int drm_rmmap(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
+extern int drm_initmap(drm_device_t * dev, unsigned long offset,
unsigned int size, unsigned int resource, int type,
int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
Index: drm/linux-core/drm_bufs.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_bufs.c,v
retrieving revision 1.2
diff -u -r1.2 drm_bufs.c
--- drm/linux-core/drm_bufs.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_bufs.c 8 Mar 2005 18:40:03 -
@@ -53,7 +53,7 @@
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
+int drm_initmap(drm_device_t * dev, unsigned long offset, unsigned int size,
unsigned int resource, int type, int flags)
{
drm_map_t *map;
@@ -63,7 +63,7 @@
if ((offset (~PAGE_MASK)) || (size (~PAGE_MASK)))
return -EINVAL;
-#if !defined(__sparc__) !defined(__alpha__)
+#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
if (offset + size offset || offset virt_to_phys(high_memory))
return -EINVAL;
#endif
Index: drm/linux-core/drm_vm.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_vm.c,v
retrieving revision 1.2
diff -u -r1.2 drm_vm.c
--- drm/linux-core/drm_vm.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_vm.c 8 Mar 2005 18:40:03 -
@@ -639,9 +639,13 @@
vma-vm_flags |= VM_IO; /* not in core dump */
}
#if defined(__ia64__)
- if (map-type != _DRM_AGP)
+ if (efi_range_is_wc(vma-vm_start, vma-vm_end -
+ vma-vm_start) (map-type != _DRM_AGP))
vma-vm_page_prot =
- pgprot_writecombine(vma-vm_page_prot);
+ pgprot_writecombine(vma-vm_page_prot);
+ else
+ vma-vm_page_prot =
+ pgprot_noncached(vma-vm_page_prot);
#endif
offset = dev-driver-get_reg_ofs(dev);
#ifdef __sparc__
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
int') and adds the checking for write combining regions I posted earlier
since I don't think that's been applied.
Here's a more complete patch that fixes up some ppc stuff as well.
Jesse
Index: drm/linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.2
diff -u -p -r1.2 drmP.h
--- drm/linux-core/drmP.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drmP.h 8 Mar 2005 19:00:54 -
@@ -55,6 +55,9 @@
#include linux/smp_lock.h/* For (un)lock_kernel */
#include linux/mm.h
#include linux/pagemap.h
+#ifdef __ia64__
+#include linux/efi.h
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include asm/pgtable.h /* For pte_wrprotect */
#endif
@@ -850,7 +853,7 @@ extern int drm_addmap(struct inode *inod
unsigned int cmd, unsigned long arg);
extern int drm_rmmap(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
+extern int drm_initmap(drm_device_t * dev, unsigned long offset,
unsigned int size, unsigned int resource, int type,
int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
Index: drm/linux-core/drm_bufs.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_bufs.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_bufs.c
--- drm/linux-core/drm_bufs.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_bufs.c 8 Mar 2005 19:00:54 -
@@ -53,7 +53,7 @@ EXPORT_SYMBOL(drm_get_resource_len);
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
+int drm_initmap(drm_device_t * dev, unsigned long offset, unsigned int size,
unsigned int resource, int type, int flags)
{
drm_map_t *map;
@@ -63,7 +63,7 @@ int drm_initmap(drm_device_t * dev, unsi
if ((offset (~PAGE_MASK)) || (size (~PAGE_MASK)))
return -EINVAL;
-#if !defined(__sparc__) !defined(__alpha__)
+#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
!defined(__powerpc__)
if (offset + size offset || offset virt_to_phys(high_memory))
return -EINVAL;
#endif
@@ -198,7 +198,7 @@ int drm_addmap(struct inode *inode, stru
/* addmap didn't match an existing permanent
map, that's an error */
return -EINVAL;
}
-#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
+#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
!defined(__powerpc__)
if (map-offset + map-size map-offset ||
map-offset virt_to_phys(high_memory)) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
Index: drm/linux-core/drm_vm.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_vm.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_vm.c
--- drm/linux-core/drm_vm.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_vm.c 8 Mar 2005 19:00:54 -
@@ -639,9 +639,13 @@ int drm_mmap(struct file *filp, struct v
vma-vm_flags |= VM_IO; /* not in core dump */
}
#if defined(__ia64__)
- if (map-type != _DRM_AGP)
+ if (efi_range_is_wc(vma-vm_start, vma-vm_end -
+ vma-vm_start) (map-type != _DRM_AGP))
vma-vm_page_prot =
- pgprot_writecombine(vma-vm_page_prot);
+ pgprot_writecombine(vma-vm_page_prot);
+ else
+ vma-vm_page_prot =
+ pgprot_noncached(vma-vm_page_prot);
#endif
offset = dev-driver-get_reg_ofs(dev);
#ifdef __sparc__
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote:
Here are a few small fixes to get r300 going on ia64. Thanks to Stephane
for pointing out the resource size mismatch. The patch just fixes that
(PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned
int') and adds the checking for write combining regions I posted earlier
since I don't think that's been applied.
Thanks,
Jesse
Or another one that removes the silly overflow and 'offset within real memory'
checks altogether. Take your pick as to which should be applied :)
Thanks,
Jesse
Index: drm/linux-core/drmP.h
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drmP.h,v
retrieving revision 1.2
diff -u -p -r1.2 drmP.h
--- drm/linux-core/drmP.h 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drmP.h 8 Mar 2005 19:03:03 -
@@ -55,6 +55,9 @@
#include linux/smp_lock.h/* For (un)lock_kernel */
#include linux/mm.h
#include linux/pagemap.h
+#ifdef __ia64__
+#include linux/efi.h
+#endif
#if defined(__alpha__) || defined(__powerpc__)
#include asm/pgtable.h /* For pte_wrprotect */
#endif
@@ -850,7 +853,7 @@ extern int drm_addmap(struct inode *inod
unsigned int cmd, unsigned long arg);
extern int drm_rmmap(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
+extern int drm_initmap(drm_device_t * dev, unsigned long offset,
unsigned int size, unsigned int resource, int type,
int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
Index: drm/linux-core/drm_bufs.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_bufs.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_bufs.c
--- drm/linux-core/drm_bufs.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_bufs.c 8 Mar 2005 19:03:03 -
@@ -53,7 +53,7 @@ EXPORT_SYMBOL(drm_get_resource_len);
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
+int drm_initmap(drm_device_t * dev, unsigned long offset, unsigned int size,
unsigned int resource, int type, int flags)
{
drm_map_t *map;
@@ -63,10 +63,6 @@ int drm_initmap(drm_device_t * dev, unsi
if ((offset (~PAGE_MASK)) || (size (~PAGE_MASK)))
return -EINVAL;
-#if !defined(__sparc__) !defined(__alpha__)
- if (offset + size offset || offset virt_to_phys(high_memory))
- return -EINVAL;
-#endif
if (!(list = drm_alloc(sizeof(*list), DRM_MEM_MAPS)))
return -ENOMEM;
memset(list, 0, sizeof(*list));
@@ -198,13 +194,6 @@ int drm_addmap(struct inode *inode, stru
/* addmap didn't match an existing permanent
map, that's an error */
return -EINVAL;
}
-#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__)
- if (map-offset + map-size map-offset ||
- map-offset virt_to_phys(high_memory)) {
- drm_free(map, sizeof(*map), DRM_MEM_MAPS);
- return -EINVAL;
- }
-#endif
#ifdef __alpha__
map-offset += dev-hose-mem_space-start;
#endif
Index: drm/linux-core/drm_vm.c
===
RCS file: /cvsroot/r300/r300_driver/drm/linux-core/drm_vm.c,v
retrieving revision 1.2
diff -u -p -r1.2 drm_vm.c
--- drm/linux-core/drm_vm.c 2 Mar 2005 03:54:27 - 1.2
+++ drm/linux-core/drm_vm.c 8 Mar 2005 19:03:03 -
@@ -639,9 +639,13 @@ int drm_mmap(struct file *filp, struct v
vma-vm_flags |= VM_IO; /* not in core dump */
}
#if defined(__ia64__)
- if (map-type != _DRM_AGP)
+ if (efi_range_is_wc(vma-vm_start, vma-vm_end -
+ vma-vm_start) (map-type != _DRM_AGP))
vma-vm_page_prot =
- pgprot_writecombine(vma-vm_page_prot);
+ pgprot_writecombine(vma-vm_page_prot);
+ else
+ vma-vm_page_prot =
+ pgprot_noncached(vma-vm_page_prot);
#endif
offset = dev-driver-get_reg_ofs(dev);
#ifdef __sparc__
Re: [PATCH] r300 warning fixes
On Tuesday, March 8, 2005 10:43 am, Jesse Barnes wrote: This small patch fixes some warnings I saw when building on ia64. I think it's safe to apply. It just moves some of the RING_LOCALS macros to below the local stack variables to avoid mixing code declarations warnings and adds vmalloc.h to drm_memory.h so that the vmalloc related stuff gets pulled in. Just committed this to r300 cvs. Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote: On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote: Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for pointing out the resource size mismatch. The patch just fixes that (PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and adds the checking for write combining regions I posted earlier since I don't think that's been applied. Thanks, Jesse Or another one that removes the silly overflow and 'offset within real memory' checks altogether. Take your pick as to which should be applied :) Anyone have a preference on this stuff? Should we remove the checks altogether or just the ones against the highmem variable? If we did the latter, we could remove the #ifdefs altogether, though I'm not sure how useful that check is--seems like we'd run into trouble elsewhere if we got a bad address anyway... Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 8, 2005 12:24 pm, Jesse Barnes wrote: On Tuesday, March 8, 2005 11:04 am, Jesse Barnes wrote: On Tuesday, March 8, 2005 10:47 am, Jesse Barnes wrote: Here are a few small fixes to get r300 going on ia64. Thanks to Stephane for pointing out the resource size mismatch. The patch just fixes that (PCI resources in Linux are 'unsigned long' at the moment, not 'unsigned int') and adds the checking for write combining regions I posted earlier since I don't think that's been applied. Thanks, Jesse Or another one that removes the silly overflow and 'offset within real memory' checks altogether. Take your pick as to which should be applied :) Anyone have a preference on this stuff? Should we remove the checks altogether or just the ones against the highmem variable? If we did the latter, we could remove the #ifdefs altogether, though I'm not sure how useful that check is--seems like we'd run into trouble elsewhere if we got a bad address anyway... Oh, and these fixes, regardless of what they are, should go into the main drm tree not the r300 branch, since they're not related to the r300 stuff at all (IOW I can't commit them). Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r300 ia64 fixes
On Tuesday, March 08, 2005 4:24 pm, Paul Mackerras wrote: Jesse Barnes writes: Anyone have a preference on this stuff? Should we remove the checks altogether or just the ones against the highmem variable? If we did the latter, we could remove the #ifdefs altogether, though I'm not sure how useful that check is--seems like we'd run into trouble elsewhere if we got a bad address anyway... My preference would be to remove the check altogether. Mine too, Dave, maybe you could check that one in (r300-ia64-fixes-3.patch)? How about the new virt_to_bus usage? That'll be a problem on ppc as well... Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
On Tuesday, March 15, 2005 6:36 am, Dave Jones wrote: I saw one report where the recent drm security hole fix broke dri for one user. Whilst it seems an isolated incident, could this have more impact than we first realised ? Worse case scenario we can drop out the multi-bridge support for now if it needs work. Mike left SGI now, so we'll need to find someone else with access to a Prism to make sure it still works correctly on a real multi-gart system. I'd be happy to test and fix things, but the page table walker patches broke ia64... Once that's cleared up I can go digging. Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm lockups since 2.6.11-bk2
On Tuesday, March 15, 2005 11:25 am, Andrew Morton wrote: Jesse Barnes [EMAIL PROTECTED] wrote: I'd be happy to test and fix things, but the page table walker patches broke ia64... Once that's cleared up I can go digging. We're hoping that davem's fix (committed yesterday) fixed that. ChangeSet 1.2181.1.2, 2005/03/14 21:16:17-08:00, [EMAIL PROTECTED] [MM]: Restore pgd_index() iteration to clear_page_range(). Yep, seems to have worked (at least my system boots). I only saw it in BK today (I was waiting for a post to Tony's thread with the fix so I didn't see it as soon as I might have). Now to test AGP stuff. Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm bugs hopefully fixed but there might still be one..
On Thursday, March 24, 2005 2:33 am, Dave Airlie wrote: Hi Andrew, Dave, I've put a couple of patches into my drm-2.6 tree that hopefully fix up the multi-bridge on i915 and the XFree86 4.3 issue.. Andrew can you drop the two patches in your tree.. the one from Brice and the one I attached to the bug? you'll get conflicts anyway I'm sure. I had to modify Brices one as it didn't look safe to me in all cases.. I think their might be one left, but I think it only seems to be on non-intel AGP system, as in my system works fine for a combination of cards and X releases ... anyone with a VIA chipset and Radeon graphics card or r128 card.. testing the next -mm would help me a lot.. I'm trying to get ahold of one--so hopefully I'll be able to test and fix this stuff up when I do. Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm bugs hopefully fixed but there might still be one..
On Thursday, March 24, 2005 10:18 am, Dave Jones wrote: I'm trying to get ahold of one--so hopefully I'll be able to test and fix this stuff up when I do. Aparently backing out the changes to via's tlb_flush routine fixed it for one VIA user. I've not had a chance to look into it just yet. Worse case we can just drop those changes for 2.6.12 You mean these changes? --- a/drivers/char/agp/via-agp.c2005-03-24 10:33:45 -08:00 +++ b/drivers/char/agp/via-agp.c2005-03-24 10:33:45 -08:00 @@ -83,8 +83,10 @@ pci_read_config_dword(agp_bridge-dev, VIA_GARTCTRL, temp); temp |= (17); + temp = ~0x7f; pci_write_config_dword(agp_bridge-dev, VIA_GARTCTRL, temp); temp = ~(17); + temp = ~0x7f; pci_write_config_dword(agp_bridge-dev, VIA_GARTCTRL, temp); } I'll ask Markus to try reverting this since I still don't have a machine setup. It sounds like a possibility given what he's seeing. Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. Seems reasonable since egl will depend on the fb drivers, right? For embedded and/or small systems w/o 3D, users can bypass egl and the fb drivers and just use a kaa based system I guess. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 8:39 am, Jon Smirl wrote: On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote: On Friday, June 10, 2005 8:09 am, Jon Smirl wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. Seems reasonable since egl will depend on the fb drivers, right? For embedded and/or small systems w/o 3D, users can bypass egl and the fb drivers and just use a kaa based system I guess. A lot of embedded systems are going with OpenGL/ES. EGL is derived from the OpenGL/ES spec. Going with OpenGL/ES is a cross platform solution for them, KAA would be kdrive specific. Right, I'm just saying that alternatives exist for people who don't want the ~100k lines EGL code (plus the kernel fb and drm drivers). Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 8:52 am, Jon Smirl wrote: On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. This seems like an odd solution. Why wouldn't you just enable multiple drivers to attach to the device? Attaching multiple drivers to hardware resources is not supported in Linux. There would all kinds of issues with ref counting resource reservations, allowing multiple interrupts handlers (who acks the interrupt), etc. What about loading/unload in different orders? In Linux you attach a primary driver to the hardware and then secondary drivers can attach to the primary one. And isn't really advisable in general--if multiple drivers want to talk to a device, they have to co-ordinate anyway, so you either end up with a loosely coupled driver group (like DRM/DRI/DDX) or a more tightly coupled driver subsystem/subdriver type setup. Your approach is the latter, and I think it's probably best. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 9:07 am, Jon Smirl wrote: The Xegl model lets you pick where you get your drivers from. It just runs on top of a driver stack providing the OpenGL/ES+EGL API. The embedded systems I am aware of are ignoring mesa, drm, fbdev and and building their own optimized OpenGL/ES stacks. The win is that the same OpenGL/ES stack can be used with other operating systems. Right, which is nice. But fundamentally, OpenGL|ES+EGL depends on a GL implementation (either sw or hw) and some sort of framebuffer control ability, right? On Linux, the GL aspect is provided by the current DRM/DRI layer, and the framebuffer control (modesetting, memory management?) is provided by the fb drivers, right? If that's the case, then I think the way you've tied together the drm and fb drivers make sense, since the most common setups in the brave new world of Xegl will require both. (Other configurations might be Xegl on top of some sort of equivalent BSD implementation or a proprietary stack, like nVidia's.) My point about KAA (or Shiny or whatever it ends up being) is that people, who for whatever reason don't want DRM/DRI (too big, too complex, or maybe they're just contrarians), can still just use the fb drivers by themselves along with whatever else they want on top. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 10:46 am, Jon Smirl wrote: We don't have enough people to finish one set of drivers and cetainly not enough to finish two. What we are going to end up with is two half finished systems. People working on KAA are capable of making valuable contributions to DRI/DRM if they choose to. Well, that may be true, but in the open source world people will work on the things they're interested in; you can't really tell them what to do. Hopefully they'll be enough interest in the EGL stuff to get a good number of drivers finished (and who knows, maybe the Shiny stuff will be simple enough that people can get started with it, write some driver drivers, and then move onto EGL, with the end result of actually *adding* developers with experience to the EGL effort). But anyway, you've said all this before, sorry for pulling you off topic. :) Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 4:38 pm, Benjamin Herrenschmidt wrote: Anyway, I really want a slightly different approach than what Jon is doing, that is a 3 modules scenario: - A basic stub module that attaches to the PCI card. It doesn't touch the hardware per-se (thus won't break your VGA console, though radeonfb without fb console shouldn't either, the problem you have is a bug). That stub contains the common code like IRQ handling, card type detection, maybe vram detection etc... And some locking facility - Depending on the above, an optional fbdev module that provides the fbdev interface mode setting - Depending on the first one too, but independant from the fbdev one, the DRM module providing the radeon DRM kernel interface What's the advantage of this if the fb part of the driver is typically needed? (I'm assuming it'll be used for modesetting at the very least in Linux.) Is it just to avoid issues with the VGA driver? Maybe it's the right way to go in the long run, but I see no problem with Jon's approach as an intermediate (if not final) step. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.14-rt4: via DRM errors
On Thursday, November 24, 2005 4:50 am, Thomas Hellström wrote: There is some info in the old precision insight documentation about the DRI infrastructure, (can't seem to find a link right now) But generally there is only one global lock and something called the drawable spinlock that is apparently not used anymore. The global lock is similar to a futex, with the exception that the kernel is called both to resolve contention and whenever a new context is about to take the lock, so that optional context switching can take place, and also if the client requests that some special action should take place after locking is done, like wait for dma ready or quiescent. The lock should be taken before writing to the hardware or before submitting DMA commands. If you want to be _sure_ that noone else uses the hardware (like you want to read a particular register or something), you have to take the lock and wait for DMA quiescent. For example, if you want to make sure the video scaler is idle so you can write to it, you first take the lock so that noone else writes to it or to the DMA queue, then you wait for the DMA queue to be empty or make sure there are no pending commands for the scaler, then you wait for the scaler to become idle. The lock value is easily manipulated from user space and resides in one of the shared memory areas. I guess this means that with the current drm security policy it should be regarded as an advisory lock between drm clients. This is a nice little writeup, maybe it could go into the kernel's Documentation/ directory? It would be nice to document how the lock and signal handling interact as well. At one point I was about to implement a scheme for via with a number of similar locks, one for each independent function on the video chip, Like 2D, 3D, Mpeg decoder, Video scaler 1 and 2, so that they didn't have to wait for eachother. The global lock would then only be taken to make sure that no drawables were touched by the X server or other clients while the lock was held, which would be compatible with how the X server works today. Never got around to do that, however, but the mpeg decoders have a futex scheme to prevent clients stepping on eachother. With that it is possible to have multiple clients use the same hw decoder. Sounds interesting, but that would be card specific, right? I mean, on some cards the 2d and 3d locks would have to be the same because of shared state or whatever, for example. Jesse --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] basic drm driver for Trident CyberBlade
I'm trying to get the CyberBlade EXA driver into a bit better shape, and
that means some sort of decent host-fb DMA support. The device
itself is apparently capable of that, but EXA has trouble since it only
has the user virtual address of the transfers it wants to make, so I
thought a DRM driver might be in order. It's also necessary for decent
VBLANK support, which will hopefully be pretty straightforward. Note
that at this point, the DRM driver won't do you any good since I
haven't checked the EXA stuff that uses it into X.Org CVS yet (and
afaik there's no DRI driver for this device either).
Any thoughts on how the host-fb DMA stuff should work? Basically EXA
UploadToScreen wants to hand the card a virtual address range and have
it loaded up to the card's VRAM; DownloadFromScreen wants to do the
same in reverse. Should I just add a device specific DRM_IOCTL to
accomplish this (using get_user_pages() etc.) or is there some existing
code I could leverage?
Thanks,
Jesse
Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
diff --git a/drivers/char/drm/Makefile b/drivers/char/drm/Makefile
index 9d180c4..a212175 100644
--- a/drivers/char/drm/Makefile
+++ b/drivers/char/drm/Makefile
@@ -8,6 +8,7 @@ drm-objs:= drm_auth.o drm_bufs.o drm
drm_agpsupport.o drm_scatter.o ati_pcigart.o drm_pci.o \
drm_sysfs.o
+blade-objs := blade_drv.o
tdfx-objs := tdfx_drv.o
r128-objs := r128_drv.o r128_cce.o r128_state.o r128_irq.o
mga-objs:= mga_drv.o mga_dma.o mga_state.o mga_warp.o mga_irq.o
@@ -30,6 +31,7 @@ endif
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_TDFX) += tdfx.o
+obj-$(CONFIG_DRM_BLADE) += blade.o
obj-$(CONFIG_DRM_R128) += r128.o
obj-$(CONFIG_DRM_RADEON)+= radeon.o
obj-$(CONFIG_DRM_MGA) += mga.o
--- /dev/null 2006-03-02 18:11:38.777108750 -0800
+++ drivers/char/drm/blade_drv.c 2006-03-05 20:24:53.0 -0800
@@ -0,0 +1,117 @@
+/*
+ * Copyright 2006 Jesse Barnes [EMAIL PROTECTED]
+ * All Rights Reserved.
+ *
+ * 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
+ * PRECISION INSIGHT AND/OR ITS SUPPLIERS 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:
+ *Jesse Barnes [EMAIL PROTECTED]
+ */
+
+#include linux/config.h
+#include drm_pciids.h
+#include drmP.h
+
+#define DRIVER_AUTHOR Jesse Barnes
+
+#define DRIVER_NAME blade_drm
+#define DRIVER_DESC Trident CyberBlade
+#define DRIVER_DATE 20060303
+
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCHLEVEL 0
+
+static struct pci_device_id blade_pciids[] = {
+ blade_PCI_IDS
+};
+
+static struct drm_driver blade_driver = {
+ .driver_features = (DRIVER_USE_AGP | DRIVER_USE_MTRR |
+ DRIVER_PCI_DMA | DRIVER_SG | DRIVER_HAVE_DMA |
+ DRIVER_HAVE_IRQ | DRIVER_FB_DMA), /* IRQ_VBL? */
+ .reclaim_buffers = drm_core_reclaim_buffers,
+ .get_map_ofs = drm_core_get_map_ofs,
+ .get_reg_ofs = drm_core_get_reg_ofs,
+ .fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .release = drm_release,
+ .ioctl = drm_ioctl,
+ .mmap = drm_mmap,
+ .poll = drm_poll,
+ .fasync = drm_fasync,
+ },
+ .pci_driver = {
+ .name = DRIVER_NAME,
+ .id_table = blade_pciids,
+ },
+
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+ .patchlevel = DRIVER_PATCHLEVEL,
+};
+
+static int vblank_wait(struct drm_device * dev, unsigned int *sequence)
+{
+ /* Use next vblank interrupt or pending register */
+}
+
+static irqreturn_t irq_handler(DRM_IRQ_ARGS)
+{
+}
+
+static void irq_preinstall(struct drm_device * dev)
+{
+}
+
+static void irq_postinstall(struct drm_device * dev)
+{
+}
+
+static void irq_uninstall(struct drm_device * dev)
+{
+}
+
+static int __init blade_init(void)
+{
+ /*
+ * TODO:
+ * ioremap device resources
+ * Setup IRQ for vblank
+ * Lots of other stuff (e.g. host-fb dma stuff)
+ */
+ return drm_init(blade_driver);
+}
+
+static void __exit blade_exit(void)
+{
+ drm_exit(blade_driver);
+}
+
+module_init(blade_init);
+module_exit
Re: [PATCH] basic drm driver for Trident CyberBlade
On Monday, March 6, 2006 12:28 pm, Thomas Hellström wrote: The via driver has code that does this (via_dmablit.c) as a device-specific IOCTL. It maintains a queue of blit operations and fire them off when the previous one is completed. The user calls a sync IOCTL to verify that the operation is finished. Ok, thanks, I'll check it out. It looks like the CyberBlade device supports command queuing, maybe that would be a way to optimize the command submission stuff. The via-specific code is quite limited, so it should be easy to port it to other hardware but the card needs to have a descriptor-based PCI DMA engine. Note that the throughput is quite low. With EXA you get about 65-70 MB/s either direction. Limited by the PCI bus speed. Ok. I don't expect this system to be a speed demon either, but it does have SG support so hopefully I won't have to submit things in very small chunks. If your card can do AGP-VRAM transfers in hardware the best option for upload is probably to use that functionality. Software copies to AGP can be pipelined with AGP-VRAM blits using two bounce-buffers in AGP space. You split up the transfer and copy to one buffer while you're blitting to VRAM from the other. Hm, I'll have to take a look at that. Based on the specs, it looks like the AGP transfer stuff is a separate command set. For downloads from VRAM we will soon have an option to blit from VRAM to AGP, and then take the pages out of AGP space and read from them with full speed, but that's still under development. That sounds good, sounds like it should be fairly optimal. Thanks, Jesse --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling new xf86-video-intel drive
On Saturday, March 17, 2007, Sergio Monteiro Basto wrote: Hi , I need your help , I am trying compile intel video drive and give me this: checking for xf86Modes.h... no symlink mode code configure: error: Must have X server = 1.3 source tree for mode setting code. Please specify --with-xserver-source + exit 1 what I need upgrade is just xorg-x11-server-Xorg-1.1.1 ? This is probably a better question for [EMAIL PROTECTED], but you'll need the sources for a 1.3+ server tree to build the latest Intel driver. Just check it out in the parent directory of your Intel driver tree and the configure scripts should find it. If that doesn't work, send a note to [EMAIL PROTECTED] Jesse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] Added structs and ioctls for modesetting in kernel
:00.0 -0800
+++ linux-2.6.21-rc4-modesetting/drivers/char/drm/drm_crtc.c 2007-03-21 09:33:54.0 -0700
@@ -0,0 +1,56 @@
+#include drmP.h
+#include drm.h
+#include drm_crtc.h
+
+static DEFINE_SPINLOCK(drm_modes_lock);
+static LIST_HEAD(drm_modes);
+
+static DEFINE_SPINLOCK(drm_output_lock);
+static LIST_HEAD(drm_outputs);
+
+struct drm_output *drm_output_create(drm_device_t *dev,
+ const struct drm_output_funcs *funcs,
+ const char *name)
+{
+ struct drm_output *output;
+
+ if (!name) {
+ dev_printk(KERN_ERR, dev-pdev-dev, %s: name missing.\n,
+ __FUNCTION__);
+ return NULL;
+ }
+
+ output = kmalloc(sizeof(struct drm_output), GFP_KERNEL);
+ if (!output)
+ return NULL;
+
+ output-dev = dev;
+ output-funcs = funcs;
+ strncpy(output-name, name, DRM_OUTPUT_LEN);
+ output-name[DRM_OUTPUT_LEN - 1] = 0;
+ output-subpixel_order = SubPixelUnknown;
+ /* randr_output? */
+ /* output_set_monitor(output)? */
+ /* check for output_ignored(output)? */
+
+ spin_lock(drm_output_lock);
+ list_add(output-head, drm_outputs);
+ spin_unlock(drm_output_lock);
+
+ return output;
+}
+EXPORT_SYMBOL(drm_output_create);
+
+void drm_output_destroy(struct drm_output *output)
+{
+ spin_lock(drm_output_lock);
+ list_del(output-head);
+ spin_unlock(drm_output_lock);
+ kfree(output);
+}
+EXPORT_SYMBOL(drm_output_destroy);
+
+bool drm_initial_config(drm_device_t *dev, bool can_grow)
+{
+ return 0;
+}
diff -Napur -X /home/jbarnes/dontdiff linux-2.6.21-rc4/drivers/char/drm/drm_crtc.h linux-2.6.21-rc4-modesetting/drivers/char/drm/drm_crtc.h
--- linux-2.6.21-rc4/drivers/char/drm/drm_crtc.h 1969-12-31 16:00:00.0 -0800
+++ linux-2.6.21-rc4-modesetting/drivers/char/drm/drm_crtc.h 2007-03-21 08:41:51.0 -0700
@@ -0,0 +1,350 @@
+/*
+ * Copyright © 2006 Keith Packard
+ * Copyright © 2007 Intel Corporation
+ * Jesse Barnes [EMAIL PROTECTED]
+ */
+#ifndef __DRM_CRTC_H__
+#define __DRM_CRTC_H__
+
+#include linux/spinlock.h
+#include linux/types.h
+#include drmP.h
+#include drm.h
+
+/*
+ * Note on terminology: here, for brevity and convenience, we refer to output
+ * control chips as 'CRTCS'. They can control any type of output, VGA, LVDS,
+ * DVI, etc. And 'screen' refers to the whole of the visible display, which
+ * may span multiple monitors (and therefore multiple CRTC and output
+ * structures).
+ */
+
+enum drm_mode_status {
+MODE_OK = 0, /* Mode OK */
+MODE_HSYNC, /* hsync out of range */
+MODE_VSYNC, /* vsync out of range */
+MODE_H_ILLEGAL, /* mode has illegal horizontal timings */
+MODE_V_ILLEGAL, /* mode has illegal horizontal timings */
+MODE_BAD_WIDTH, /* requires an unsupported linepitch */
+MODE_NOMODE, /* no mode with a maching name */
+MODE_NO_INTERLACE, /* interlaced mode not supported */
+MODE_NO_DBLESCAN, /* doublescan mode not supported */
+MODE_NO_VSCAN, /* multiscan mode not supported */
+MODE_MEM, /* insufficient video memory */
+MODE_VIRTUAL_X, /* mode width too large for specified virtual size */
+MODE_VIRTUAL_Y, /* mode height too large for specified virtual size */
+MODE_MEM_VIRT, /* insufficient video memory given virtual size */
+MODE_NOCLOCK, /* no fixed clock available */
+MODE_CLOCK_HIGH, /* clock required is too high */
+MODE_CLOCK_LOW, /* clock required is too low */
+MODE_CLOCK_RANGE, /* clock/mode isn't in a ClockRange */
+MODE_BAD_HVALUE, /* horizontal timing was out of range */
+MODE_BAD_VVALUE, /* vertical timing was out of range */
+MODE_BAD_VSCAN, /* VScan value out of range */
+MODE_HSYNC_NARROW, /* horizontal sync too narrow */
+MODE_HSYNC_WIDE, /* horizontal sync too wide */
+MODE_HBLANK_NARROW, /* horizontal blanking too narrow */
+MODE_HBLANK_WIDE, /* horizontal blanking too wide */
+MODE_VSYNC_NARROW, /* vertical sync too narrow */
+MODE_VSYNC_WIDE, /* vertical sync too wide */
+MODE_VBLANK_NARROW, /* vertical blanking too narrow */
+MODE_VBLANK_WIDE, /* vertical blanking too wide */
+MODE_PANEL, /* exceeds panel dimensions */
+MODE_INTERLACE_WIDTH, /* width too large for interlaced mode */
+MODE_ONE_WIDTH, /* only one width is supported */
+MODE_ONE_HEIGHT,/* only one height is supported */
+MODE_ONE_SIZE, /* only one resolution is supported */
+MODE_NO_REDUCED,/* monitor doesn't accept reduced blanking */
+MODE_BAD = -2, /* unspecified reason */
+MODE_ERROR = -1 /* error condition */
+};
+
+#define DRM_DISPLAY_MODE_LEN 32
+
+struct drm_display_mode {
+ struct list_head head;
+ char name[DRM_DISPLAY_MODE_LEN];
+ enum drm_mode_status status;
+ int type;
+
+ /* Proposed mode values */
+ int clock;
+ int hdisplay;
+ int hsync_start;
+ int hsync_end;
+ int htotal;
+ int hskew;
+ int vdisplay;
+ int vsync_start;
+ int vsync_end;
+ int vtotal;
+ int vscan;
+ unsigned int flags;
+
+ /* Actual mode we give to hw */
+ int clock_index;
+ int synth_clock;
+ int crtc_hdisplay;
+ int
Re: [PATCH 1/3] Added structs and ioctls for modesetting in kernel
On Thursday, March 22, 2007 6:54 am Alex Deucher wrote: On 3/22/07, Jesse Barnes [EMAIL PROTECTED] wrote: On Tuesday, March 20, 2007, Jakob Bornecrantz wrote: Added structs and ioctls for modesetting in kernel And just to give you an idea of the sorts of structures and layout I've been working with, here's what I was playing with today. Right now it just grabs the EDID data from the LVDS panel on my laptop, but I figured that's a good start since I'll need mode timing information from somewhere anyway to set modes correctly. There's still lots to be done and quite a few open questions, but it's probably good to get a few eyes on it at this point. while we are moving stuff to the drm, perhaps we should take the time to add support for multiple buffers and address translation. Then in the drm we could set up the scan out buffers, etc. however we want and then expose them to X in a standard fashion. Yes, I definitely think we should do this. Some sort of scanout buffer allocation will be minimally required for this new modesetting code to work. I'm still in the process of reviewing Thomas's (huge) TTM patch, which may get us most of the way there. X could assume they are just one big screen and the drm would deal with the translation to the appropriate buffers. We could use this to work around HW pitch or coordinate limits. It would also make support for multiple cards easier as the userspace drm common layer could dispatch to different local or network devices (think expanding your desktop across multiple PCs). I haven't thought it that far through yet, but it may be a possibility. I think X would still want to know about multiple screens though, since some applications may want to treat different screens specially (e.g. no IM popups on a presentation screen for example). Jesse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Latest on modesetting
Some people were asking about modeseting on #dri-devel this morning so I thought I'd post an update (airlied is asleep so we can blame him for all the problems :). The modesetting-101 branch of the DRM tree is coming along nicely. Much of X.Org's modesetting code has been pulled in (will look very familiar to those of you who've worked with X.Org's Randr 1.2 code), along with driver support code for Intel chipsets. Dave pulled over a bunch of it, and integrated the patches from Jakob (ioctl interface for modesetting) and I (initial port of some X.Org code along with DDC and i2c code) into the tree, got it working and wrote a simple drmfb driver to sit on top. Based on that, I've been working on making the i915 driver initialization less dependent on userspace for things, like mapping registers, allocating memory, setting modes, etc. I just checked in some code to initialize drmfb at load time and set the correct modes depending on output configuration (seems to work ok for external vga but lvds modes are still messed up somehow). It's all still very fragile at this point, so you probably won't want to play with it unless you're really interested in hacking on it. Some of the open questions we're wrestling with atm: o how do we free drm drivers to init a load time rather than addmap/etc. time? o how can we do TTM memory allocation at load time? depends on AGP init happening early, etc. o what should the initial config be? cloned? multihead? single, primary head with other heads initialized to a blank screen? and of course there's lots to do on the logistics front: output, crtc list management, locking, etc., and bugs in DDC probing for old monitors (need more delays and i2c poking). Comments? Questions? A huge amount of the credit for this stuff belongs to keithp and anholt for the excellent, high quality X and driver code they've been putting together recently, making porting and debugging that much easier. Thanks, Jesse - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
On Wednesday, April 11, 2007, Jesse Barnes wrote:
Some people were asking about modeseting on #dri-devel this morning so I
thought I'd post an update (airlied is asleep so we can blame him for
all the problems :).
The modesetting-101 branch of the DRM tree is coming along nicely. Much
of X.Org's modesetting code has been pulled in (will look very familiar
to those of you who've worked with X.Org's Randr 1.2 code), along with
driver support code for Intel chipsets.
Dave pulled over a bunch of it, and integrated the patches from Jakob
(ioctl interface for modesetting) and I (initial port of some X.Org code
along with DDC and i2c code) into the tree, got it working and wrote a
simple drmfb driver to sit on top.
Based on that, I've been working on making the i915 driver
initialization less dependent on userspace for things, like mapping
registers, allocating memory, setting modes, etc. I just checked in
some code to initialize drmfb at load time and set the correct modes
depending on output configuration (seems to work ok for external vga but
lvds modes are still messed up somehow).
It's all still very fragile at this point, so you probably won't want to
play with it unless you're really interested in hacking on it.
Some of the open questions we're wrestling with atm:
o how do we free drm drivers to init a load time rather than
addmap/etc. time?
o how can we do TTM memory allocation at load time? depends on AGP
init happening early, etc.
o what should the initial config be? cloned? multihead? single,
primary head with other heads initialized to a blank screen?
and of course there's lots to do on the logistics front: output, crtc
list management, locking, etc., and bugs in DDC probing for old monitors
(need more delays and i2c poking).
Oh, and if you want this to have any chance of working at the moment,
you'll need this patch too (I haven't pushed it for fear of breaking other
drivers), warning this was cut pasted:
diff --git a/linux-core/drm_stub.c b/linux-core/drm_stub.c
index f4da7da..13652eb 100644
--- a/linux-core/drm_stub.c
+++ b/linux-core/drm_stub.c
@@ -113,10 +113,6 @@ static int drm_fill_in_dev(drm_device_t * dev, struct
pci_d
dev-driver = driver;
- if (dev-driver-load)
- if ((retcode = dev-driver-load(dev, ent-driver_data)))
- goto error_out_unreg;
-
if (drm_core_has_AGP(dev)) {
if (drm_device_is_agp(dev))
dev-agp = drm_agp_init(dev);
@@ -136,6 +132,11 @@ static int drm_fill_in_dev(drm_device_t * dev, struct
pci_d
}
}
+
+ if (dev-driver-load)
+ if ((retcode = dev-driver-load(dev, ent-driver_data)))
+ goto error_out_unreg;
+
retcode = drm_ctxbitmap_init(dev);
if (retcode) {
DRM_ERROR(Cannot allocate memory for context bitmap.\n);
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest on modesetting
On Wednesday, April 11, 2007, Keith Packard wrote: o what should the initial config be? cloned? multihead? single, primary head with other heads initialized to a blank screen? The X server has some built-in policy for what the starting mode should look like. I think we should be able to build that into the kernel and leave more complicated policies to user-mode. 1. Identify outputs with 'preferred' modes. 2. If no preferred mode, pick an output, set it to 96dpi 3. All other outputs get the closest mode which is no larger than the mode selected above 4. Fit CRTCs to the output configuration by searching for the best match, scoring preferred modes 2, other modes 1, no mode 0. 5. Clone everybody. Cloning seems like the obviously right plan to me; we want to make the boot-up output visible, and we don't expect to need more than one screen. The worst thing that could happen in clone mode is that the user will see more than one copy of the boot messages. Right, bootup output is important (though its signal to noise is degrading with the proliferation of printks added to the bootup these days). But you could also argue (at least for GUI desktop usage) that desktop extension is preferable to cloning. For a text-only bootup (whether it be actual textmode or fbcon), a clone may make more sense, though then you run the risk of not being able to use your preferred mode on the 'main' display (e.g. laptop panel), don't you? Or does the 'fit' in step 4 above work in that situation? E.g. a laptop with a 1280x800 panel connected to an LCD with a 1024x768 display? For the kernel (special uses like debugging aside), I guess either cloning or just using the primary head would make the most sense. Detecting the other heads is necessary, and if cloning weren't in use, some sort of natively sized splash screen would let the user know that it was detected properly... Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] make radeons fire fewer vblank interrupts
In playing around yesterday, we found that some drivers will unnecessarily enable interrupts for vblank events. Since these tend to happen frequently (60+ Hz), they'll cause your CPU to wake up a lot, which will waste power if they're not really in use. This patch hacks the radeon driver to only enable vblank interrupts when the user is waiting for one, rather than at IRQ setup time. I couldn't find any code in the DDX that wanted vblank support, so I suppose the real users are in the Mesa driver somewhere, so I haven't tested it other than to see that my interrupt frequency really does decrease. Comments? Thanks, Jesse diff --git a/drivers/char/drm/radeon_irq.c b/drivers/char/drm/radeon_irq.c index 3ff0baa..71f1919 100644 --- a/drivers/char/drm/radeon_irq.c +++ b/drivers/char/drm/radeon_irq.c @@ -147,9 +147,14 @@ int radeon_driver_vblank_wait(drm_device_t * dev, unsigned int *sequence) * by about a day rather than she wants to wait for years * using vertical blanks... */ + /* Turn on VBL ints */ + RADEON_WRITE(RADEON_GEN_INT_CNTL, + RADEON_CRTC_VBLANK_MASK | RADEON_SW_INT_ENABLE); DRM_WAIT_ON(ret, dev-vbl_queue, 3 * DRM_HZ, (((cur_vblank = atomic_read(dev-vbl_received)) - *sequence) = (1 23))); + /* Go back to just SW interrupts */ + RADEON_WRITE(RADEON_GEN_INT_CNTL, RADEON_SW_INT_ENABLE); *sequence = cur_vblank; @@ -227,9 +232,8 @@ void radeon_driver_irq_postinstall(drm_device_t * dev) atomic_set(dev_priv-swi_emitted, 0); DRM_INIT_WAITQUEUE(dev_priv-swi_queue); - /* Turn on SW and VBL ints */ - RADEON_WRITE(RADEON_GEN_INT_CNTL, - RADEON_CRTC_VBLANK_MASK | RADEON_SW_INT_ENABLE); + /* Enable SW interrupts */ + RADEON_WRITE(RADEON_GEN_INT_CNTL, RADEON_SW_INT_ENABLE); } void radeon_driver_irq_uninstall(drm_device_t * dev) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] make radeons fire fewer vblank interrupts
On Wednesday, May 9, 2007 8:56 am Eric Anholt wrote: I suspect doing it like this might break userspace expectations about the behaviour of the vblank counter. It would be better to do it similarly to how Eric Anholt did it for i915, i.e. by toggling the vblank interrupt in the 2D driver TransitionTo2/3D hooks. Or possibly even better (as this would e.g. still leave it enabled all the time when using a GLX compositing manager), the 3D driver could tell the DRM whether it needs the vblank interrupt or not. Yeah, I wasn't sure if the 3D driver would be able to know easily when it might need to wait on an absolute vblank. Arjan suggested that we not turn off the vblank when 3d is running until nobody's waited one one for (for example) a second, and then if someone waits on one after that, the kernel can re-enable the interrupt and extrapolate the vblank counter using the system clock. Hiding vblank enable/disable knowledge in the kernel sounds nicer than what I did on i915. Yeah, most drivers will probably have to grow power management state machines like this if we're really going to be aggressive in turning them off. I'll try to come up with a patch that does that (then on to ipw2200...). Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] enhancing the kernel's graphics subsystem
Patches at http://www.kernel.org/pub/linux/kernel/people/jbarnes/patches drm-modesetting-core.patch drm-modesetting-i915.patch console-unregister.patch (Sorry the first two are slightly too big for lkml; they're against the DRM tree at git://git.freedesktop.org/git/mesa/drm.) In collaboration with the FB guys, we've been working on enhancing the kernel's graphics subsystem in an attempt to bring some sanity to the Linux graphics world and avoid the situation we have now where several kernel and userspace drivers compete for control of graphics devices. In the interest of getting some early feedback, I thought I'd post a description of how we've structured things so far, along with some of the early code, to get some feedback on the direction. Why in the kernel? There are several reasons to pull modesetting and proper multihead support into the kernel: - suspend/resume - debugging (e.g. panic) - non-X uses - more reliable VT switch Each of the above is covered in more detail below. Suspend/resume Currently, the kernel has to rely on an external application (X, vbetool, etc.), or worse, ACPI, to reset video devices to the proper state after resume. If one of these systems has trouble or crashes during or shortly after resume, the system will become unusable, with little indication as to why (see Debugging below). Putting code into the kernel to perform low level modesetting (i.e. without video BIOS support) will allow the kernel to resume to the correct mode automatically and more quickly than would be possible otherwise. Debugging As mentioned above, if something goes wrong with modesetting during resume, the user has very little indication of where things went wrong. Likewise, if a panic or oops occurs while an application like X is running, the user will experience a hard hang, rather than the much more pleasant blue penguin of death (to be coded). With kernel modesetting support, the kernel should be able to display panic and oops messages directly on the console, even if a graphical application is running, since it would have awareness of the current mode, display depth, pitch, and other variables needed to display output. Another possibility is multihead debugging: one display could run the user's applications (i.e. a normal display) while a secondary display could run a system level debugger, allowing the user to stop the machine, investigate memory, step through programs, etc. (admittedly this is somewhat far fetched). Non-X uses As it stands, non-X based applications wanting to use video devices have two options: either take over the hardware themselves or use the existing kernel fb layer. The former is obviously a tall order given the complexity of current graphics devices, while the latter isn't featureful enough to expose multiple outputs, perform per-device locking so that multiple clients can share the device, etc. A kernel based modsetting and multihead API would make developing such applications much easier. VT switch Currently, the kernel relies on an external program to restore the graphics state when a VT switch occurs. This doesn't always work, with similar results to the suspend/resume case: an apparently hung or unusable machine. Of course, the kernel can't unconditionally preempt the graphics device to set a new mode, but having modesetting in the kernel will give it a much better chance of coordinating with the DRM command dispatch code to find a good time to set a new mode. Interfaces With the above patches, the kernel DRM layer manages the output devices, available modes, and calls into the low level DRM drivers to set modes and probe outputs devices for attached displays, much like the X server's internal RandR 1.2 APIs. It also provides userspace with an interface to these functions (Jakob based these APIs on the X server's Randr extension, but there are differences). DRM/FB cooperation Another major factor to consider when enhancing modesetting in the kernel is DRM and FB cooperation. Currently, FB isn't aware of DRM drivers, and DRM is only minimally aware of FB (such that it can bind to PCI devices even after FB drivers have already done so). As a result, any modesetting done by either layer results in memory allocation that may not be honored by the other side (and/or the X server, which has its own idea of how memory is being used). To properly address interoperability, both the FB and DRM layers need to share a common memory manager, common suspend/resume code, and common modesetting code. In addition, applications must use these layers in some way to avoid conflicts (e.g. X should call into the DRM or FB layers to do memory allocation). What about the FB layer? Today, the FB layer is really only well aware of a single head, and doesn't do full EDID parsing, therefore its knowledge of available modes is limited. On the plus side, it's able to fetch EDID data where
[PATCH 1/3] allow console unregistration
Randy just informed me that the patch limits are bigger now, so here are the
actual patches.
This patch allows for proper console unregistration via the VT layer, and
updates the FB layer to use it. This makes debugging new console drivers
much easier, since you can properly clean them up before unloading.
Antonio already checked it out (and suggested a tweak for the fbcon side)
so I think it's on its way already via the FB tree.
Jesse
--- linux-2.6.21-rc4/drivers/video/fbmem.c 2007-03-15 17:20:01.0
-0700
+++ linux-2.6.21-rc4-modesetting/drivers/video/fbmem.c 2007-04-26
18:16:52.0 -0700
@@ -1349,6 +1349,8 @@
if (!registered_fb[i])
return -EINVAL;
+ event.info = fb_info;
+ fb_notifier_call_chain(FB_EVENT_FB_UNBIND, event);
if (fb_info-pixmap.addr
(fb_info-pixmap.flags FB_PIXMAP_DEFAULT))
kfree(fb_info-pixmap.addr);
--- linux-2.6.21-rc4/include/linux/fb.h 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/include/linux/fb.h 2007-04-26
17:33:07.0 -0700
@@ -525,6 +525,8 @@
#define FB_EVENT_MODE_CHANGE_ALL 0x0B
/* A software display blank change occured */
#define FB_EVENT_CONBLANK 0x0C
+/* Unbind from the console if possible */
+#define FB_EVENT_FB_UNBIND 0x0E
struct fb_event {
struct fb_info *info;
--- linux-2.6.21-rc4/include/linux/console.h2007-03-15 17:20:01.0
-0700
+++ linux-2.6.21-rc4-modesetting/include/linux/console.h2007-04-26
17:56:31.0 -0700
@@ -64,6 +64,7 @@
extern const struct consw newport_con; /* SGI Newport console */
extern const struct consw prom_con;/* SPARC PROM console */
+int unbind_con_driver(const struct consw *csw, int first, int last, int deflt);
int con_is_bound(const struct consw *csw);
int register_con_driver(const struct consw *csw, int first, int last);
int unregister_con_driver(const struct consw *csw);
--- linux-2.6.21-rc4/drivers/video/console/fbcon.c 2007-03-15
17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/drivers/video/console/fbcon.c 2007-04-26
18:15:49.0 -0700
@@ -563,8 +563,10 @@
for (i = first_fb_vc; i = last_fb_vc; i++)
con2fb_map[i] = info_idx;
+ printk(KERN_ERR calling take_over_console, return value: );
err = take_over_console(fb_con, first_fb_vc, last_fb_vc,
fbcon_is_default);
+ printk(KERN_ERR %d\n, err);
if (err) {
for (i = first_fb_vc; i = last_fb_vc; i++) {
@@ -2896,6 +2898,13 @@
return found;
}
+static int fbcon_fb_unbind(int idx)
+{
+ unbind_con_driver(fb_con, 0, MAX_NR_CONSOLES - 1, 0);
+
+ return 0;
+}
+
static int fbcon_fb_unregistered(int idx)
{
int i;
@@ -2933,6 +2942,7 @@
{
int ret = 0, i;
+ printk(KERN_ERR fbcon registration called\n);
if (info_idx == -1) {
for (i = first_fb_vc; i = last_fb_vc; i++) {
if (con2fb_map_boot[i] == idx) {
@@ -2941,8 +2951,10 @@
}
}
- if (info_idx != -1)
+ if (info_idx != -1) {
+ printk(KERN_ERR fb taking over console\n);
ret = fbcon_takeover(1);
+ }
} else {
for (i = first_fb_vc; i = last_fb_vc; i++) {
if (con2fb_map_boot[i] == idx
@@ -3036,6 +3048,9 @@
mode = event-data;
ret = fbcon_mode_deleted(info, mode);
break;
+ case FB_EVENT_FB_UNBIND:
+ ret = fbcon_fb_unbind(info-node);
+ break;
case FB_EVENT_FB_REGISTERED:
ret = fbcon_fb_registered(info-node);
break;
--- linux-2.6.21-rc4/drivers/char/vt.c 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/drivers/char/vt.c 2007-04-26
18:22:42.0 -0700
@@ -2832,8 +2832,24 @@
return retval;
}
-static int unbind_con_driver(const struct consw *csw, int first, int last,
-int deflt)
+/**
+ * unbind_con_driver - unbind a console driver
+ * @csw: pointer to console driver to unregister
+ * @first: first in range of consoles that @csw should be unbound from
+ * @last: last in range of consoles that @csw should be unbound from
+ * @deflt: should next bound console driver be default after @csw is unbound?
+ *
+ * To unbind a driver from all possible consoles, pass 0 as @first and
+ * %MAX_NR_CONSOLES as @last.
+ *
+ * @deflt controls whether the console that ends up replacing @csw should be
+ * the default console.
+ *
+ * RETURNS:
+ * -ENODEV if @csw isn't a registered console driver or can't be unregistered
+ * or 0 on success.
+ */
+int unbind_con_driver(const struct consw *csw, int first, int last, int deflt)
{
struct module *owner = csw-owner;
const
Re: [PATCH 1/3] allow console unregistration
On Thursday, May 17, 2007 3:32 pm Jesse Barnes wrote: Randy just informed me that the patch limits are bigger now, so here are the actual patches. This patch allows for proper console unregistration via the VT layer, and updates the FB layer to use it. This makes debugging new console drivers much easier, since you can properly clean them up before unloading. Antonio already checked it out (and suggested a tweak for the fbcon side) so I think it's on its way already via the FB tree. And before someone complains, here's the diffstat: drivers/char/vt.c | 21 +++-- drivers/video/console/fbcon.c | 17 - drivers/video/fbmem.c |2 ++ include/linux/console.h |1 + include/linux/fb.h|2 ++ 5 files changed, 40 insertions(+), 3 deletions(-) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm modesetting core
On Thursday, May 17, 2007 3:37 pm Jesse Barnes wrote: This patch adds the core of the new DRM based modesetting system. It creates several new structures in the DRM, the primary ones being the CRTC, which controls all aspects of your device's CRTC(s), output, which describes and controls the various outputs on your gfx chip (e.g. TMDS, LVDS, VGA, etc.), and mode, which describes graphics modes in enough detail for the output and CRTC callbacks to program them to hardware. It also contains the user level IOCTL interfaces for doing graphics programming (getting CRTC, output and mode lists, setting up new frame buffer objects, etc.). It relies on the new TTM patch Dave posted recently. Makefile.kernel |6 drmP.h | 11 drm_bo.c|8 drm_bo_move.c |2 drm_bufs.c |3 drm_compat.h|7 drm_crtc.c | 1652 drm_crtc.h | 535 ++ drm_drv.c | 92 --- drm_edid.c | 467 +++ drm_edid.h | 176 + drm_fb.c| 201 ++ drm_fops.c |4 drm_modes.c | 558 ++ drm_objects.h | 22 drm_os_linux.h | 18 drm_stub.c | 21 drm_vm.c|5 18 files changed, 3695 insertions(+), 93 deletions(-) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] Intel support for DRM modesetting
On Thursday, May 17, 2007 3:40 pm Jesse Barnes wrote: This patch adds support for DRM modesetting to the Intel DRM driver and stubs out a simple FB driver to sit underneath. The code had to be refactored a bit, since current DRM drivers tend to be fully initialized by userspace via ioctls. This patch makes the driver load routine do most of the heavy lifting, since it's necessary in order to fully bring up a console driver. It also relies on the TTM patch Dave posted recently for allocating the initial framebuffer used by the FB layer. i915_drv.c|2 i915_init.c | 305 + intel_crt.c | 248 ++ intel_display.c | 1232 ++ intel_drv.h | 79 +++ intel_i2c.c | 187 intel_lvds.c | 500 + intel_modes.c | 55 ++ intel_sdvo.c | 1095 +++ intel_sdvo_regs.h | 328 ++ 10 files changed, 4030 insertions(+), 1 deletion(-) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/3] allow console unregistration
On Thursday, May 17, 2007, Antonino A. Daplas wrote: On Thu, 2007-05-17 at 15:32 -0700, Jesse Barnes wrote: Randy just informed me that the patch limits are bigger now, so here are the actual patches. This patch allows for proper console unregistration via the VT layer, and updates the FB layer to use it. This makes debugging new console drivers much easier, since you can properly clean them up before unloading. Antonio already checked it out (and suggested a tweak for the fbcon side) so I think it's on its way already via the FB tree. Sorry, I was busy and got sidetracked so I wasn't able to work on this for 2 weeks. Yes, this should work for now, at least for debugging purposes. I'll work on refining on fbcon side, hopefully for 2.6.22-2.6.23 time frame. No problem, I don't expect the rest of the code to be ready for awhile... This patch should be pretty close (modulo debugging statements and other bogons) to what we discussed earlier. I think the main change that's needed is to only unregister the specific console that was registered, rather than all of them. Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm modesetting core
On Thursday, May 17, 2007, Luca Tettamanti wrote:
Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto:
This patch adds the core of the new DRM based modesetting system.
A couple of comments on drm_fb since I'm somewhat familiar with fb code:
new file mode 100644
index 000..0d06792
--- /dev/null
+++ b/linux-core/drm_edid.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright (c) 2007 Intel Corporation
+ * Jesse Barnes [EMAIL PROTECTED]
+ *
+ * DDC probing routines (drm_ddc_read drm_do_probe_ddc_edid)
originally from
+ * FB layer.
Hum, why are you duplicating them here? fbmon.c has the
infrastructure for parsing and even fixing known-broken EDIDs.
Yeah, there's more sharing that could be done... though I don't think the
fb layer has the bits to actually grab EDIDs. Also, DRM is shared with
BSD...
+static bool edid_valid(struct edid *edid)
+{
+ int i;
+ u8 csum = 0;
+ u8 *raw_edid = (u8 *)edid;
+
+ if (memcmp(edid-header, edid_header, sizeof(edid_header)))
+ goto bad;
+ if (edid-version != 1)
+ goto bad;
+ if (edid-revision = 0 || edid-revision 3)
+ goto bad;
+
+ for (i = 0; i EDID_LENGTH; i++)
+ csum += raw_edid[i];
+ if (csum)
+ goto bad;
+
+ return 1;
+
+bad:
+ return 0;
+}
This is basically edid_check_header + edid_checksum.
Yep, pretty trivial stuff.
get_detailed_timing?
If you can't use 'struct fb_videomode' we may refactor code around a
common data structure instead of a copypaste.
I agree that would be better. I'll see what I can do to unify the two.
+static unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter
*adapter)
[...]
+static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
[...]
Copy and paste from fb_dcc.c; furthermore a fix in drm_ddc_read hasn't
been backported to the original code.
I think the original tries a few times... but it's still buggy. I've got
an old EDID 1.1 monitor whose EDID block is fetched by X but not by this
code (or the original FB code) so I think we still have some timing bugs
to fix.
+ info = framebuffer_alloc(sizeof(struct drmfb_par), device);
+ if (!info){
+ return -EINVAL;
+ }
-ENOMEM? Plus, spurious brackets.
Fixed, thanks.
+ if (register_framebuffer(info) 0)
+ return -EINVAL;
You leak the fb_info structure on error path.
Oops, I'll fix that too.
At this point though, the drm_fb driver isn't actually used. I recently
added the intel_fb driver (mostly using code from intelfb) so we could
have an accelerated DRM FB driver, hopefully that one's ok.
Thanks for looking at it.
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm modesetting core
On Friday, May 18, 2007 12:33 pm Luca Tettamanti wrote: Yeah, there's more sharing that could be done... though I don't think the fb layer has the bits to actually grab EDIDs. There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I wrote them for the radeon driver, but now are available for general use) which will issue the read command; fbmon.c has the stuff for parsing the EDID; you usualy build a DB of supported modes which is then used to validate the mode requested by the user. Of course each driver has to implement the I2C adapter. I'll take a look at fbmon... I've seen the fb_ddc_read stuff but didn't see many drivers using it heavily. I think it makes sense to reuse your code where possible (in fact some earlier versions of the code made more use of FB stuff but was removed or rewritten for various reasons). Also, DRM is shared with BSD... Your patch already uses 'struct i2c_adapter' in drm_edid.c, is it portable? I'm not sure how portable that will be. But regardless, if Linux has some of this code already, I'd like to reuse it. I'll go head and see what I can rip out. In fact, I've received some comments pushing me towards moving the core code (crtc, mode management) to drivers/video instead of DRM. That might make sense, especially if we can just use/extend the FB layer's mode tracking structures. Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] enhancing the kernel's graphics subsystem
On Monday, May 21, 2007, Benjamin Herrenschmidt wrote: In collaboration with the FB guys, we've been working on enhancing the kernel's graphics subsystem in an attempt to bring some sanity to the Linux graphics world and avoid the situation we have now where several kernel and userspace drivers compete for control of graphics devices. .../... A little note about initial mode setting at boot... I do stongly beleive that the decision of what mode to choose should not be made in the kernel. At boot the kernel should either leave the HW in whatever state the FW set it (and text mode is fine) or setup some sane default (ie 640x480 has the most chances of working) if that's not an option, maybe some very minimum EDID parsing in case you have a fixed frequency weirdo panel, but that's it (unless it's a mac an OF tells you what to use :-) The kernel would provide userland with connector infos (presence load detect, EDID, ...) and userland gets to decide what to do. The current code does its best to figure out what modes are available and tries to pick a good one for each display. It sounds like you're mainly concerned with the actual mode picking, not the mode and output detection and enumeration? If so, that's a pretty easy change to make. But if you're also worried about the kernel building mode lists, then we'll have bigger changes to make... Some reasons to keep that policy completely out of the kernel even at boot time are: - User may want to configure his default gfx setup and have it up early - EDID do lie, monitors routinely ship with windows .inf files containing updated infos apple has that too in OS X (EDID overrides afaik) etc and if we're going to do such a database of known monitors, it should definitely not be in the kernel. Besides, we want to add more infos that EDIDs don't provide most of the time to it like subpixel ordering etc... - It sounds better that way :-) (yeah, that's the best reason !) So while I agree that the register frobbing, memory management, etc... should be indeed moved to the kernel as you guys have been doing lately, the policy of deciding what mode to set should totally stick to userland. IMHO, the best would be a lib (or daemon or both) for monitor detection mode setting that is separate from X :-) That could handle storing the admin's default setup (including weird monitor info if any) and restoring it at boot time, etc... I'm not really sure how much of a problem broken EDIDs will be. The X server only has a few quirks for broken EDIDs now, nothing major afaict, and apparently the FB layer already has some code for handling EDID quirks, so I don't think that'll be our biggest problem. So far, it looks like handling laptop panels is a bit trickier (at least for Intel chips)... Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] enhancing the kernel's graphics subsystem
On Tuesday, May 22, 2007, Philipp Klaus Krause wrote: Benjamin Herrenschmidt schrieb: In collaboration with the FB guys, we've been working on enhancing the kernel's graphics subsystem in an attempt to bring some sanity to the Linux graphics world and avoid the situation we have now where several kernel and userspace drivers compete for control of graphics devices. What's the difference between this and Jon Smirls' proposals from early 2005? There are lots of differences. From memory, Jon tried to enhance the FB layer to do modesetting with an eye toward multiseat support. Modes were set by echoing values into sysfs, and iirc it didn't tie into the DRM layer at all or use proper memory management. These patches use ioctls on the DRM device for modesetting (at least for now), and provide userspace with maximum flexibility. Framebuffer objects are allocated using the new DRM memory manager, and any FB devices created are slaves of the DRM layer, avoiding some of the fighting over suspend/resume and graphics programming. Many of the aims are the same though, Jon was trying to address many of the problems outlined in my initial mail too, we just have different opinions about how exactly those problems should be solved. :) Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] enhancing the kernel's graphics subsystem
On Tuesday, May 22, 2007, Benjamin Herrenschmidt wrote: On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote: The current code does its best to figure out what modes are available and tries to pick a good one for each display. It sounds like you're mainly concerned with the actual mode picking, not the mode and output detection and enumeration? If so, that's a pretty easy change to make. But if you're also worried about the kernel building mode lists, then we'll have bigger changes to make... I'm worried that the EDID we get from the monitor is bogus and needs to be overriden. Now, if the kernel builds a mode list, that's find if we have a call to feed it with a replacement one later on from userland. In addition, there are all those monitors that cannot be probed (no DDC/EDID) and for which only userland can reasonably provide a mode or a mode list. Yeah, we already have a call to add modes to the kernel's list, so we should be covered. So it's a bit of both :-) Building an initial mode list from the EDID might be fair enough if we can replace it soon enough, but we still need to be very conservative about whatever boot mode we choose. Right. I'm not really sure how much of a problem broken EDIDs will be. The X server only has a few quirks for broken EDIDs now, nothing major afaict, and apparently the FB layer already has some code for handling EDID quirks, so I don't think that'll be our biggest problem. So far, it looks like handling laptop panels is a bit trickier (at least for Intel chips)... Well, I've seen my share of broken EDID.. Last time I looked at Darwin, I think I saw Apple maintaining a fairly huge database of EDID replacements in userland... Interesting... I wonder how the distro monitor databases compare. Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] update DRM core vblank code to be more power friendly
We've had some IRC and off-list discussions about how to improve the
DRM's vblank code to be a bit more power friendly. The core requirement
is that we only enable vblank interrupts when a client is actually waiting
for a vblank event (be it a signal or a wakeup).
This patch updates the DRM core, requiring drivers to provide vblank
enable and disable hooks, as well as a counter updater, and adds some
i915 code to use it.
When the DRM vblank code is called, the core will update the counter,
add the desired sequence value to it, and either setup a signal or
wait for the desired sequence number to be hit, enabling vblanks around
the operation. Once complete, vblank interrupts will again be disabled
to save power.
The patch doesn't yet deal with two obvious cases (and probably more
that I'm missing, it's untested yet):
- the hardware counter resets on mode switch, we need to rebase
the appropriate last_counter at that point so it's not treated as
a counter wrap
- a client interested in signals but also blocked on a vblank event
may cause vblanks to be disabled if it received signal at the wrong
time
I'll be happy to fix it up and/or restructure as requested. I think the
basic approach should be fairly sound (even devices that don't support a
counter register could fake it using total time/vrefresh or similar), but
if not I'd love to hear about it. :)
Thanks,
Jesse
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index dd3a69d..31293a8 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -627,8 +627,9 @@ struct drm_driver {
int (*kernel_context_switch) (struct drm_device * dev, int old,
int new);
void (*kernel_context_switch_unlock) (struct drm_device * dev);
- int (*vblank_wait) (struct drm_device * dev, unsigned int *sequence);
- int (*vblank_wait2) (struct drm_device * dev, unsigned int *sequence);
+ u32 (*update_vblank_count) (struct drm_device *dev, int crtc);
+ void (*enable_vblank) (struct drm_device *dev, int crtc);
+ void (*disable_vblank) (struct drm_device *dev, int crtc);
int (*dri_library_name) (struct drm_device * dev, char * buf);
/**
@@ -783,8 +784,6 @@ typedef struct drm_device {
/[EMAIL PROTECTED] */
wait_queue_head_t vbl_queue;/** VBLANK wait queue */
- atomic_t vbl_received;
- atomic_t vbl_received2; /** number of secondary VBLANK
interrupts */
spinlock_t vbl_lock;
struct list_head vbl_sigs; /** signal list to send on
VBLANK */
struct list_head vbl_sigs2; /** signals to send on secondary
VBLANK */
diff --git a/linux-core/drm_irq.c b/linux-core/drm_irq.c
index 8871671..ad3ceff 100644
--- a/linux-core/drm_irq.c
+++ b/linux-core/drm_irq.c
@@ -248,7 +248,7 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
drm_wait_vblank_t vblwait;
struct timeval now;
int ret = 0;
- unsigned int flags, seq;
+ unsigned int flags, seq, crtc, cur_vblank;
if ((!dev-irq) || (!dev-irq_enabled))
return -EINVAL;
@@ -265,13 +265,13 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
}
flags = vblwait.request.type _DRM_VBLANK_FLAGS_MASK;
+ crtc = flags _DRM_VBLANK_SECONDARY ? 1 : 0;
if (!drm_core_check_feature(dev, (flags _DRM_VBLANK_SECONDARY) ?
DRIVER_IRQ_VBL2 : DRIVER_IRQ_VBL))
return -EINVAL;
- seq = atomic_read((flags _DRM_VBLANK_SECONDARY) ? dev-vbl_received2
- : dev-vbl_received);
+ seq = dev-driver-update_vblank_count(dev, crtc);
switch (vblwait.request.type _DRM_VBLANK_TYPES_MASK) {
case _DRM_VBLANK_RELATIVE:
@@ -332,6 +332,8 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
vbl_sig-info.si_signo = vblwait.request.signal;
vbl_sig-task = current;
+ dev-driver-enable_vblank(dev, crtc);
+
spin_lock_irqsave(dev-vbl_lock, irqflags);
list_add_tail(vbl_sig-head, vbl_sigs);
@@ -340,17 +342,15 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
vblwait.reply.sequence = seq;
} else {
- if (flags _DRM_VBLANK_SECONDARY) {
- if (dev-driver-vblank_wait2)
- ret = dev-driver-vblank_wait2(dev,
vblwait.request.sequence);
- } else if (dev-driver-vblank_wait)
- ret =
- dev-driver-vblank_wait(dev,
-vblwait.request.sequence);
-
+ dev-driver-enable_vblank(dev, crtc);
+ DRM_WAIT_ON(ret, dev-vbl_queue, 3 * DRM_HZ,
+ (((cur_vblank =
+ dev-driver-update_vblank_count(dev, crtc))
+ - seq) = (1 23)));
do_gettimeofday(now);
Re: [RFC] update DRM core vblank code to be more power friendly
On Monday, June 11, 2007 11:14:45 Ian Romanick wrote: Jesse Barnes wrote: We've had some IRC and off-list discussions about how to improve the DRM's vblank code to be a bit more power friendly. The core requirement is that we only enable vblank interrupts when a client is actually waiting for a vblank event (be it a signal or a wakeup). This patch updates the DRM core, requiring drivers to provide vblank enable and disable hooks, as well as a counter updater, and adds some i915 code to use it. When the DRM vblank code is called, the core will update the counter, add the desired sequence value to it, and either setup a signal or wait for the desired sequence number to be hit, enabling vblanks around the operation. Once complete, vblank interrupts will again be disabled to save power. The patch doesn't yet deal with two obvious cases (and probably more that I'm missing, it's untested yet): - the hardware counter resets on mode switch, we need to rebase the appropriate last_counter at that point so it's not treated as a counter wrap - a client interested in signals but also blocked on a vblank event may cause vblanks to be disabled if it received signal at the wrong time I'll be happy to fix it up and/or restructure as requested. I think the basic approach should be fairly sound (even devices that don't support a counter register could fake it using total time/vrefresh or similar), but if not I'd love to hear about it. :) The problem is that a few of the GLX extensions (e.g., GLX_SGI_video_sync and GLX_OML_sync_control) allow applications to query the vblank counter directly. I don't know of other hardware that maintains an actual counter. I know that MGA doesn't, and I'm pretty sure that Via doesn't either. Right, we still have to expose the counter. But that just means calling the update_vblank_counter hook before returning it to userspace. And of course, another option for devices that don't have vblank count registers (aside from the 'fake it based on time' mentioned above) would be to just leave interrupts enabled and do the counting there as usual. That would make the enable/disable hooks no-ops, and the update_vblank_counter into a simple return of the latest value. Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] update DRM core vblank code to be more power friendly
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
On Mon, 2007-06-11 at 10:59 -0700, Jesse Barnes wrote:
The patch doesn't yet deal with two obvious cases (and probably more
that I'm missing, it's untested yet):
- the hardware counter resets on mode switch, we need to rebase
the appropriate last_counter at that point so it's not treated as
a counter wrap
I think this should be handled in the core by having an offset that
relates the hardware counter to the software visible value. Mode setting
would then 'rebase' the offset to make the user-visible value change
smoothly:
pre_mode_set
old = current raw hardware counter
post_mode_set
new = current raw hardware counter
offset += old - new
now create a 'cooked' hardware counter:
cooked hardware counter = offset + raw hardware counter
Yep, sounds reasonable.
- a client interested in signals but also blocked on a vblank event
may cause vblanks to be disabled if it received signal at the wrong
time
the core should track a per-crtc enable/disable count and call the
driver when it transitions through zero.
Yeah, I think there's even a 'vbl_pending' counter I can use for this, though
I'll have to make it atomic.
+ unsigned long last_vblank_count[2];
+ atomic_t vblank_count[2];
For a first implementation, I suggest that the driver never store this
value and just read from the registers every time it fetches the frame
counter. You could 'optimize' reading when the interrupt was running by
caching the last value, but this will be race-prone.
I'm using last_vblank_count to deal with wrapping (as you see below), and
vblank_count is the total vblank value (including all wraps).
+ /*
+* Now update the appropriate counter.
+* Assume we haven't missed a full 24 bits of vblank
+* events, or that it won't matter if they're not accounted
+* for when we adjust for wrapping.
+* FIXME: if count was zero'd due to modeset, need to rebase
+*/
+ spin_lock_irqsave(dev-vbl_lock, irqflags);
+ if (count dev_priv-last_vblank_count[crtc]) {
+ diff = 0xff - dev_priv-last_vblank_count[crtc];
+ diff += count;
+ } else {
+ diff = count - dev_priv-last_vblank_count[crtc];
+ }
+ dev_priv-last_vblank_count[crtc] = count;
+ spin_unlock_irqrestore(dev-vbl_lock, irqflags);
+ atomic_add(diff, dev_priv-vblank_count[crtc]);
+ return atomic_read(dev_priv-vblank_count[crtc]);
ick. just read the registers and return the value here. We should place
wrap-detection in the core code by reporting the range of the register
values; with the offset suggested above, that would result in a single
addition to convert from raw to cooked frame counts.
Hm, yeah I guess it might be nicer in the core. I was thinking that this
would give the driver maximum flexibility and avoid the need for a 'max
value' callback or field, but that may be a net win.
Thanks,
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] update DRM core vblank code to be more power friendly
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
ick. just read the registers and return the value here. We should place
wrap-detection in the core code by reporting the range of the register
values; with the offset suggested above, that would result in a single
addition to convert from raw to cooked frame counts.
Ok, here's an updated version:
- move wraparound logic to the core
- add pre/post modeset ioctls (per-driver right now, making them core would
mean lots more DDX changes I think), hope I got this right
- add vblank_get/put calls so interrupts are enabled at the right time
I haven't implemented Ville's suggestion of adding a short timer before
disabling interrupts again, but it should be easy now that the get/put
routines are in place and we think it's worth it (might make vblank
calls a little cheaper, but it would probably be hard to detect).
Any more thoughts? If it looks good, I'll go ahead and test it, clean it up a
bit,
and convert my old radeon patch over to this new scheme (other drivers will need
work too though).
Thanks,
Jesse
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index dd3a69d..ed0e0b7 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -627,8 +627,9 @@ struct drm_driver {
int (*kernel_context_switch) (struct drm_device * dev, int old,
int new);
void (*kernel_context_switch_unlock) (struct drm_device * dev);
- int (*vblank_wait) (struct drm_device * dev, unsigned int *sequence);
- int (*vblank_wait2) (struct drm_device * dev, unsigned int *sequence);
+ u32 (*get_vblank_counter) (struct drm_device *dev, int crtc);
+ void (*enable_vblank) (struct drm_device *dev, int crtc);
+ void (*disable_vblank) (struct drm_device *dev, int crtc);
int (*dri_library_name) (struct drm_device * dev, char * buf);
/**
@@ -783,12 +784,12 @@ typedef struct drm_device {
/[EMAIL PROTECTED] */
wait_queue_head_t vbl_queue;/** VBLANK wait queue */
- atomic_t vbl_received;
- atomic_t vbl_received2; /** number of secondary VBLANK
interrupts */
+ atomic_t *vblank_count; /** number of VBLANK interrupts
(driver must alloc the right number of counters) */
spinlock_t vbl_lock;
struct list_head vbl_sigs; /** signal list to send on
VBLANK */
struct list_head vbl_sigs2; /** signals to send on secondary
VBLANK */
- unsigned int vbl_pending;
+ atomic_t *vbl_pending;
+ unsigned long max_vblank_count; /** size of vblank counter register */
spinlock_t tasklet_lock;/** For drm_locked_tasklet */
void (*locked_tasklet_func)(struct drm_device *dev);
diff --git a/linux-core/drm_irq.c b/linux-core/drm_irq.c
index 8871671..d9c396a 100644
--- a/linux-core/drm_irq.c
+++ b/linux-core/drm_irq.c
@@ -221,6 +221,42 @@ int drm_control(struct inode *inode, struct file *filp,
}
}
+static u32 last_vblank; /* protected by dev-vbl_lock */
+static void drm_vblank_get(drm_device_t *dev, int crtc)
+{
+ unsigned long irqflags;
+ u32 cur_vblank, diff;
+
+ if (atomic_add_return(1, dev-vbl_pending[crtc]) != 1)
+ return;
+
+ /*
+* Interrpts were disabled prior to this call, so deal with counter
+* wrap if needed.
+*/
+ cur_vblank = dev-driver-get_vblank_counter(dev, crtc);
+ spin_lock_irqsave(dev-vbl_lock, irqflags);
+ if (cur_vblank last_vblank) {
+ diff = dev-max_vblank_count -
+ last_vblank;
+ diff += cur_vblank;
+ } else {
+ diff = cur_vblank - last_vblank;
+ }
+ last_vblank = cur_vblank;
+ spin_unlock_irqrestore(dev-vbl_lock, irqflags);
+
+ atomic_add(diff, dev-vblank_count[crtc]);
+ dev-driver-enable_vblank(dev, crtc);
+}
+
+static void drm_vblank_put(drm_device_t *dev, int crtc)
+{
+ if (atomic_dec_and_test(dev-vbl_pending[crtc]))
+ dev-driver-disable_vblank(dev, crtc);
+}
+
+
/**
* Wait for VBLANK.
*
@@ -248,7 +284,7 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
drm_wait_vblank_t vblwait;
struct timeval now;
int ret = 0;
- unsigned int flags, seq;
+ unsigned int flags, seq, crtc;
if ((!dev-irq) || (!dev-irq_enabled))
return -EINVAL;
@@ -265,13 +301,13 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
}
flags = vblwait.request.type _DRM_VBLANK_FLAGS_MASK;
+ crtc = flags _DRM_VBLANK_SECONDARY ? 1 : 0;
if (!drm_core_check_feature(dev, (flags _DRM_VBLANK_SECONDARY) ?
DRIVER_IRQ_VBL2 : DRIVER_IRQ_VBL))
return -EINVAL;
- seq = atomic_read((flags _DRM_VBLANK_SECONDARY) ? dev-vbl_received2
- : dev-vbl_received);
+ seq = atomic_read(dev-vblank_count[crtc]);
switch
Re: [RFC] update DRM core vblank code to be more power friendly
On Monday, June 11, 2007 6:42:09 Keith Packard wrote:
On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
+static u32 last_vblank; /* protected by dev-vbl_lock */
uh. per crtc?
Oh, hm yeah. I guess it'll have to go in drm_device.
+ atomic_add(diff, dev-vblank_count[crtc]);
Ok, I think this is reasonable, although different from what I
suggested.
This is just wraparound handling.
+ seq = atomic_read(dev-vblank_count[crtc]);
Isn't this way too early? Seems like you'd want to get a reasonably
up-to-date value here; should this be after drm_vblank_get?
Oh you're right about that, otherwise we'll end up with lots of events in the
past.
+u32 i915_get_vblank_counter(drm_device_t *dev, int crtc)
+{
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
+ return i915_vblank_counter(dev, crtc) + dev_priv-vblank_offset[crtc];
+}
I thought you were doing the offset stuff in core?
I thought about it, but if I did, it would require lots of DDX changes I
think? Dave convinced me it should actually be a driver specific SETPARAM,
so after posting this patch I converted to that interface.
+
+int i915_premodeset(DRM_IOCTL_ARGS)
+{
+ DRM_DEVICE;
+ drm_i915_private_t *dev_priv = dev-dev_private;
+
+ int crtc = data;
+
+ if (crtc 1) {
+ DRM_ERROR(bad crtc\n);
+ return -EINVAL;
+ }
+
+ dev_priv-vblank_premodeset[crtc] = i915_vblank_counter(dev, crtc);
+ return 0;
+}
+
+int i915_postmodeset(DRM_IOCTL_ARGS)
+{
+ DRM_DEVICE;
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ u32 new;
+ int crtc = data;
+
+ if (crtc 1) {
+ DRM_ERROR(bad crtc\n);
+ return -EINVAL;
+ }
+
+ new = i915_vblank_counter(dev, crtc);
+ dev_priv-vblank_offset[crtc] = dev_priv-vblank_premodeset[crtc] -
new; + return 0;
+}
Ah, ok, offsets in driver.
Since most drivers don't do randr-1.2 yet, poking around in their modesetting
code to make a generic DRM call seemed like overkill. I think a per-driver
setparam will get away from this, though either way we'll be stuck with a
dead interface once kernel modesetting is ready.
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] update DRM core vblank code to be more power friendly
On Monday, June 11, 2007 7:13:04 Jesse Barnes wrote: On Monday, June 11, 2007 6:42:09 Keith Packard wrote: On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote: +static u32 last_vblank; /* protected by dev-vbl_lock */ uh. per crtc? Oh, hm yeah. I guess it'll have to go in drm_device. Actually with the lock there I think it's safe. But if I move it to drm_device I can get rid of the locking, so I guess I'll do that (that way we can call drm_vblank_get under the vbl_lock). Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] update DRM core vblank code to be more power friendly
On Monday, June 11, 2007 11:59:23 Michel Dänzer wrote:
On Mon, 2007-06-11 at 15:20 -0700, Jesse Barnes wrote:
On Monday, June 11, 2007 11:36:10 Keith Packard wrote:
ick. just read the registers and return the value here. We should
place wrap-detection in the core code by reporting the range of
the register values; with the offset suggested above, that would
result in a single addition to convert from raw to cooked frame
counts.
Ok, here's an updated version:
- move wraparound logic to the core
- add pre/post modeset ioctls (per-driver right now, making them
core would mean lots more DDX changes I think),
Shouldn't really matter, DDX drivers can call driver independent
ioctls.
Yeah, that's true. It could also be called from the server's new
modesetting code, so that converted drivers would automatically
benefit. I just wanted to avoid having to update every driver, but I
think we can avoid that in either case.
@@ -265,13 +301,13 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
}
flags = vblwait.request.type _DRM_VBLANK_FLAGS_MASK;
+ crtc = flags _DRM_VBLANK_SECONDARY ? 1 : 0;
if (!drm_core_check_feature(dev, (flags _DRM_VBLANK_SECONDARY)
? DRIVER_IRQ_VBL2 : DRIVER_IRQ_VBL))
return -EINVAL;
- seq = atomic_read((flags _DRM_VBLANK_SECONDARY) ?
dev-vbl_received2 - : dev-vbl_received);
+ seq = atomic_read(dev-vblank_count[crtc]);
switch (vblwait.request.type _DRM_VBLANK_TYPES_MASK) {
case _DRM_VBLANK_RELATIVE:
This value is used as the basis for relative waits, so you need to
make sure it's up to date.
Yeah, Keith mentioned this too, I've fixed it in my tree.
@@ -311,15 +347,15 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
}
}
- if (dev-vbl_pending = 100) {
+ if (atomic_read(dev-vbl_pending[crtc]) = 100) {
spin_unlock_irqrestore(dev-vbl_lock, irqflags);
return -EBUSY;
}
Previously, dev-vbl_pending was only used to make sure userspace
can't exhaust memory by scheduling an infinite number of signals. I
don't think this is necessary for blocking calls (as every process
can only do one such call at a time), is it?
I don't think so... we should be able to catch that case through a
regular system wide process count limit (though we'll probably hit a
memory or other resource problem first).
@@ -313,14 +313,14 @@ irqreturn_t
i915_driver_irq_handler(DRM_IRQ_ARGS)
(DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B))
== (DRM_I915_VBLANK_PIPE_A | DRM_I915_VBLANK_PIPE_B)) {
if (temp VSYNC_PIPEA_FLAG)
- atomic_inc(dev-vbl_received);
+ atomic_inc(dev-vblank_count[0]);
if (temp VSYNC_PIPEB_FLAG)
- atomic_inc(dev-vbl_received2);
+ atomic_inc(dev-vblank_count[1]);
} else if (((temp VSYNC_PIPEA_FLAG)
(vblank_pipe DRM_I915_VBLANK_PIPE_A)) ||
((temp VSYNC_PIPEB_FLAG)
(vblank_pipe DRM_I915_VBLANK_PIPE_B)))
- atomic_inc(dev-vbl_received);
+ atomic_inc(dev-vblank_count[0]);
DRM_WAKEUP(dev-vbl_queue);
drm_vbl_send_signals(dev);
Maybe this should use i915_get_vblank_counter() instead of just
incrementing, in case e.g. an interrupt is missed.
Yeah, that's a good idea. And I think it could simplify this logic a
bit?
@@ -489,15 +458,116 @@ int i915_irq_wait(DRM_IOCTL_ARGS)
return i915_wait_irq(dev, irqwait.irq_seq);
}
-static void i915_enable_interrupt (drm_device_t *dev)
+void i915_enable_vblank(drm_device_t *dev, int crtc)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *)
dev-dev_private;
- dev_priv-irq_enable_reg = USER_INT_FLAG;
- if (dev_priv-vblank_pipe DRM_I915_VBLANK_PIPE_A)
+ switch (crtc) {
+ case 0:
dev_priv-irq_enable_reg |= VSYNC_PIPEA_FLAG;
- if (dev_priv-vblank_pipe DRM_I915_VBLANK_PIPE_B)
+ break;
+ case 1:
dev_priv-irq_enable_reg |= VSYNC_PIPEB_FLAG;
+ break;
+ default:
+ DRM_ERROR(tried to enable vblank on non-existent crtc %d\n,
+ crtc);
+ break;
+ }
+
+ I915_WRITE16(I915REG_INT_ENABLE_R, dev_priv-irq_enable_reg);
+}
Does this need to check that the X server enabled the vblank
interrupt for the pipe? What would happen if this ended up enabling
it for an inactive pipe?
Hm, we might get nonsensical values or a non-incrementing vblank count,
but otoh userspace didn't bother to enable vblank events for the pipe
it just requested one for, so maybe undefined behavior is ok?
If not, it would be easy to check the dev_priv
Re: [RFC] update DRM core vblank code to be more power friendly
On Tuesday, June 12, 2007 7:53:13 Ian Romanick wrote: If an app is running with swap buffers synchronized to vblank, won't it go through the following: - Render scene. - Start to wait for vblank. - Enable vblank int. - Wait. - Disable vblank int. - Do swap. - Repeat. Isn't there some cost associated with the extra enable / disable of the vblank interrupt? Yeah, but it's typically just one additional write as Michel pointed out. In addition, the fake wall clock based vblank counter might have accuracy problems with periods of only one or two vblanks. Unfortunately, these are the cases where apps will care the most about accuracy. Really? Refresh rates aren't very high relative to the event accuracy we have in the kernel; we should be able to schedule an event with good granularity, hopefully more than enough to hit a vblank window. But like I said in my original post, drivers that don't have a vblank counter register have a couple of options: 1) never disable interrupts, continue tracking events as usual 2) use a timer to keep the vblank counter accurate across interrupt off periods If it turns out that accuracy really is an issue, we can easily add the delay Ville talked about to keep things easy for those drivers, but I suspect option (1) is probably the best one for such hardware anyway. Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] update DRM core vblank code to be more power friendly
On Tuesday, June 12, 2007 10:58:24 Keith Packard wrote:
On Tue, 2007-06-12 at 19:23 +0200, Michel Dänzer wrote:
That would mean one register read sequence per waiter per interrupt
whereas otherwise it's one read sequence per CRTC (which is enabled
and has waiters) per interrupt. Looks like the latter can be made
to be more efficient.
So, just so I understand the basic control flow:
wait_for_vblank (crtc, seq)
{
enable_irq (crtc)
while ((seq - crtc-current_seq) 0)
block ();
disable_irq (crtc)
}
enable_irq (crtc)
{
if (enable_count++ == 0) {
set_interrupts_enabled (crtc);
crtc-current_seq = read_frame_count (crtc)
}
}
disable_irq (crtc)
{
if (--enable_count == 0)
set_interrupts_disabled (crtc);
}
irq ()
{
if (status interrupt_crtc0)
crtc0-current_seq = read_frame_count (crtc0);
if (status interrupt_crtc1)
crtc1-current_seq = read_frame_count (crtc1);
wakeup ();
}
This looks good, but like Michel said, if only one pipe's vblank is
enabled, only the primary vblank counter should be updated (regardless
of *which* vblank count is enabled). But maybe that can be done at a
higher level, or maybe we can change that behavior and just make things
per-crtc as I've done with most of the code.
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] update DRM core vblank code to be more power friendly
On Tuesday, June 12, 2007 10:05:46 Keith Packard wrote: On Tue, 2007-06-12 at 09:40 -0700, Jesse Barnes wrote: Hm, we might get nonsensical values or a non-incrementing vblank count, but otoh userspace didn't bother to enable vblank events for the pipe it just requested one for, so maybe undefined behavior is ok? The 'undefined' behaviour here is that the frame count will never arrive so the client will block forever. If not, it would be easy to check the dev_priv-vblank_pipe value for sanity here. That, and we should also wake everyone up when crtcs are reconfigured so clients can reset which crtc they're waiting for. Does that belong in the vblank_enable routine or in a new modeset routine? Btw, I pushed all the latest stuff (including the changes Michel recommended) into the vblank-rework tree of mesa/drm. I've tested on one machine here at hasn't crashed yet and things seem to be working ok... Now to test without the vblank disable stuff Eric put in the DDX driver... Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework'
On Wednesday, June 13, 2007 12:24:05 Michel Dänzer wrote:
On Tue, 2007-06-12 at 13:37 -0700, Jesse Barnes wrote:
diff --git a/linux-core/drm_irq.c b/linux-core/drm_irq.c
index f229f77..8125b75 100644
--- a/linux-core/drm_irq.c
+++ b/linux-core/drm_irq.c
@@ -77,6 +77,70 @@ int drm_irq_by_busid(struct inode *inode
return 0;
}
+int drm_vblank_init(drm_device_t *dev, int num_crtcs)
+{
+ int i, ret = -ENOMEM;
+
+ init_waitqueue_head(dev-vbl_queue);
+ spin_lock_init(dev-vbl_lock);
+ atomic_set(dev-vbl_pending, 0);
+ dev-num_crtcs = num_crtcs;
+
+ dev-vbl_sigs = drm_alloc(sizeof(struct list_head) * num_crtcs,
+ DRM_MEM_DRIVER);
[...]
+ ret = 0;
+ goto out;
Just return 0? :)
Sure, I was just trying to avoid having more than one return, but I
don't care too much.
+err:
+ kfree(dev-vbl_sigs);
Mismatch between drm_alloc() and kfree(). If the code stays in a
Linux specific file, you can use kmalloc.
Oops, yeah that should be fixed.
@@ -359,6 +450,8 @@ int drm_wait_vblank(DRM_IOCTL_ARGS)
spin_unlock_irqrestore(dev-vbl_lock, irqflags);
+ atomic_inc(dev-vbl_pending);
+
if (!
(vbl_sig =
drm_alloc(sizeof(drm_vbl_sig_t), DRM_MEM_DRIVER))) {
This increases the count before we know we really schedule a new
signal. (Was broken before the rework, just noticed it now)
Ok I'll fix that.
@@ -414,9 +507,9 @@ void drm_vbl_send_signals(drm_device_t *
spin_lock_irqsave(dev-vbl_lock, flags);
- for (i = 0; i 2; i++) {
+ for (i = 0; i dev-num_crtcs; i++) {
drm_vbl_sig_t *vbl_sig, *tmp;
- struct list_head *vbl_sigs = i ? dev-vbl_sigs2 :
dev-vbl_sigs; + struct list_head *vbl_sigs = dev-vbl_sigs[i];
unsigned int vbl_seq = atomic_read(dev-vblank_count[i]);
list_for_each_entry_safe(vbl_sig, tmp, vbl_sigs, head) {
As has been discussed in other posts, it would probably be nice if
everything including this and the blocking waitqueues was per CRTC. I
think there could be a single drm_vblank_handler(drm_device_t *dev,
int crtc) function to be called from the driver's interrupt handler
which takes care of waking up the CRTC waitqueue and sending its
pending signals.
Yeah, it probably won't help much from a performance perspective but
would make the code cleaner.
+typedef struct drm_modeset_ctl {
+ drm_modeset_ctl_cmd_t cmd;
+ unsigned long arg;
+} drm_modeset_ctl_t;
unsigned long is bad for 32 bit userland on a 64 bit kernel.
Yeah, it should probably be u64, or a real per-subioctl command union.
@@ -953,6 +968,8 @@ typedef union drm_mm_init_arg{
#define DRM_IOCTL_UPDATE_DRAW DRM_IOW(0x3f,
drm_update_draw_t)
+#define DRM_IOCTL_MODESET_CTL DRM_IOW(0x40,
drm_modeset_ctl_t)
0x40 is the first driver specific ioctl. There's a second driver
independent range starting at 0xa0 (DRM_COMMAND_END).
Oops, ok I'll fix that.
+ if (temp VSYNC_PIPEA_FLAG)
+ atomic_add(i915_get_vblank_counter(dev, 0),
+ dev-vblank_count[0]);
+ if (temp VSYNC_PIPEB_FLAG)
+ atomic_add(i915_get_vblank_counter(dev, 1),
+ dev-vblank_count[1]);
I think atomic_add is wrong here.
Hm yeah it should be just atomic_set(), duh.
@@ -461,6 +481,9 @@ int i915_irq_wait(DRM_IOCTL_ARGS)
void i915_enable_vblank(drm_device_t *dev, int crtc)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *)
dev-dev_private; +
+ if (crtc dev_priv-vblank_pipe)
+ return;
Should be something like !(dev_priv-vblank_pipe (1 crtc)).
Yeah, that's a better check.
@@ -660,6 +638,7 @@ int i915_vblank_swap(DRM_IOCTL_ARGS)
spin_unlock_irqrestore(dev-drw_lock, irqflags);
+ drm_vblank_get(dev, pipe);
curseq = atomic_read(dev-vblank_count[pipe]);
if (seqtype == _DRM_VBLANK_RELATIVE)
@@ -670,6 +649,7 @@ int i915_vblank_swap(DRM_IOCTL_ARGS)
swap.sequence = curseq + 1;
} else {
DRM_DEBUG(Missed target sequence\n);
+ drm_vblank_put(dev, pipe);
return DRM_ERR(EINVAL);
}
}
I think updating the counters should be split off drm_vblank_get(),
so it can only be called once it's known the interrupt needs to be
enabled, and drm_vblank_put() doesn't need to be added to every error
path. (As a bonus, the interrupt never gets needlessly enabled and
immediately disabled again in case of an error)
Yeah, that's a good idea, much less error prone than what I have now.
I'll fix that up too. Thanks again for reviewing so carefully, keep it
up! :)
Thanks,
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE
Re: drm: Branch 'vblank-rework'
+ if (temp VSYNC_PIPEA_FLAG) + atomic_add(i915_get_vblank_counter(dev, 0), +dev-vblank_count[0]); + if (temp VSYNC_PIPEB_FLAG) + atomic_add(i915_get_vblank_counter(dev, 1), +dev-vblank_count[1]); I think atomic_add is wrong here. Hm yeah it should be just atomic_set(), duh. On second thought, maybe I'll just go back to atomic_inc, otherwise I'll have to figure out the difference between the last count and the new count, then atomically add that to the current count, to deal with missed interrupts. Then again, maybe I could unify it with the counter update code that I pull out of drm_vblank_get. I'll see about that. Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework'
On Thursday, June 14, 2007 12:40:46 Michel Dänzer wrote:
On Wed, 2007-06-13 at 14:26 -0700, Jesse Barnes wrote:
On Wednesday, June 13, 2007 12:24:05 Michel Dänzer wrote:
On Tue, 2007-06-12 at 13:37 -0700, Jesse Barnes wrote:
+typedef struct drm_modeset_ctl {
+ drm_modeset_ctl_cmd_t cmd;
+ unsigned long arg;
+} drm_modeset_ctl_t;
unsigned long is bad for 32 bit userland on a 64 bit kernel.
Yeah, it should probably be u64, or a real per-subioctl command
union.
You have to be extra careful though because different alignment rules
can screw you up even if the individual members have the same size.
See e.g. the radeon setparam ioctl that recently needed to grow a 32
bit compatibility handler for this reason.
On Wed, 2007-06-13 at 14:33 -0700, Jesse Barnes wrote:
+ if (temp VSYNC_PIPEA_FLAG)
+ atomic_add(i915_get_vblank_counter(dev, 0),
+dev-vblank_count[0]);
+ if (temp VSYNC_PIPEB_FLAG)
+ atomic_add(i915_get_vblank_counter(dev, 1),
+dev-vblank_count[1]);
I think atomic_add is wrong here.
Actually, AFAICT dev-vblank_count is currently completely mixed up
between reference counting for enabling the interrupt and the
driver/API counters.
Oops, did I mix them up in the last commit? I'll double check and fix,
maybe I should rename the reference count variable to indicate that
it's used for reference counting. :)
Yeah, I think there should be a dedicated raw driver counter, and the
API counter should probably only be available via an accessor
function which adds dev-vblank_offset.
Then the driver interrupt handler could just atomic_set() the raw
counter, or maybe the drm_vblank_handler() function I suggested in
another post could just take the raw counter value as an argument.
Hm, but that might cause trouble with wraparound. I was thinking of
just calling drm_update_counter() from the interrupt handler to deal
with the update, I'll have to extract it from drm_vblank_get() first
though... at least I think that will work (though it will involve more
PIOs than just an atomic op in the interrupt handler).
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework'
Ok, I updated the branch with most of your suggestions. I think the ioctl still needs work (just made it a u64 for now), since at the very least we'll need to add the new one Keith suggested to handle CRTC reconfiguration. Please take a look and I'll test some more. I also added some comments to most of the new stuff, and once it's settled down I'll send out a note with instructions on how to update drivers (though I can try to do it myself, I'll probably get it wrong for some drivers). Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework'
On Friday, June 15, 2007 4:15:57 Michel Dänzer wrote: On Thu, 2007-06-14 at 11:37 -0700, Jesse Barnes wrote: Ok, I updated the branch with most of your suggestions. I think the ioctl still needs work (just made it a u64 for now), Yeah, that (first member 32 bit, second 64 bit) is exactly the same as radeon setparam so not 32/64 safe (64 bit compiler aligns the second member to 64 bits). since at the very least we'll need to add the new one Keith suggested to handle CRTC reconfiguration. Not sure it's really needed. E.g. the driver get_vblank_counter hook could return 0 for a disabled CRTC, so the core would handle a CRTC getting disabled as a wraparound, and then the code disabling the CRTC could call drm_handle_vblank to wake up its waiters. But the code that handles disabling the CRTC doesn't exist yet, so it would either be in the X server DDX or an ioctl to the DRM driver, right? Please take a look and I'll test some more. I also added some comments to most of the new stuff, and once it's settled down I'll send out a note with instructions on how to update drivers (though I can try to do it myself, I'll probably get it wrong for some drivers). Sounds good. I pushed some minor fixes and enhancements, the rework is proving very good at digging up longstanding bugs in this code. :) Yeah, the fixes look good, the code is actually starting to look like it might work correctly now. :) Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vblank rework for radeon
For reference, here's a patch converting radeon to the new vblank
infrastructure. The basics are pretty easy:
- add a get_vblank_counter hook to return the current vblank event
count
- add enable/disable_vblank hooks to enable/disable the vblank
interrupt
- init the vblank core (drm_vblank_init) with the number of crtcs
you have in your chip configuration
- init the max_vblank_count value to the highest value your vblank
counter register can handle
- update your interrupt handler to use the new drm_handle_vblank
routine, it'll take care of updating the master vblank count,
wakeup any clients waiting for events, and send any signals
- if needed, convert your internal routines that use vblank
events to use the new drm_vblank_get/put routines, around the
sections of code that need to have vblank interrupts enabled
(like the i915 buffer swap code)
If your device doesn't have a vblank counter register, you can simply
keep interrupts enabled (making the enable/disable hooks into no-ops,
though we could check for their existence in the core if needed), and
make the get_counter hook return the current master value and set your
max_vblank_count to ~0.
Alternately, to save power, you could make your get_counter hook use
wall time to calculate how many events have occurred since it was last
called, and make the enable/disable hooks have proper interrupt
control. This allows interrupts to be disabled for longer periods,
saving power.
Note that this particular patch is untested (testing now), and can
probably be simplified more once one of the radeon guys looks at it
(as it stands, it still removes more lines than it adds, which is
nice).
Thanks,
Jesse
diff --git a/linux-core/radeon_drv.c b/linux-core/radeon_drv.c
index 327a6a9..39c3513 100644
--- a/linux-core/radeon_drv.c
+++ b/linux-core/radeon_drv.c
@@ -60,8 +60,7 @@ static int probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
static struct drm_driver driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
- DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED |
- DRIVER_IRQ_VBL | DRIVER_IRQ_VBL2,
+ DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED,
.dev_priv_size = sizeof(drm_radeon_buf_priv_t),
.load = radeon_driver_load,
.firstopen = radeon_driver_firstopen,
@@ -70,8 +69,9 @@ static struct drm_driver driver = {
.postclose = radeon_driver_postclose,
.lastclose = radeon_driver_lastclose,
.unload = radeon_driver_unload,
- .vblank_wait = radeon_driver_vblank_wait,
- .vblank_wait2 = radeon_driver_vblank_wait2,
+ .get_vblank_counter = radeon_get_vblank_counter,
+ .enable_vblank = radeon_enable_vblank,
+ .disable_vblank = radeon_disable_vblank,
.dri_library_name = dri_library_name,
.irq_preinstall = radeon_driver_irq_preinstall,
.irq_postinstall = radeon_driver_irq_postinstall,
diff --git a/shared-core/radeon_drv.h b/shared-core/radeon_drv.h
index 283dee3..5f671df 100644
--- a/shared-core/radeon_drv.h
+++ b/shared-core/radeon_drv.h
@@ -366,13 +366,12 @@ extern int radeon_irq_emit(DRM_IOCTL_ARGS);
extern int radeon_irq_wait(DRM_IOCTL_ARGS);
extern void radeon_do_release(drm_device_t * dev);
-extern int radeon_driver_vblank_wait(drm_device_t * dev,
-unsigned int *sequence, int relative);
-extern int radeon_driver_vblank_wait2(drm_device_t * dev,
- unsigned int *sequence, int relative);
+extern u32 radeon_get_vblank_counter(drm_device_t *dev, int crtc);
+extern int radeon_enable_vblank(drm_device_t *dev, int crtc);
+extern void radeon_disable_vblank(drm_device_t *dev, int crtc);
extern irqreturn_t radeon_driver_irq_handler(DRM_IRQ_ARGS);
extern void radeon_driver_irq_preinstall(drm_device_t * dev);
-extern void radeon_driver_irq_postinstall(drm_device_t * dev);
+extern int radeon_driver_irq_postinstall(drm_device_t * dev);
extern void radeon_driver_irq_uninstall(drm_device_t * dev);
extern int radeon_vblank_crtc_get(drm_device_t *dev);
extern int radeon_vblank_crtc_set(drm_device_t *dev, int64_t value);
@@ -513,6 +512,9 @@ extern int r300_do_cp_cmdbuf(drm_device_t *dev,
DRMFILE filp,
#define RADEON_CRTC_CRNT_FRAME 0x0214
#define RADEON_CRTC2_CRNT_FRAME 0x0314
+#define RADEON_CRTC_CRNT_FRAME 0x0214
+#define RADEON_CRTC2_CRNT_FRAME 0x0314
+
#define RADEON_GEN_INT_CNTL0x0040
# define RADEON_CRTC_VBLANK_MASK (1 0)
# define RADEON_CRTC2_VBLANK_MASK (1 9)
diff --git a/shared-core/radeon_irq.c b/shared-core/radeon_irq.c
index 2534ff1..46ec035 100644
--- a/shared-core/radeon_irq.c
+++ b/shared-core/radeon_irq.c
@@ -47,6 +47,50 @@ static void radeon_irq_set_state(drm_device_t *dev,
u32 mask, int state)
RADEON_WRITE(RADEON_GEN_INT_CNTL,
Re: drm: Branch 'vblank-rework' - 2 commits
On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote: On Fri, 2007-06-22 at 11:13 -0700, Jesse Barnes wrote: New commits: diff-tree 7f2a1cf2753c0c97b1290469a15322f7549f78ae (from parents) Merge: d2d53024fb4003a6b86a3ea1ea33c76ac20bebc9 97dcd7fd25c18d5148619254229f8d94efb55b44 Author: Jesse Barnes [EMAIL PROTECTED] Date: Fri Jun 22 11:12:02 2007 -0700 Merge branch 'vblank-rework' into vblank There seems to be a little mess with the vblank branches (what about the mails about changes to 'origin/vblank-rework'?)... Yeah sorry. Had some trouble with git... I think the main vblank-rework tree should be ok aside from the silly merge messages. diff-tree 97dcd7fd25c18d5148619254229f8d94efb55b44 (from 2d24455ed8b12df6d06d135cb70f02473d11f4b0) Author: Jesse Barnes [EMAIL PROTECTED] Date: Fri Jun 22 11:06:51 2007 -0700 more vblank rework - use a timer for disabling vblank events to avoid enable/disable calls too often - make i915 work with pre-965 chips again (would like to structure this better, but this hack works on my test system) Can you elaborate on the latter? The previous code seemed to work fine on my i915 system... Any app wanting to sync to vblank on 915 hung prior to these mods, since the vblank counter never incremented. Did you see that working or just the server starting up? Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework' - 2 commits
On Monday, June 25, 2007 11:46:59 Michel Dänzer wrote:
On Mon, 2007-06-25 at 08:43 -0700, Jesse Barnes wrote:
On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
On Fri, 2007-06-22 at 11:13 -0700, Jesse Barnes wrote:
diff-tree 97dcd7fd25c18d5148619254229f8d94efb55b44 (from
2d24455ed8b12df6d06d135cb70f02473d11f4b0) Author: Jesse Barnes
[EMAIL PROTECTED]
Date: Fri Jun 22 11:06:51 2007 -0700
more vblank rework
- use a timer for disabling vblank events to avoid
enable/disable calls too often
- make i915 work with pre-965 chips again (would like to
structure this better, but this hack works on my test system)
Can you elaborate on the latter? The previous code seemed to work
fine on my i915 system...
Any app wanting to sync to vblank on 915 hung prior to these mods,
since the vblank counter never incremented. Did you see that
working [...]
Yes, I consider sync-to-vblank the main feature for vblank-rework. :)
How exactly did you test (vblank_mode=2 glxgears here), and did the
app(s) hang indefinitely or just initially for three seconds?
IIRC my test app hung indefinitely. Main loop was something like:
while (i++) {
/* Wait for vsync */
if (waitforsync)
video_sync(2, (count + 1) % 2, count);
/* Alternate colors to make tearing obvious */
if (i 1)
glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
else
glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}
If waitforsync == 0, I get obvious tearing (a kind of rain effect of
the two colors I painted), while if waitforsync != 0, the app either
hangs or alternates at the refresh rate, making kind of an orange
color. But I'll retest (though I don't see how it could have worked
for you unless 915 has these registers too in the same location).
Does vblank_mode= work with the Intel driver too? The docs I found only
mentioned radeon and mga...
Jesse
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework' - 2 commits
On Monday, June 25, 2007 12:44:16 Jesse Barnes wrote:
On Monday, June 25, 2007 11:46:59 Michel Dänzer wrote:
On Mon, 2007-06-25 at 08:43 -0700, Jesse Barnes wrote:
On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
On Fri, 2007-06-22 at 11:13 -0700, Jesse Barnes wrote:
diff-tree 97dcd7fd25c18d5148619254229f8d94efb55b44 (from
2d24455ed8b12df6d06d135cb70f02473d11f4b0) Author: Jesse
Barnes [EMAIL PROTECTED]
Date: Fri Jun 22 11:06:51 2007 -0700
more vblank rework
- use a timer for disabling vblank events to avoid
enable/disable calls too often
- make i915 work with pre-965 chips again (would like
to structure this better, but this hack works on my test
system)
Can you elaborate on the latter? The previous code seemed to
work fine on my i915 system...
Any app wanting to sync to vblank on 915 hung prior to these
mods, since the vblank counter never incremented. Did you see
that working [...]
Yes, I consider sync-to-vblank the main feature for vblank-rework.
:)
How exactly did you test (vblank_mode=2 glxgears here), and did the
app(s) hang indefinitely or just initially for three seconds?
IIRC my test app hung indefinitely. Main loop was something like:
while (i++) {
/* Wait for vsync */
if (waitforsync)
video_sync(2, (count + 1) % 2, count);
/* Alternate colors to make tearing obvious */
if (i 1)
glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
else
glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}
If waitforsync == 0, I get obvious tearing (a kind of rain effect
of the two colors I painted), while if waitforsync != 0, the app
either hangs
^
P.S. but I may not have been patient enough to wait for the 3 second
timeout... Like I said I'll retest.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'vblank-rework' - 2 commits
On Monday, June 25, 2007 12:44:16 pm Jesse Barnes wrote:
On Monday, June 25, 2007 11:46:59 Michel Dänzer wrote:
On Mon, 2007-06-25 at 08:43 -0700, Jesse Barnes wrote:
On Monday, June 25, 2007 4:00:01 am Michel Dänzer wrote:
On Fri, 2007-06-22 at 11:13 -0700, Jesse Barnes wrote:
diff-tree 97dcd7fd25c18d5148619254229f8d94efb55b44 (from
2d24455ed8b12df6d06d135cb70f02473d11f4b0) Author: Jesse Barnes
[EMAIL PROTECTED]
Date: Fri Jun 22 11:06:51 2007 -0700
more vblank rework
- use a timer for disabling vblank events to avoid
enable/disable calls too often
- make i915 work with pre-965 chips again (would like to
structure this better, but this hack works on my test system)
Can you elaborate on the latter? The previous code seemed to work
fine on my i915 system...
Any app wanting to sync to vblank on 915 hung prior to these mods,
since the vblank counter never incremented. Did you see that
working [...]
Yes, I consider sync-to-vblank the main feature for vblank-rework. :)
How exactly did you test (vblank_mode=2 glxgears here), and did the
app(s) hang indefinitely or just initially for three seconds?
IIRC my test app hung indefinitely. Main loop was something like:
while (i++) {
/* Wait for vsync */
if (waitforsync)
video_sync(2, (count + 1) % 2, count);
/* Alternate colors to make tearing obvious */
if (i 1)
glClearColor(1.0f, 1.0f, 1.0f, 1.0f);
else
glClearColor(1.0f, 0.0f, 0.0f, 0.0f);
glClear(GL_COLOR_BUFFER_BIT);
glFlush();
}
If waitforsync == 0, I get obvious tearing (a kind of rain effect of
the two colors I painted), while if waitforsync != 0, the app either
hangs or alternates at the refresh rate, making kind of an orange
color. But I'll retest (though I don't see how it could have worked
for you unless 915 has these registers too in the same location).
Does vblank_mode= work with the Intel driver too? The docs I found only
mentioned radeon and mga...
Ok, I retested without the if (!IS_965) ... code in place, which was working
for you. On my box, I get a hard hang when I run the attached test program,
or any other gl program. I checked out some old docs though, apparently 845
didn't have the frame counters, but 945 does, and I'm guessing 915 does too
since it works for you. I'll keep debugging.
Thanks,
Jesse
#include stdio.h
#include stdlib.h
#include string.h
#include unistd.h
#include GL/gl.h
#include GL/glu.h
#include GL/glx.h
#include GL/glxext.h
#include X11/X.h
#include X11/Xlib.h
#include X11/Xutil.h
void (*video_sync_get)();
void (*video_sync)();
static int GLXExtensionSupported(Display *dpy, const char *extension)
{
const char *extensionsString, *pos;
extensionsString = glXQueryExtensionsString(dpy, DefaultScreen(dpy));
pos = strstr(extensionsString, extension);
return pos != NULL (pos == extensionsString || pos[-1] == ' ')
(pos[strlen(extension)] == ' ' || pos[strlen(extension)] == '\0');
}
extern char *optarg;
extern int optind, opterr, optopt;
static char optstr[] = w:h:s;
int main(int argc, char *argv[])
{
Display *disp;
XVisualInfo *pvi;
XSetWindowAttributes swa;
int attrib[]= { GLX_RGBA,
GLX_RED_SIZE, 1,
GLX_GREEN_SIZE, 1,
GLX_BLUE_SIZE, 1,
None };
GLXContext context;
Window winGL;
unsigned int count;
int dummy;
Atom wmDelete;
int width = 500, height = 500, waitforsync = 0;
int c, i = 1;
opterr = 0;
while ((c = getopt(argc, argv, optstr)) != -1) {
switch (c) {
case 'w':
width = atoi(optarg);
break;
case 'h':
height = atoi(optarg);
break;
case 's':
waitforsync = 1;
break;
default:
fprintf(stderr, unknown option %c\n, (char)c);
break;
}
}
disp = XOpenDisplay(NULL);
if (!disp) {
fprintf(stderr, failed to open display\n);
return -1;
}
if (!glXQueryExtension(disp, dummy, dummy)) {
fprintf(stderr, glXQueryExtension failed\n);
return -1;
}
if (!GLXExtensionSupported(disp, GLX_SGI_video_sync)) {
fprintf(stderr, GLX_SGI_video_sync not supported, exiting\n);
return -1;
}
pvi = glXChooseVisual(disp, DefaultScreen(disp), attrib);
if (!pvi) {
fprintf(stderr, failed to choose visual, exiting\n);
return -1;
}
context = glXCreateContext(disp, pvi, None, GL_TRUE);
if (!context) {
fprintf(stderr, failed to create glx context\n);
return -1;
}
pvi-screen = DefaultScreen(disp);
swa.colormap = XCreateColormap(disp, RootWindow(disp, pvi-screen),
pvi-visual, AllocNone);
swa.border_pixel = 0;
swa.event_mask = ExposureMask | KeyPressMask | ButtonPressMask |
StructureNotifyMask;
winGL = XCreateWindow(disp, RootWindow(disp, pvi-screen),
0, 0,
width, height,
0, pvi-depth, InputOutput, pvi-visual
Re: drm: Branch 'vblank-rework' - 2 commits
On Wednesday, June 27, 2007 2:55:39 am Michel Dänzer wrote: Ok, I retested without the if (!IS_965) ... code in place, which was working for you. On my box, I get a hard hang when I run the attached test program, or any other gl program. I tried the clutter examples (clutter also uses the GLX_SGI_video_sync extension) and they work fine, although unsurprisingly, they exhibit tearing - the driconf option vblank_mode or the GLX_SGI_swap_control extension are more effective at avoiding tearing. If you're testing on a laptop with only the LVDS output enabled, you're probably hitting http://bugs.freedesktop.org/show_bug.cgi?id=10542 . If so, the symptoms should be the same with the drm master branch. The bug made it sound like there's some generic Mesa breakage with GLX_SGI_video_sync, so yeah I'm probably seeing that problem. I think this last change is definitely broken and should be reverted or at least amended to reflect the actual hardware capabilities and to obey the vblank interrupt enable/disable state for hardware that truly doesn't have frame counters. I agree it's something that shouldn't go upstream into the master branch. I'll try to root cause what I'm seeing (still waiting on getting some i915 docs) and fix it properly. Thanks, Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm modesetting-101 i945GM, testing and questions
On Wednesday, June 27, 2007 6:30:14 am Philippe Gaultier wrote: Anyway, I would like to remove Xorg and only use the framebuffer because - I don't need X - I would like to reduce the whole application footprint So, I did the following : 1- I tried to apply the 3 Patches from Jesse Barnes but I was not able to apply them properly (I had some missing symbols while compiling the kernel) I was not able to give a try with those patches 2- I cloned the git/drm tree using branch modesetting-101 Compilation was fine, intel_fb loads and the drm/framebuffer appears in /proc/fb but I have some troubles / remarks Yeah, (2) is the right thing to do. The patches are out of date. a. the drm/intel_fb does not load it the screen is off In fact, if I don't turn on the Plasma display, the drm/intel_fb does not appear in /proc/fb. b. if the plasma display is on, the drm/fb loads up (you can see the log at the end of this email). - I can see the framebuffer in /proc/fb - mplayer -vo fb does not complain Anyway, I got two main problems : First: the EDID is not extracted correctly (it was correct with 2.0.0 Xorg driver), I get only one modeline : ---8--- Modeline 5:640x480 6 25200 640 656 752 800 480 490 492 525 ---8--- Hm, so it just defaults to 640x480... you'd have to add some debugging code to the i2c code that fetches the EDID data to see what's going on. I may just be that the timing is off somewhere, just enough to prevent the kernel from receiving the EDID block. Second, when the mode 640x480 is set the screen does not display anything good. I only get some black screen which is sometime replace with coloured snow (I don't know how to explain it better...). If I try mplayer -vo fbdev(2), I'm only able to get a black screen So, here are my questions : - Are you still working on this drm/fb (modesetting) ? Yes, though I haven't checked anything in for a few weeks. I hope to be back on it shortly (have a few other features to get working first). - Is there a place where I can find a full procedure to make reliable tests ? - Are you interested in feedbacks ? (do you want me to make some specific tests, do you want access to my computer, ...) - ... Yes, definitely. It's great that there's interest in the tree, and we're interested in hearing about problems or different usage models for the code, but keep in mind that it's *very* bleeding edge, so when it breaks you get to keep both pieces. :) Jesse - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm modesetting-101 i945GM, testing and questions
On Tuesday, July 3, 2007 5:26:07 Philippe Gaultier wrote:
Anyway, I tried the last release of the modsetting-101 branch
yesterday night and I wasn't able to make it work :
- I compiled the code (everything was fine)
- I inserted the drm module
Jul 2 21:10:56 coreduo [drm] Initialized drm 1.1.0 20060810
- I inserted the i915 module
Jul 2 21:11:10 coreduo ACPI: PCI Interrupt :00:02.0[A] - GSI 16
(level, low) - IRQ 16
Jul 2 21:11:10 coreduo PCI: Setting latency timer of device
:00:02.0 to 64 Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable
to read EDID block. Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable
to read EDID block. Jul 2 21:11:10 coreduo i2c_adapter i2c-3: unable
to read EDID block. Jul 2 21:11:10 coreduo i915 :00:02.0: LVDS:
no EDID data Jul 2 21:11:11 coreduo i2c_adapter i2c-3: sendbytes:
error - bailout. Jul 2 21:11:11 coreduo i2c_adapter i2c-3: unable to
read EDID block. Jul 2 21:11:11 coreduo i915 :00:02.0: TMDS-1:
no EDID data Jul 2 21:11:11 coreduo allocated 640x480 fb:
0x0002, bo f611c6c0 Jul 2 21:11:11 coreduo fb0: intelfb frame
buffer device
Jul 2 21:11:11 coreduo [drm] Initialized i915 1.9.0 20070209 on
minor 0
Driver insertion seems fine except I still got the EDID trouble (I'll
try to do some debug)
When the driver is loaded, I get a blue screen on my hdmi/Plasma TV
set showing the message No signal (that was not the case with
previous release)
That could be because the monitor wasn't detected and the driver had
trouble programming a good mode.
Jul 2 21:11:24 coreduo Call Trace:
Jul 2 21:11:24 coreduo [f8d241f0] drm_cleanup+0x7a/0x19b [drm]
Jul 2 21:11:24 coreduo [f8d243e0] drm_cleanup_pci+0x16/0x24 [drm]
Jul 2 21:11:24 coreduo [c02467d7] pci_device_remove+0x16/0x36
Jul 2 21:11:24 coreduo [c02917bd]
__device_release_driver+0x64/0x8d Jul 2 21:11:24 coreduo
[c0291cca] driver_detach+0xc3/0xc9 Jul 2 21:11:24 coreduo
[c02913d8] bus_remove_driver+0x63/0x81 Jul 2 21:11:24 coreduo
[c0291cf1] driver_unregister+0x8/0x1d Jul 2 21:11:24 coreduo
[c0246931] pci_unregister_driver+0xe/0x67 Jul 2 21:11:24 coreduo
[f8d243c8] drm_exit+0xb7/0xb9 [drm] Jul 2 21:11:24 coreduo
[c01367cb] sys_delete_module+0x138/0x19a Jul 2 21:11:24 coreduo
[c01493f5] remove_vma+0x36/0x3b
Jul 2 21:11:24 coreduo [c0149e3f] do_munmap+0x16e/0x1c3
Jul 2 21:11:24 coreduo [c0102702] sysenter_past_esp+0x5f/0x85
Jul 2 21:11:24 coreduo [c035] xfrm_state_add+0x13/0x1d0
I know there are some issues with module removal unless you have a
kernel with some additional fb patches (something like the attached,
which has been superceded by a better patch by Antonio).
If I do a shutdown -r now, the whole system seems to freeze (I'm
ssh'ing it because I dont have anything displayed on the console
since I inserted the i915 module)
Here is the log (after the shutdown -r now)
Jul 2 21:12:04 coreduo shutdown[1642]: shutting down for system
reboot Jul 2 21:12:04 coreduo init: Switching to runlevel: 6
I cannot get more information... from the system logs
Yeah, after a bug like the above, the kernel might have trouble doing
much else.
So here are some questions :
1. If I compile the source code, do I need to install libdrm.so/la
before doing the insmod
No, that's just the userspace library. You'll need it if you want to
use drm* calls for modesetting in your application, but it's not
strictly needed for the kernel stuff to work.
2. Is there a way to force the driver to keep the display on TMDS-1
?
It'll try to probe all available outputs, so if everything goes well,
TMDS-1 will be setup correctly. Using the modesetting ioctls, you can
control whether TMDS-1 is cloned, an extension of another output or has
its own CRTC.
Jesse
--- linux-2.6.21-rc4/drivers/video/fbmem.c 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/drivers/video/fbmem.c 2007-04-26 18:16:52.0 -0700
@@ -1349,6 +1349,8 @@
if (!registered_fb[i])
return -EINVAL;
+ event.info = fb_info;
+ fb_notifier_call_chain(FB_EVENT_FB_UNBIND, event);
if (fb_info-pixmap.addr
(fb_info-pixmap.flags FB_PIXMAP_DEFAULT))
kfree(fb_info-pixmap.addr);
--- linux-2.6.21-rc4/include/linux/fb.h 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/include/linux/fb.h 2007-04-26 17:33:07.0 -0700
@@ -525,6 +525,8 @@
#define FB_EVENT_MODE_CHANGE_ALL 0x0B
/* A software display blank change occured */
#define FB_EVENT_CONBLANK 0x0C
+/* Unbind from the console if possible */
+#define FB_EVENT_FB_UNBIND 0x0E
struct fb_event {
struct fb_info *info;
--- linux-2.6.21-rc4/include/linux/console.h 2007-03-15 17:20:01.0 -0700
+++ linux-2.6.21-rc4-modesetting/include/linux/console.h 2007-04-26 17:56:31.0 -0700
@@ -64,6 +64,7 @@
extern const struct consw newport_con; /* SGI Newport console */
extern const struct consw prom_con; /* SPARC PROM console */
+int
Re: last git xf86-video-intel have problem with video out xv
What hardware do you have? Does Xv based video work again if you add Option tiling false to the Intel device section of your xorg.conf? I thought Wang's fix would have taken care of this problem, but it sounds like we still have a bug here... Jesse On Sunday, July 29, 2007 11:29 am Sergio Monteiro Basto wrote: Hi , I done a bisect the git xf86-video-intel and here is the results: -- drv-intel bad vo xv: HEAD is now at 04130ac... Fix i915 rendering for tiled buffer version 1 bad vo xv: 88f8b688e2316ae4a1f7485f0010ce90de54783a HEAD is now at 88f8b68... Fix some physical address handling for 4GB addresses verison 2 bad vo xv: HEAD is now at 4359df9... Fix tiling and fb compression defaults for 965 (not yet fully supported). version 5 bad vo xv: HEAD is now at ca593a5... FBC and tiling changes version 6 good: 8798ef11321ee6957919279076758d47ad956cf3 HEAD is now at 8798ef1... Merge branch 'master' into fbc version 4 good: HEAD is now at 8919b22... Re-add tiling kludge, but only for 965 version 3 good: 3c552af65d28fafec1d09484a8914b690b961349 Update documentation and bump driver version to 2.1.0. and xorg diff of last good and first bad Xorg.log - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: last git xf86-video-intel have problem with video out xv
Does Xv based video work again if you add Option tiling false to the Intel device section of your xorg.conf? no , seems that not obey to Option tiling false I try latest git and here is the xorg diff in attach Oh, you should also add Option FramebufferCompression false for that configuration... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: last git xf86-video-intel have problem with video out xv
On Monday, July 30, 2007 2:01 pm Sergio Monteiro Basto wrote: On Mon, 2007-07-30 at 13:37 -0700, Jesse Barnes wrote: Does Xv based video work again if you add Option tiling false to the Intel device section of your xorg.conf? no , seems that not obey to Option tiling false I try latest git and here is the xorg diff in attach Oh, you should also add Option FramebufferCompression false for that configuration... ok now with Option FramebufferCompression false vo(video output) xv working correctly Ok good, that means it's just a tiling bug. I'm still working to track the rest of these down. but other strange thing continue (WW) intel(0): Option Legacy3D is not used I'm not sure about this option, it may be obsolete now... (II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so This is generally a good message since it means your 3D accel module was loaded correctly. Thanks, Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM enhancements document
I finally found some time to create a new wiki page for all the modesetting/configuration related DRM enhancements we've been talking about: http://dri.freedesktop.org/wiki/DrmModesetting Please take a look and let me know what you think. I still have to go through all the feedback I received from the lkml post I made awhile back, and make sure it's captured (I think it is, albeit at a fairly high level mostly), and add more detail in the design and development sections. Jakub, hopefully you can go over it and add more detail about the userland APIs? Dave and Keith, we talked about the new device node scheme awhile back, but I only have notes on what the master node should be responsible for, did we have any new ioctls for the slave nodes? Ring buffer mapping, etc. should probably be there? Thanks, Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xf86-video-intel and tilling problem on my i915GM
On Wednesday, August 8, 2007 10:33 am Sergio Monteiro Basto wrote: On Wed, 2007-08-08 at 10:21 +0800, Zhenyu Wang wrote: Pls raise any Xorg video driver issue to [EMAIL PROTECTED], not dri-devel. xorg ML have many traffic It's good if you can pull latest fixes to test it, thanks. I just pull and test and nothing better . commit 92af2f4bbcb395cbde097776718449d99843ad67 Date: Tue Aug 7 15:18:17 2007 -0700 Sergio, to reiterate (sorry I lost the earlier messages in this thread), you're having trouble with Xv unless you disable tiling and framebuffer compression right? Thanks, Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xf86-video-intel and tilling problem on my i915GM
On Wednesday, August 8, 2007 1:11 pm Sergio Monteiro Basto wrote: On Wed, 2007-08-08 at 11:12 -0700, Jesse Barnes wrote: Sergio, to reiterate (sorry I lost the earlier messages in this thread), you're having trouble with Xv unless you disable tiling and framebuffer compression right? yes but just i810 afect my i915GM ? is that right ? I just tested again on my 915 machine. Xv seems to work well, the display is ok and the speed is right, so hopefully the latest bits will work for you. Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xf86-video-intel and tilling problem on my i915GM
On Thursday, August 9, 2007 5:33:20 am Sergio Monteiro Basto wrote: On Wed, 2007-08-08 at 16:13 -0700, Jesse Barnes wrote: I just tested again on my 915 machine. Xv seems to work well, the display is ok and the speed is right, so hopefully the latest bits will work for you. Let me check :) Since we still have XAA+Xv tiled rendering bugs, you'll need to disable tiling or use EXA as your AccelMethod... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: Hi, On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters [...] master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Graphics hardware is somewhat different in this regard due to the large userland component to the driver. It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... Well, I'm not sure it's quite as bad as you make out. The kernel must still come up with *some* initial mode, though this may typically be whatever the bootloader gave us at handoff time. Once the kernel has started init, however, a userspace program (call it 'gfxmgr') can do full output probing (i.e. monitor mode detection, output-crtc mapping, and initial mode picking) taking better advantage of the hardware. The 'gfxmgr' program should be *much* smaller than the X server, since it will be doing far less--just output probing and access control, not full mode setting (the kernel will do this), protocol management, and client scheduling. Of course, most of this has yet to be prototyped, though most of the code is already written (in some cases several times over), lying around in various projects... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Wednesday, August 22, 2007 6:47:31 am Matthias Hopf wrote: On Aug 20, 07 15:45:00 -0700, Keith Packard wrote: On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote: Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. Post-boot, for the primary card, I don't know what hardware requires BIOS calls at ths point. We certainly shouldn't encourage people to build drivers that do. No. But you already limit yourself to the primary card, a new design shouldn't be limited that way. And an astonishingly big number of people have to rely on vesa fb, because driver development for their hardware sucks big time (no docs, no hardware in time, etc.). Currently AFAIK we don't allow changing the resolution here during runtime, I'd like to see a new framework being flexible enough with this respect. Well, you'll still be able to run current code, hopefully that's flexible enough. If there's no native driver available, I don't really see how any of the new features can be reasonably provided (e.g. memory management, kernel suspend/resume support, native modesetting in the kernel). OTOH, I don't think we want to break tools like vbetool or prevent basic VESA drivers from working, it's just that users won't get anything new from them... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote: I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) I'm not sure what you mean here--the kernel does fully set the mode in this scheme, all userspace does is provide the mode info (timings, etc.). However, I do not see why some central daemon should be involved when an X server or framebuffer application or console driver or whatever wants to set up a mode on its VT; or if the system is suspended/resumed. At a minimum, there must be a program to determine which outputs have monitors attached, and what modes are available on those monitors. It's possible this could be hardcoded in simple or embedded cases, but for a dynamic system it should probably be done in userspace, since EDID overrides will be fairly common, and various platform specific quirks will probably be necessary. As I pointed out in my FOSDEM talk, the kernel does *not* strictly need to know how to determine what modes are available, or how to set up a mode with desired properties -- this can be handled by the client. However, the kernel *does* need to know enough about the hardware, to be able to safely switch between arbitrary client-supplied modes. (Or back to a default mode, if a client dies.) Yep, no disagreement here. Generally the kernel can grab the currently programmed mode at boot time, and assume its fairly safe should something catastrophic happen. Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Thursday, August 23, 2007 8:38:46 pm Tiago Vignatti wrote: I hope you guys are not forgetting who wants to start two (or more) instances of the Xorg server (for multiseat purposes or what ever). Oh definitely not. This work should make muliseat much easier. In this case, the daemon - in kernel or not - would be useful to handle the routing of the VGA code to the right legacy cards. An external daemon is also needed to control the resources provided by the vga card in the case of multiseat (which would be overlapped in a multi-head environment if the Resource Access Control (RAC) never existed on Xorg). Yeah, this subsystem might be a good place for benh's VGA arbitration kernel code... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Sunday, September 2, 2007 6:21 pm [EMAIL PROTECTED] wrote: Hi, On Fri, Aug 24, 2007 at 08:31:10AM -0700, Jesse Barnes wrote: On Thursday, August 23, 2007 6:44:49 pm [EMAIL PROTECTED] wrote: I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) I'm not sure what you mean here--the kernel does fully set the mode in this scheme, all userspace does is provide the mode info (timings, etc.). Well, some people argue that even the timings etc. could be calculated directly in the kernel -- unless I totally misunderstood their remarks. Anyways, my point was that I'm fine with both variants. Yeah, that could be done either way; in fact the kernel already has some timing formulas builtin. We could add a GTF version if needed. At a minimum, there must be a program to determine which outputs have monitors attached, and what modes are available on those monitors. It's possible this could be hardcoded in simple or embedded cases, but for a dynamic system it should probably be done in userspace, since EDID overrides will be fairly common, and various platform specific quirks will probably be necessary. I'm pretty sure detecting the outputs is something that can be done in the kernel without problems. And it *should* be done there, so the kernel can actually manage the available hardware. Yeah, I think output enumeration should be done in the kernel. But figuring out what's attached to a given output and what it supports is a little more burdensome (e.g. EDID as you mention below): not only are there a huge number of devices and combinations (think of just monitors and KVMs as an example) but myriad broken or simple devices that provide incorrect information or no information at all. As for EDID, I totally agree that this can be done in user space just fine. What I'm saying is that no central daemon is required for that. Handling this data should be totally uncritical -- it can be done by a library linked to the actual client processes. (X server, console etc.) Ideally, using a DRM backend to a generic library like libggi, which adds a lot of additional flexibility :-) Right, there's no reason most of this code can't be in a set of libraries. Nor is there any reason to *require* the use of a gfx daemon in many cases. It's just that for some of the cases we have in mind (multiple users, each with multiple clients, possibly doing direct rendering), a gfx daemon to arbitrate things may be a good approach. Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: Lossy interrupts on x86_64
Forgot to cc dri-devel, but you can follow this discussion on lkml. Jesse ---BeginMessage--- I just narrowed down a weird problem where I was losing more than 50% of my vblank interrupts to what seems to be the hires timers patch. Stock 2.6.23-rc5 works fine, but the latest (171) kernel from rawhide drops most of my interrupts unless I also have another interrupt source running (e.g. if I hold down a key or move the mouse I get the expected number of vblank interrupts, otherwise I get between 3 and 30 instead of the expected 60 per second). Any ideas? It seems like it might be bad APIC programming, but I haven't gone through those mods to look for suspects... Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ---End Message--- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Vblanks, CRTCs and GLX, oh my!
Both the generic DRM vblank-rework and Intel specific pipe/plane swapping have uncovered some vblank related problems which we discussed at XDS last week. Unfortunately, no matter what we do (including the do nothing option), some applications will break some of the time in the new world order. Basically we have a few vblank related bits of code: 1) DRM_IOCTL_WAIT_VBLANK - core DRM vblank wait ioctl 2) driver interrupt code - increments appropriate vblank counter 3) DRM_I915_VBLANK_SWAP - Intel specific scheduled swap ioctl 4) SAREA private data - used for tracking which gfx plane to swap 5) glX*VideoSyncSGI - GL interfaces for sync'ing to vblank events As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new world of dyanmically controlled outputs and CRTCs (at least for i915 and radeon): a client trying to sync against the second CRTC that doesn't pass _DRM_VBLANK_SECONDARY will only work if one CRTC is enabled, due to the way current interrupt handlers increment the respective vblank counters (i.e. they increment the correct counter if both CRTCs are generating events, but only the primary counter if only one CRTC vblank interrupt is enabled). The Intel specific DRM_I915_VBLANK_SWAP is a really nice interface, and is the only reliable way to get tear free vblank swap on a loaded system. However, what it really cares about is display planes (in the Intel sense), so it uses the _DRM_VBLANK_SECONDARY flag to indicate whether it wants to flip plane A or B. Whether or not to pass the _DRM_VBLANK_SECONDARY flag is determined by DRI code based on the SAREA private data that describes how much of a given client's window is visible on either pipe. This should work fine as of last week's mods and only the DDX and DRM code have to be aware of potential pipe-plane swapping due to hardware limitations. The vblank-rework branch of the DRM tree tries to address (1) and (2) by splitting the logic for handling CRTCs and their associated vblank interrupts into discrete paths, but this defeats the original purpose of the driver interrupt code that tries to fall back to a single counter, which is due to limitations in (5), namely that the glX*VideoSyncSGI APIs can only handle a single pipe. So, what to do? One way of making the glX*VideoSyncSGI interfaces behave more or less as expected would be to make them more like DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to determine which pipe needs to be sync'd against by passing in the display plane the client is most tied to (this would imply making the Intel specific SAREA plane info more generic), letting the DRM take care of the rest. Another option (which could be done in addition to the above) would be to add some new CRTC-aware interfaces along with ways at getting at current CRTC/display plane for a client (does GL already have this?). And no matter the outcome, we should encourage people to use interfaces like DRM_I915_VBLANK_SWAP rather than glXWaitVideoSyncSGI, otherwise they'll be highly susceptible to unpredictable scheduling hiccups. Any other thoughts? Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Tuesday, September 18, 2007 3:10 pm Torgeir Veimo wrote: On 18 Sep 2007, at 22:54, Jesse Barnes wrote: Any other thoughts? Please do add the option of retrieving a serial number of the vsync irq. It is very handy when debugging video playback that suffers from judder. This should be possible already using glXGetVideoSyncSGI. Does that not work for you? Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 19, 2007 3:52 am Michel Dänzer wrote: On Tue, 2007-09-18 at 14:54 -0700, Jesse Barnes wrote: As it stands, DRM_IOCTL_WAIT_VBLANK is downright broken in the new world of dyanmically controlled outputs and CRTCs (at least for i915 and radeon): a client trying to sync against the second CRTC that doesn't pass _DRM_VBLANK_SECONDARY will only work if one CRTC is enabled, due to the way current interrupt handlers increment the respective vblank counters (i.e. they increment the correct counter if both CRTCs are generating events, but only the primary counter if only one CRTC vblank interrupt is enabled). Yes, I made it that way to allow old Mesa drivers that don't know anything about secondary vblank to work. The trouble is that at least xf86-video-intel currently never enables vblank interrupts for pipe B only, which defeats that purpose. It's really too bad I screwed up trying to make all this backwards compatible, so I'm afraid it looks like we have to bite the bullet and make incompatible changes again to hopefully make things right finally. Well I'm not sure you screwed it up, before we had randr1.2 enabled drivers that scheme made a lot of sense. :) The vblank-rework branch of the DRM tree tries to address (1) and (2) by splitting the logic for handling CRTCs and their associated vblank interrupts into discrete paths, but this defeats the original purpose of the driver interrupt code that tries to fall back to a single counter, which is due to limitations in (5), namely that the glX*VideoSyncSGI APIs can only handle a single pipe. Right, it would be nice if we could preserve the above with vblank-rework. Or, I guess another option would be to stop caring about old Mesa drivers that don't know about secondary vblank and to just make sure things work as well as possible when vblank interrupts are enabled for both pipes. But note that 'old drivers' currently includes i965 and all Radeon drivers. Given that some of this will break no matter what, I like this option better. One way of making the glX*VideoSyncSGI interfaces behave more or less as expected would be to make them more like DRM_I915_VBLANK_SWAP internally, i.e. using SAREA values to determine which pipe needs to be sync'd against by passing in the display plane the client is most tied to (this would imply making the Intel specific SAREA plane info more generic), Not necessarily - the driver could provide its own versions of the GetMSC and WaitForMSC hooks, or we could make the generic ones use a new driver hook to determine whether to use secondary vblank. Yeah, common code would be best. So: - use the vblank-rework tree to make per-CRTC vblank counters (as you say, this breaks some setups but will fix others) - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY correctly That should make the current stack work fairly well. And when there's a real need, we can look at adding multipipe aware extensions. I can finish up the Intel bits, but the vblank-rework tree still needs mach64, mga, r128 and via updated. And the Mesa parts of those drivers need updating to handle multiple pipes. Anyone have time to tackle those? Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Friday, September 21, 2007 2:51:02 am Michel Dänzer wrote: So: - use the vblank-rework tree to make per-CRTC vblank counters (as you say, this breaks some setups but will fix others) Out of curiosity, what setups are you thinking of that this will fix on its own? Can't think of any offhand. It should fix the case where a client is waiting on pipe B when vblank interrupts on pipe A go from off to on. Currently, that'll cause the client to switch to the wrong vblank counter after pipe A's interrupts become active. In the vblank rework tree, it'll either not work in the first place (because it's using the wrong counter) or it'll work and keep working due to passing in DRM_VBLANK_SECONDARY. I think this is the correct behavior. - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY correctly One idea (with some handwaving :) would be the common code keeping around a pointer to the driver's vblank_flags variable or keeping track of the flags per drawable in some other sensible way. Yeah, if it can be kept generic I think that would be good. That should make the current stack work fairly well. And when there's a real need, we can look at adding multipipe aware extensions. My gut feeling is we'd be better off without apps or even toolkits dealing with this directly. So long as everything's keyed off the drawable, the GLX implementation should mostly be able to do the right thing on its own. One exception being cloned (or at least overlapping) setups where the CRTC modes aren't in sync. My idea for that has been a driconf option to choose which CRTC to sync to in case the drawable is visible on both CRTCs). Yeah, makes sense. If we get this right there shouldn't be much need for exposing clients to the pipe layouts directly. Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Friday, September 21, 2007 2:51 am Michel Dänzer wrote:
- add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY
correctly
One idea (with some handwaving :) would be the common code keeping
around a pointer to the driver's vblank_flags variable or keeping
track of the flags per drawable in some other sensible way.
I like the idea, here's something concrete. I put the vblank stuff into
the screen private, but I'm not sure if that's the best place
(logically the vblank counters are screen specific), are there X
compatibility issues with changing that structure?
Porting over other drivers should be trivial...
Thanks,
Jesse
diff --git a/src/mesa/drivers/dri/common/dri_util.h b/src/mesa/drivers/dri/common/dri_util.h
index 539d28d..a1b2a1d 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -468,6 +468,15 @@ struct __DRIscreenPrivateRec {
/[EMAIL PROTECTED]/
/**
+ * \name Vertical blank tracking information
+ * Used for waiting on vertical blank events.
+ */
+/[EMAIL PROTECTED]/
+unsigned int vblSeq;
+unsigned int vblFlags;
+/[EMAIL PROTECTED]/
+
+/**
* \name Device-dependent private information (stored in the SAREA).
*
* This data is accessed by the client driver only.
diff --git a/src/mesa/drivers/dri/common/vblank.c b/src/mesa/drivers/dri/common/vblank.c
index e7ed545..307c957 100644
--- a/src/mesa/drivers/dri/common/vblank.c
+++ b/src/mesa/drivers/dri/common/vblank.c
@@ -63,6 +63,8 @@ int driGetMSC32( __DRIscreenPrivate * priv, int64_t * count )
vbl.request.type = DRM_VBLANK_RELATIVE;
vbl.request.sequence = 0;
+ if ( priv-vblFlags VBLANK_FLAG_SECONDARY )
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
ret = drmWaitVBlank( priv-fd, vbl );
*count = (int64_t)vbl.reply.sequence;
@@ -124,6 +126,8 @@ int driWaitForMSC32( __DRIdrawablePrivate *priv,
vbl.request.type = dont_wait ? DRM_VBLANK_RELATIVE :
DRM_VBLANK_ABSOLUTE;
vbl.request.sequence = next;
+ if ( priv-driScreenPriv-vblFlags VBLANK_FLAG_SECONDARY )
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
if ( drmWaitVBlank( priv-driScreenPriv-fd, vbl ) != 0 ) {
/* FIXME: This doesn't seem like the right thing to return here.
@@ -257,7 +261,13 @@ void driDrawableInitVBlank( __DRIdrawablePrivate *priv, GLuint flags,
{
if ( priv-pdraw-swap_interval == (unsigned)-1 ) {
/* Get current vertical blank sequence */
- drmVBlank vbl = { .request={ .type = DRM_VBLANK_RELATIVE, .sequence = 0 } };
+ drmVBlank vbl;
+
+ vbl.request.type = DRM_VBLANK_RELATIVE;
+ if ( flags VBLANK_FLAG_SECONDARY ) {
+ vbl.request.type |= DRM_VBLANK_SECONDARY;
+ }
+ vbl.request.sequence = 0;
do_wait( vbl, vbl_seq, priv-driScreenPriv-fd );
priv-pdraw-swap_interval = (flags (VBLANK_FLAG_THROTTLE |
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c b/src/mesa/drivers/dri/i965/intel_blit.c
index f88cbb2..96689c2 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -76,7 +76,8 @@ void intelCopyBuffer( const __DRIdrawablePrivate *dPriv,
if (!rect)
{
UNLOCK_HARDWARE( intel );
- driWaitForVBlank( dPriv, intel-vbl_seq, intel-vblank_flags, missed_target );
+ driWaitForVBlank( dPriv, dPriv-driScreenPriv-vblSeq,
+ dPriv-driScreenPriv-vblFlags, missed_target );
LOCK_HARDWARE( intel );
}
diff --git a/src/mesa/drivers/dri/i965/intel_buffers.c b/src/mesa/drivers/dri/i965/intel_buffers.c
index d155c03..a2e2128 100644
--- a/src/mesa/drivers/dri/i965/intel_buffers.c
+++ b/src/mesa/drivers/dri/i965/intel_buffers.c
@@ -33,6 +33,8 @@
#include context.h
#include framebuffer.h
#include macros.h
+#include utils.h
+#include vblank.h
#include swrast/swrast.h
GLboolean intel_intersect_cliprects( drm_clip_rect_t *dst,
@@ -172,6 +174,7 @@ static void intelSetBackClipRects( struct intel_context *intel )
void intelWindowMoved( struct intel_context *intel )
{
__DRIdrawablePrivate *dPriv = intel-driDrawable;
+ __DRIscreenPrivate *sPriv = intel-driScreen;
if (!intel-ctx.DrawBuffer) {
intelSetFrontClipRects( intel );
@@ -190,6 +193,46 @@ void intelWindowMoved( struct intel_context *intel )
}
}
+ /* Get updated plane info so we sync against the right vblank counter */
+ if (intel-intelScreen-driScrnPriv-ddxMinor = 7) {
+ drmI830Sarea *sarea = intel-sarea;
+ drm_clip_rect_t drw_rect = { .x1 = dPriv-x, .x2 = dPriv-x + dPriv-w,
+ .y1 = dPriv-y, .y2 = dPriv-y + dPriv-h };
+ drm_clip_rect_t planeA_rect = { .x1 = sarea-planeA_x, .y1 = sarea-planeA_y,
+ .x2 = sarea-planeA_x + sarea-planeA_w,
+ .y2 = sarea-planeA_y + sarea-planeA_h };
+ drm_clip_rect_t planeB_rect = { .x1 = sarea-planeB_x, .y1 = sarea-planeB_y,
+ .x2 = sarea-planeB_x + sarea-planeB_w,
+
Re: Vblanks, CRTCs and GLX, oh my!
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote: On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote: On Friday, September 21, 2007 2:51 am Michel Dänzer wrote: - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY correctly One idea (with some handwaving :) would be the common code keeping around a pointer to the driver's vblank_flags variable or keeping track of the flags per drawable in some other sensible way. I like the idea, here's something concrete. I put the vblank stuff into the screen private, but I'm not sure if that's the best place (logically the vblank counters are screen specific), The drawable private would seem more appropriate, as these are drawable attributes. Ok, I'll move it over to the drawable private, assuming there's a way to get at that structure from all the paths we care about. are there X compatibility issues with changing that structure? AFAICT no - the __DRI*Private* types seem opaque outside of *_dri.so Great. I'll go ahead and push after I test again. There's no hurry on converting the other drivers; their respective maintainers can move them over when they have time. Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Monday, September 24, 2007 1:25 am Michel Dänzer wrote: On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote: On Friday, September 21, 2007 2:51 am Michel Dänzer wrote: - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY correctly One idea (with some handwaving :) would be the common code keeping around a pointer to the driver's vblank_flags variable or keeping track of the flags per drawable in some other sensible way. I like the idea, here's something concrete. I put the vblank stuff into the screen private, but I'm not sure if that's the best place (logically the vblank counters are screen specific), The drawable private would seem more appropriate, as these are drawable attributes. Here's a new version that moves the new fields over to the drawable private. I added a new drawable hook to implement the callback, and in the process discovered that all the drivers I could find either set their MSC routines to NULL or used the generic calls. So I didn't bother creating a new driver API hook for the new call; I just set it directly to the version in vblank.c in driCreateNewDrawable(). Would it make sense to rip out all the wrappers in dri_util.c, set everything directly in driCreateNewDrawable() and driUtilCreateNewScreen()? It seems that drivers that set their MSC routines to NULL will return GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g. drmWaitVBlank() failed clients would get the same result, so compatibility would be preserved... Or should I add a new driver hook for the new per-drawable getMSC function and update every driver? Thanks, Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote: On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote: On Monday, September 24, 2007 1:25 am Michel Dänzer wrote: On Fri, 2007-09-21 at 12:46 -0700, Jesse Barnes wrote: On Friday, September 21, 2007 2:51 am Michel Dänzer wrote: - add code to Mesa so GetMSC/WaitForMSC set DRM_VBLANK_SECONDARY correctly One idea (with some handwaving :) would be the common code keeping around a pointer to the driver's vblank_flags variable or keeping track of the flags per drawable in some other sensible way. I like the idea, here's something concrete. I put the vblank stuff into the screen private, but I'm not sure if that's the best place (logically the vblank counters are screen specific), The drawable private would seem more appropriate, as these are drawable attributes. Here's a new version Where's that? :) Oops. :) I'll resend when I get back to the machine with the code... that moves the new fields over to the drawable private. I added a new drawable hook to implement the callback, and in the process discovered that all the drivers I could find either set their MSC routines to NULL or used the generic calls. So I didn't bother creating a new driver API hook for the new call; I just set it directly to the version in vblank.c in driCreateNewDrawable(). Would it make sense to rip out all the wrappers in dri_util.c, set everything directly in driCreateNewDrawable() and driUtilCreateNewScreen()? What exactly do you mean by 'all the wrappers'? There are wrappers in dri_util.c for this code. The drivers then point their Driver API callbacks at them (rather than using the routines in vblank.c directly for example), so it's just an extra level of indirection that doesn't seem to buy us anything, though maybe there are out of tree drivers that take advantage of this setup... It seems that drivers that set their MSC routines to NULL will return GL_BAD_CONTEXT from calls like glXWaitVideoSyncSGI(), and if e.g. drmWaitVBlank() failed clients would get the same result, so compatibility would be preserved... Isn't the presence or absence of the driver hooks used to decide whether or not to advertise the GLX extension(s) though? The driver hooks would still be there, they'd just directly use the appropriate call instead of calling the dri_util.c wrappers. Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 26, 2007 8:11:19 am Michel Dänzer wrote: On Wed, 2007-09-26 at 07:53 -0700, Jesse Barnes wrote: On Wednesday, September 26, 2007 12:08:13 am Michel Dänzer wrote: On Tue, 2007-09-25 at 13:32 -0700, Jesse Barnes wrote: that moves the new fields over to the drawable private. I added a new drawable hook to implement the callback, and in the process discovered that all the drivers I could find either set their MSC routines to NULL or used the generic calls. So I didn't bother creating a new driver API hook for the new call; I just set it directly to the version in vblank.c in driCreateNewDrawable(). Would it make sense to rip out all the wrappers in dri_util.c, set everything directly in driCreateNewDrawable() and driUtilCreateNewScreen()? What exactly do you mean by 'all the wrappers'? There are wrappers in dri_util.c for this code. The drivers then point their Driver API callbacks at them (rather than using the routines in vblank.c directly for example), so it's just an extra level of indirection that doesn't seem to buy us anything, [...] AFAICT all drivers point the DriverAPI callbacks to the vblank.c functions, so I'm still not sure what you're getting at, but maybe your patch will clarify. Err yeah I was describing it backwards. The __DRIscreen hooks for the MSC stuff all point to dri_util.c wrapper functions that end up calling the driver hooks. However, drivers always set their hooks to either NULL or to the routines in vblank.c. So we could just set the __DRIscreen hooks to point to vblank.c directly since none of the drivers appear to have custom hooks for these calls... Jesse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Vblanks, CRTCs and GLX, oh my!
On Wednesday, September 26, 2007 9:39 am Michel Dänzer wrote:
Err yeah I was describing it backwards. The __DRIscreen hooks for
the MSC stuff all point to dri_util.c wrapper functions that end up
calling the driver hooks. However, drivers always set their hooks
to either NULL or to the routines in vblank.c. So we could just
set the __DRIscreen hooks to point to vblank.c directly since none
of the drivers appear to have custom hooks for these calls...
I see, thanks for clarifying. Ian Romanick can probably tell us more
about this.
And for reference, here's the updated patch.
Jesse
diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
index 8d24e31..bd898d2 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -512,6 +512,17 @@ struct __DRIdrawableRec {
*/
void (*copySubBuffer)(__DRInativeDisplay *dpy, void *drawablePrivate,
int x, int y, int w, int h);
+
+/**
+ * Like the screen version of getMSC, but also takes a drawable so that
+ * the appropriate pipe's counter can be retrieved.
+ *
+ * Get the number of vertical refreshes since some point in time before
+ * this function was first called (i.e., system start up).
+ *
+ * \since Internal API version 20070925.
+ */
+int (*getMSC)(__DRInativeDisplay *dpy, void *drawablePrivate, int64_t *msc);
};
#endif
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index f52b71f..134afac 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -1889,14 +1889,32 @@ static int __glXGetVideoSyncSGI(unsigned int *count)
if ( (gc != NULL) gc-isDirect ) {
__GLXscreenConfigs * const psc = GetGLXScreenConfigs( gc-currentDpy,
gc-screen );
- if ( __glXExtensionBitIsEnabled( psc, SGI_video_sync_bit )
- psc-driScreen.private psc-driScreen.getMSC) {
- int ret;
- int64_t temp;
-
- ret = psc-driScreen.getMSC( psc-driScreen.private, temp );
- *count = (unsigned) temp;
- return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ if ( __glXExtensionBitIsEnabled( psc, SGI_video_sync_bit )
+ psc-driScreen.private ) {
+ __DRIdrawable * const pdraw =
+ (*psc-driScreen.getDrawable)(gc-currentDpy,
+ gc-currentDrawable,
+ psc-driScreen.private);
+ /*
+ * Try to use the drawable's getMSC first so we get the right
+ * counter
+ */
+ if ( (pdraw != NULL) (pdraw-getMSC != NULL) ) {
+ int ret;
+ int64_t temp;
+
+ ret = (*pdraw-getMSC)( psc-driScreen.private, pdraw-private,
+ temp);
+ *count = (unsigned) temp;
+ return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ } else if ( psc-driScreen.getMSC ) { /* fallback to screen */
+ int ret;
+ int64_t temp;
+
+ ret = psc-driScreen.getMSC( psc-driScreen.private, temp );
+ *count = (unsigned) temp;
+ return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ }
}
}
#else
diff --git a/src/mesa/drivers/dri/common/dri_util.c b/src/mesa/drivers/dri/common/dri_util.c
index c30e66f..ae2db0a 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++ b/src/mesa/drivers/dri/common/dri_util.c
@@ -31,6 +31,7 @@
#include dri_util.h
#include drm_sarea.h
+#include vblank.h
#ifndef GLX_OML_sync_control
typedef GLboolean ( * PFNGLXGETMSCRATEOMLPROC) (__DRInativeDisplay *dpy, __DRIid drawable, int32_t *numerator, int32_t *denominator);
@@ -639,6 +640,8 @@ static void *driCreateNewDrawable(__DRInativeDisplay *dpy,
pdp-numBackClipRects = 0;
pdp-pClipRects = NULL;
pdp-pBackClipRects = NULL;
+pdp-vblSeq = 0;
+pdp-vblFlags = 0;
pdp-display = dpy;
pdp-screen = modes-screen;
@@ -663,6 +666,7 @@ static void *driCreateNewDrawable(__DRInativeDisplay *dpy,
pdraw-swapBuffersMSC = driSwapBuffersMSC;
pdraw-frameTracking = NULL;
pdraw-queryFrameTracking = driQueryFrameTracking;
+pdraw-getMSC = driDrawableGetMSC;
if (driCompareGLXAPIVersion (20060314) = 0)
pdraw-copySubBuffer = driCopySubBuffer;
diff --git a/src/mesa/drivers/dri/common/dri_util.h b/src/mesa/drivers/dri/common/dri_util.h
index 539d28d..cb3c5d3 100644
--- a/src/mesa/drivers/dri/common/dri_util.h
+++ b/src/mesa/drivers/dri/common/dri_util.h
@@ -308,6 +308,15 @@ struct __DRIdrawablePrivateRec {
/[EMAIL PROTECTED]/
/**
+ * \name Vertical blank tracking information
+ * Used for waiting on vertical blank events.
+ */
+/[EMAIL PROTECTED]/
+unsigned int vblSeq;
+unsigned int vblFlags;
+/[EMAIL PROTECTED]/
+
+/**
* Pointer to context to which this drawable is currently bound.
*/
__DRIcontextPrivate *driContextPriv;
diff --git a/src/mesa/drivers/dri/common/vblank.c b/src/mesa/drivers/dri/common/vblank.c
index e7ed545..6ab72b3 100644
--- a/src/mesa/drivers/dri/common/vblank.c
+++ b/src/mesa/drivers/dri/common/vblank.c
@@ -50,19 +50,24 @@
* currently always returns a \c sequence of
[PATCH] enhanced core vblank support
Per the discussion in the other vblank thread, this patch does several
things:
- adds a new getMSC hook to __DRIdrawableRec
- updates glXGetVideoSyncSGI to use the new hook if present
- adds new vblank fields to __DRIdrawablePrivateRec
- adds a new driDrawableGetMSC32 vblank.c routine
this new function takes a drawable private so it can set pipe
flags for example when it calls into the DRM
- adds a wrapper for the new vblank.c routine in dri_util.c
for symmetry
- updates driCreateNewDrawable to init the new vblank fields
and set the callback for the new per-drawable getMSC routine
- adds a __DriverAPI hook for GetDrawableMSC
- updates the drivers to use driDrawableGetMSC32 in their
DriverAPI initialization
I'm not sure about the compatibility implications of these changes, it
seems like touching __DRIdrawableRec and __DriverAPIRec may affect
binary compatibility with existing drivers, is there anything else?
If compatibility isn't a concern, I can go ahead and remove the
per-screen getMSC altogether, along with its associated __DriverAPI
function pointers and remove some code.
Also, I decided against cleaning up the screen and drawable callback
wrappers in dri_util.c. It seems they'll be needed if we ever add full
OML extension support. I made the new stuff fit in with that scheme.
Any thoughts?
Thanks,
Jesse
include/GL/internal/dri_interface.h| 11 ++
src/glx/x11/glxcmds.c | 34 +++-
src/mesa/drivers/dri/common/dri_util.c | 12 +++
src/mesa/drivers/dri/common/dri_util.h | 17 ++
src/mesa/drivers/dri/common/vblank.c | 39 +--
src/mesa/drivers/dri/common/vblank.h |3 +
src/mesa/drivers/dri/ffb/ffb_xmesa.c |1
src/mesa/drivers/dri/i810/i810screen.c |1
src/mesa/drivers/dri/i915/intel_screen.c |1
src/mesa/drivers/dri/i915tex/intel_screen.c|1
src/mesa/drivers/dri/i965/intel_blit.c |3 +
src/mesa/drivers/dri/i965/intel_buffers.c | 41 +
src/mesa/drivers/dri/i965/intel_context.c | 14
src/mesa/drivers/dri/i965/intel_context.h |7
src/mesa/drivers/dri/i965/intel_screen.c |1
src/mesa/drivers/dri/i965/server/i830_common.h |9 +
src/mesa/drivers/dri/mach64/mach64_screen.c|1
src/mesa/drivers/dri/mga/mga_xmesa.c |1
src/mesa/drivers/dri/nouveau/nouveau_screen.c |2 -
src/mesa/drivers/dri/r128/r128_screen.c|1
src/mesa/drivers/dri/radeon/radeon_screen.c|2 +
src/mesa/drivers/dri/sis/sis_screen.c |1
src/mesa/drivers/dri/tdfx/tdfx_screen.c|1
src/mesa/drivers/dri/unichrome/via_screen.c|1
24 files changed, 180 insertions(+), 25 deletions(-)
diff --git a/include/GL/internal/dri_interface.h b/include/GL/internal/dri_interface.h
index 8d24e31..bd898d2 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -512,6 +512,17 @@ struct __DRIdrawableRec {
*/
void (*copySubBuffer)(__DRInativeDisplay *dpy, void *drawablePrivate,
int x, int y, int w, int h);
+
+/**
+ * Like the screen version of getMSC, but also takes a drawable so that
+ * the appropriate pipe's counter can be retrieved.
+ *
+ * Get the number of vertical refreshes since some point in time before
+ * this function was first called (i.e., system start up).
+ *
+ * \since Internal API version 20070925.
+ */
+int (*getMSC)(__DRInativeDisplay *dpy, void *drawablePrivate, int64_t *msc);
};
#endif
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index f52b71f..134afac 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -1889,14 +1889,32 @@ static int __glXGetVideoSyncSGI(unsigned int *count)
if ( (gc != NULL) gc-isDirect ) {
__GLXscreenConfigs * const psc = GetGLXScreenConfigs( gc-currentDpy,
gc-screen );
- if ( __glXExtensionBitIsEnabled( psc, SGI_video_sync_bit )
- psc-driScreen.private psc-driScreen.getMSC) {
- int ret;
- int64_t temp;
-
- ret = psc-driScreen.getMSC( psc-driScreen.private, temp );
- *count = (unsigned) temp;
- return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ if ( __glXExtensionBitIsEnabled( psc, SGI_video_sync_bit )
+ psc-driScreen.private ) {
+ __DRIdrawable * const pdraw =
+ (*psc-driScreen.getDrawable)(gc-currentDpy,
+ gc-currentDrawable,
+ psc-driScreen.private);
+ /*
+ * Try to use the drawable's getMSC first so we get the right
+ * counter
+ */
+ if ( (pdraw != NULL) (pdraw-getMSC != NULL) ) {
+ int ret;
+ int64_t temp;
+
+ ret = (*pdraw-getMSC)( psc-driScreen.private, pdraw-private,
+ temp);
+ *count = (unsigned) temp;
+ return (ret == 0) ? 0 : GLX_BAD_CONTEXT;
+ } else if (
