Adding new pci vendor id
Hi I am using a linux kernel with the following info Linux 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686 GNU/Linux I would like to know what is the procedure to add new pci vendor id and device id to the list pciids.h which i found at this location - /usr/src/kernels/2.6.29.6-217.2.3.fc11.i686.PAE/include/drm/drm_pciids.h Thanks and regards, Tauseef Junior design engineer, Gennum This communication contains confidential information intended only for the addressee(s). If you have received this communication in error, please notify us immediately and delete this communication from your mail box. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
Hi,
some minor comments below.
On Tue, 11 Aug 2009 15:52:06 +1000
Dave Airlie airl...@gmail.com wrote:
From: Tiago Vignatti tiago.vigna...@nokia.com
Background:
Graphic devices are accessed through ranges in I/O or memory space. While most
modern devices allow relocation of such ranges, some Legacy VGA devices
implemented on PCI will typically have the same hard-decoded addresses as
they did on ISA. For more details see PCI Bus Binding to IEEE Std 1275-1994
Standard for Boot (Initialization Configuration) Firmware Revision 2.1
Section 7, Legacy Devices.
The Resource Access Control (RAC) module inside the X server currently does
the task of arbitration when more than one legacy device co-exists on the same
machine. But the problem happens when these devices are trying to be accessed
by different userspace clients (e.g. two server in parallel). Their address
assignments conflict. Therefore an arbitration scheme _outside_ of the X
server is needed to control the sharing of these resources. This document
introduces the operation of the VGA arbiter implemented for Linux kernel.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/Makefile |2 +-
drivers/gpu/vga/Kconfig | 10 +
drivers/gpu/vga/Makefile |1 +
drivers/gpu/vga/vgaarb.c | 1206
++
drivers/pci/pci.c| 44 ++
drivers/video/Kconfig|2 +
include/linux/pci.h |2 +
include/linux/vgaarb.h | 195
8 files changed, 1461 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/vga/Kconfig
create mode 100644 drivers/gpu/vga/Makefile
create mode 100644 drivers/gpu/vga/vgaarb.c
create mode 100644 include/linux/vgaarb.h
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index de566cf..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y+= drm/
+obj-y+= drm/ vga/
diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
new file mode 100644
index 000..790e675
--- /dev/null
+++ b/drivers/gpu/vga/Kconfig
@@ -0,0 +1,10 @@
+config VGA_ARB
+ bool VGA Arbitration if EMBEDDED
+ default y
+ depends on PCI
+ help
+ Some legacy VGA devices implemented on PCI typically have the same
+ hard-decoded addresses as they did on ISA. When multiple PCI devices
+ are accessed at same time they need some kind of coordination. Please
+ see Documentation/vgaarbiter.txt for more details. Select this to
+ enable VGA arbiter.
The file Documentation/vgaarbiter.txt does not exist.
diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile
new file mode 100644
index 000..7cc8c1e
--- /dev/null
+++ b/drivers/gpu/vga/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VGA_ARB) += vgaarb.o
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
new file mode 100644
index 000..199138f
--- /dev/null
+++ b/drivers/gpu/vga/vgaarb.c
@@ -0,0 +1,1206 @@
+/*
+ * vgaarb.c
+ *
+ * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org
+ * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com
+ * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org
+ *
+ * Implements the VGA arbitration. For details refer to
+ * Documentation/vgaarbiter.txt
Another reference to vgaarbiter.txt.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/list.h
+#include linux/sched.h
+#include linux/wait.h
+#include linux/spinlock.h
+#include linux/poll.h
+#include linux/miscdevice.h
+
+#include linux/uaccess.h
+
+#include linux/vgaarb.h
+
+static void vga_arbiter_notify_clients(void);
+/*
+ * We keep a list of all vga devices in the system to speed
+ * up the various operations of the arbiter
+ */
+struct vga_device {
+ struct list_head list;
+ struct pci_dev *pdev;
+ unsigned int decodes; /* what does it decodes */
+ unsigned int owns; /* what does it owns */
+ unsigned int locks; /* what does it locks */
+ unsigned int io_lock_cnt; /* legacy IO lock count */
+ unsigned int mem_lock_cnt; /* legacy MEM lock count */
+ unsigned int io_norm_cnt; /* normal IO count */
+ unsigned int mem_norm_cnt; /* normal MEM count */
+
+ /* allow IRQ enable/disable hook */
+ void *cookie;
+ void (*irq_set_state)(void *cookie, bool enable);
+ unsigned int (*set_vga_decode)(void *cookie, bool decode);
+};
+
+static LIST_HEAD(vga_list);
+static int vga_count, vga_decode_count;
+static bool vga_arbiter_used;
+static DEFINE_SPINLOCK(vga_lock);
+static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue);
+
+
+static const char *vga_iostate_to_str(unsigned int iostate)
+{
+ /* Ignore VGA_RSRC_IO and VGA_RSRC_MEM
Re: [PATCH 2/3] ttm: ttm_fbdev_mmap() fixes.
Michel Dänzer wrote:
On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote:
Michel Dänzer wrote:
On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote:
Aargh. Wait. I remember now.
The fbcon bo is exported through the fbdev address space at offset 0.
The vm_node is for the drm device address space only. So it is perfectly
legal and actually correct for it not to have a vm_node, unless it's
going to be accessible from the drm device. Does it need to for KMS?
I don't think so.
I'm a bit unsure whether it's OK to export a bo through two different
address spaces. In particular, unmap_mapping_range() on the drm device
will not kill the fbdev user-space mappings.
Hmm, so that would mean that if an fbdev mapping is created while the BO
is in VRAM, it would still access VRAM after the BO has been evicted? Is
there a solution for this?
Yes, You need to call unmap_mapping_range() on the fbdev address space.
See how that is done in ttm_bo_unmap_virtual() for the drm address
space. Actually, I think you need to set up a bo_driver hook in
ttm_bo_unmap_virtual() to do this every time the bo is moved or swapped out.
The attached patches should hopefully address all the feedback I've
received here and on IRC. Let me know what you think.
Michel,
The TTM parts look good to me.
At some point we should fix up the ttm_bo_fbdev_io performance by
avoiding vmap() / ioremap() and instead use atomic maps but that's for
the future.
I'm not 100% sure, but the Radeon part still looks a little problematic.
First, I think it's illegal to call radeonfb_remap() from the fbdev
accelerated hooks, since these may be called from within atomic context
and there's no way to detect this since in_atomic() only works if
CONFIG_PREEMPT is set. IIRC Jakob hit this with psbfb.
Also when you test for mem_reg_is_pci() to determine that it's ok to
kmap, I'd instead test for TTM_BO_FLAG_NO_EVICT to make sure the object
is pinned, regardless of its whereabouts.
Also, the kernel address must be invalidated just before unpin to
avoid racing.
So the sequence must be
pin_fbcon_fb()
kmap()
invalidate_kernel_address()
kunmap()
unpin_fbconfb().
So the problem is really: How do we avoid the
invalidate_kernel_address() racing with an fbcon access?
To be completely sure we would want a spinlock protecting the address
pointer, but we don't have one, and the error is fatal if this happens.
There is a very nasty and hackish way to fix this without having a
spinlock to protect the address, and that is to rewrite the kernel page
tables of the vmap() to point to a dummy page when the bo is unpinned.
I'm not sure all needed functions are exported, though.
/Thomas
From bc1e3c5d116f194ac972f6f69b79b69bc64d1789 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel=20D=C3=A4nzer?= daen...@vmware.com
Date: Mon, 10 Aug 2009 23:41:47 +0200
Subject: [PATCH 1/2] ttm: fbdev fixes.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
* Fix ttm_bo_fbdev_io() and export it.
* Add a BO driver hook for unmapping virtual memory ranges backed by a BO.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c|4
drivers/gpu/drm/ttm/ttm_bo_vm.c | 29 -
include/drm/ttm/ttm_bo_api.h| 15 +++
include/drm/ttm/ttm_bo_driver.h | 15 +++
4 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b98a02d..2c363e1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1443,6 +1443,10 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
loff_t offset = (loff_t) bo-addr_space_offset;
loff_t holelen = ((loff_t) bo-mem.num_pages) PAGE_SHIFT;
+ if (bdev-driver-unmap_mapping_range
+ bdev-driver-unmap_mapping_range(bo))
+ return;
+
if (!bdev-dev_mapping)
return;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 27b146c..bdd1bed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -129,10 +129,15 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
is_iomem = (bus_size != 0);
- page_offset = ((address - vma-vm_start) PAGE_SHIFT) +
- bo-vm_node-start - vma-vm_pgoff;
- page_last = ((vma-vm_end - vma-vm_start) PAGE_SHIFT) +
- bo-vm_node-start - vma-vm_pgoff;
+ page_offset = ((address - vma-vm_start) PAGE_SHIFT) -
+ vma-vm_pgoff;
+ page_last = ((vma-vm_end - vma-vm_start) PAGE_SHIFT) -
+ vma-vm_pgoff;
+
+ if (likely(bo-vm_node)) {
+ page_offset += bo-vm_node-start;
+
Re: [PATCH 2/3] ttm: ttm_fbdev_mmap() fixes.
On Tue, 2009-08-11 at 10:48 +0200, Thomas Hellström wrote: Michel Dänzer wrote: On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote: Michel Dänzer wrote: On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote: Aargh. Wait. I remember now. The fbcon bo is exported through the fbdev address space at offset 0. The vm_node is for the drm device address space only. So it is perfectly legal and actually correct for it not to have a vm_node, unless it's going to be accessible from the drm device. Does it need to for KMS? I don't think so. I'm a bit unsure whether it's OK to export a bo through two different address spaces. In particular, unmap_mapping_range() on the drm device will not kill the fbdev user-space mappings. Hmm, so that would mean that if an fbdev mapping is created while the BO is in VRAM, it would still access VRAM after the BO has been evicted? Is there a solution for this? Yes, You need to call unmap_mapping_range() on the fbdev address space. See how that is done in ttm_bo_unmap_virtual() for the drm address space. Actually, I think you need to set up a bo_driver hook in ttm_bo_unmap_virtual() to do this every time the bo is moved or swapped out. The attached patches should hopefully address all the feedback I've received here and on IRC. Let me know what you think. Michel, The TTM parts look good to me. The only thing I'm not quite sure about is the ttm_bo_vm_fault changes; I think they make the assumption that the BO backs the beginning of the address space if bo-vm_node is NULL? If that is a problem, how could it be solved? At some point we should fix up the ttm_bo_fbdev_io performance by avoiding vmap() / ioremap() and instead use atomic maps but that's for the future. Yeah, I don't think this is important, most certainly not for now. I'm not 100% sure, but the Radeon part still looks a little problematic. First, I think it's illegal to call radeonfb_remap() from the fbdev accelerated hooks, since these may be called from within atomic context and there's no way to detect this since in_atomic() only works if CONFIG_PREEMPT is set. IIRC Jakob hit this with psbfb. Also when you test for mem_reg_is_pci() to determine that it's ok to kmap, I'd instead test for TTM_BO_FLAG_NO_EVICT to make sure the object is pinned, regardless of its whereabouts. Note that the primary purpose of the test isn't to check that it's okay to kmap but that the resulting screen_base will be suitable for cfb_* (i.e. essentially that it uses ioremap). Otherwise it just leaves screen_base invalid. So the problem is really: How do we avoid the invalidate_kernel_address() racing with an fbcon access? To be completely sure we would want a spinlock protecting the address pointer, but we don't have one, and the error is fatal if this happens. Hmm. Maybe the console semaphore could be used for this? If we can't acquire it, maybe we could just fail whatever we would need it for... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] ttm: ttm_fbdev_mmap() fixes.
Michel Dänzer wrote: On Tue, 2009-08-11 at 10:48 +0200, Thomas Hellström wrote: Michel Dänzer wrote: On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote: Michel Dänzer wrote: On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote: Aargh. Wait. I remember now. The fbcon bo is exported through the fbdev address space at offset 0. The vm_node is for the drm device address space only. So it is perfectly legal and actually correct for it not to have a vm_node, unless it's going to be accessible from the drm device. Does it need to for KMS? I don't think so. I'm a bit unsure whether it's OK to export a bo through two different address spaces. In particular, unmap_mapping_range() on the drm device will not kill the fbdev user-space mappings. Hmm, so that would mean that if an fbdev mapping is created while the BO is in VRAM, it would still access VRAM after the BO has been evicted? Is there a solution for this? Yes, You need to call unmap_mapping_range() on the fbdev address space. See how that is done in ttm_bo_unmap_virtual() for the drm address space. Actually, I think you need to set up a bo_driver hook in ttm_bo_unmap_virtual() to do this every time the bo is moved or swapped out. The attached patches should hopefully address all the feedback I've received here and on IRC. Let me know what you think. Michel, The TTM parts look good to me. The only thing I'm not quite sure about is the ttm_bo_vm_fault changes; I think they make the assumption that the BO backs the beginning of the address space if bo-vm_node is NULL? If that is a problem, how could it be solved? I think this is OK for now. If we want to export bo maps through even more devices, we can probably deal with that when that happens. I'm not 100% sure, but the Radeon part still looks a little problematic. First, I think it's illegal to call radeonfb_remap() from the fbdev accelerated hooks, since these may be called from within atomic context and there's no way to detect this since in_atomic() only works if CONFIG_PREEMPT is set. IIRC Jakob hit this with psbfb. Also when you test for mem_reg_is_pci() to determine that it's ok to kmap, I'd instead test for TTM_BO_FLAG_NO_EVICT to make sure the object is pinned, regardless of its whereabouts. Note that the primary purpose of the test isn't to check that it's okay to kmap but that the resulting screen_base will be suitable for cfb_* (i.e. essentially that it uses ioremap). Otherwise it just leaves screen_base invalid. Hmm. Ok. I just want to make sure that the screen_base will *never* be valid when the bo is unpinned or unreserved. That would potentially cause severe memory corruption. So the problem is really: How do we avoid the invalidate_kernel_address() racing with an fbcon access? To be completely sure we would want a spinlock protecting the address pointer, but we don't have one, and the error is fatal if this happens. Hmm. Maybe the console semaphore could be used for this? If we can't acquire it, maybe we could just fail whatever we would need it for... We've tried various uses of that one as well for psb, but we didn't really succeed, but I admit I don't have a clear understanding of exactly what it is used for. /Thomas -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm sysfs questions
Hi! I'm wondering why we are using a struct device as a sysfs representation for connectors instead of a struct kobject? In particular, what stops the drm_sysfs_[suspend|resume] functions to get called for the connectors, having them cast to a struct drm_minor and sending the cpu to the bushes? /Thomas -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23250] New: [Regression] OpenGL game is very slow with DRI2, was fast with DRI1
http://bugs.freedesktop.org/show_bug.cgi?id=23250 Summary: [Regression] OpenGL game is very slow with DRI2, was fast with DRI1 Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: achim.fr...@googlemail.com The OpenGL game Clonk Rage gets very slow if I throw flintstones at some trees. With DRI1 everything is very fast but with DRI2 it gets really slow. http://www.clonk.de/cr.php?lng=en I have tested this with intel g45 (X4500HD) and gm945 the show both the same behaviour. This problem exists since the introduction of DRI2. I have tested it against latest kernel and xorg-edgers ppa. I have created a little demo video where you can see how big the differers between DRI1 and DRI2 is. http://rapidshare.com/files/266164313/clonk.ogv Regards Achim -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding new pci vendor id
Hi, On Tue, 2009-08-11 at 03:24 -0400, Tauseef Hussain wrote: Hi I am using a linux kernel with the following info Linux 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686 GNU/Linux I would like to know what is the procedure to add new pci vendor id and device id to the list pciids.h which i found at this location - /usr/src/kernels/2.6.29.6-217.2.3.fc11.i686.PAE/include/drm/drm_pciids.h My guess is that you just submit a patch on that mailing-list. Xav -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/6] kernel modsetting support for intel overlay
Hi all, This series implements support for the intel overlay hw with kms. Caveats/Remarks: - the overlay image is flickering but stabilizes after a few secs of showing the same frame. I've researched intel ddx history/bugs and there was a similar issue in the original userspace modesetting driver, but I haven't found the solution. Hints/ideas highly appreciated. - untested on anything else than a 855GM - this is the only hw I have. Especially panel fitting one-line-mode is completely untested. Testing this needs an LVDS with vertical resolution less than native but larger than 1024. - patches 1, 4, 5 change drm-generic code. - the ioctl interface is intel-only. Anyone (radeon devs?) working on another overlay implementation/interested in sharing code? Yours, Daniel PS: I'll post the ddx part shortly to intel-gfx. Daniel Vetter (6): [drm]: make drm_mode_object_find typesafe [drm/i915] remove open-coded drm_mode_object_find [drm/i915]: modeset: always set intel_crtc-dpms_mode [drm/i915]: require_pipe_a helper functions [drm/i915]: add i915_lp_ring_sync helper [drm/i915] implement drmmode overlay support drivers/gpu/drm/drm_crtc.c |3 +- drivers/gpu/drm/drm_crtc_helper.c|3 +- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_dma.c |7 + drivers/gpu/drm/i915/i915_drv.h |5 + drivers/gpu/drm/i915/i915_gem.c | 51 ++- drivers/gpu/drm/i915/i915_reg.h |5 + drivers/gpu/drm/i915/intel_display.c | 133 +++- drivers/gpu/drm/i915/intel_drv.h | 35 + drivers/gpu/drm/i915/intel_overlay.c | 1289 ++ include/drm/drm_crtc.h |3 +- include/drm/drm_crtc_helper.h|2 + include/drm/drm_os_linux.h |2 +- include/drm/i915_drm.h | 71 ++ 14 files changed, 1579 insertions(+), 31 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay.c -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/6] [drm/i915]: require_pipe_a helper functions
These will be used to ensure that the clock of pipe a is running
when the overlay is switched on. Programming logic more or less
directly ported over from userspace.
Also export the already existing helper function drm_encoder_crtc_ok.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc_helper.c|3 +-
drivers/gpu/drm/i915/intel_display.c | 83 ++
drivers/gpu/drm/i915/intel_drv.h |5 ++
include/drm/drm_crtc_helper.h|2 +
4 files changed, 92 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 6aaa2cb..2d837a5 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -511,7 +511,7 @@ static void drm_setup_crtcs(struct drm_device *dev)
*
* Return false if @encoder can't be driven by @crtc, true otherwise.
*/
-static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
+bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
struct drm_crtc *crtc)
{
struct drm_device *dev;
@@ -532,6 +532,7 @@ static bool drm_encoder_crtc_ok(struct drm_encoder *encoder,
return true;
return false;
}
+EXPORT_SYMBOL(drm_encoder_crtc_ok);
/*
* Check the CRTC we're going to map each output to vs. its current
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 818c703..cb709b8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2936,6 +2936,89 @@ void intel_release_load_detect_pipe(struct intel_output
*intel_output, int dpms_
}
}
+/** Ensure that pipe A is enabled. Returns the crtc that runs pipe a or NULL
+ * if pipe a is already enabled */
+struct drm_crtc *intel_require_pipe_a_start(struct drm_device *dev,
+ int *dpms_mode)
+{
+ struct drm_crtc *crtc;
+ struct intel_crtc *intel_crtc;
+ struct drm_connector *connector;
+ struct drm_crtc_helper_funcs *crtc_funcs;
+ struct intel_output *intel_output;
+
+ crtc = intel_get_crtc_from_pipe(dev, 0);
+ intel_crtc = to_intel_crtc(crtc);
+ BUG_ON(intel_crtc-pipe != 0);
+
+ if (crtc-enabled intel_crtc-dpms_mode == DRM_MODE_DPMS_ON)
+ return NULL;
+
+ DRM_DEBUG(i915: require PIPEA, switching on crtc ...\n);
+
+ *dpms_mode = intel_crtc-dpms_mode;
+
+ if (crtc-enabled intel_crtc-dpms_mode != DRM_MODE_DPMS_ON) {
+ /* just switch it on */
+ crtc_funcs = crtc-helper_private;
+ crtc_funcs-dpms(crtc, DRM_MODE_DPMS_ON);
+
+ return crtc;
+ }
+
+ if (!drm_helper_crtc_in_use(crtc)) {
+ /* look for an encoder/connector */
+ list_for_each_entry(connector,
+ dev-mode_config.connector_list, head) {
+ intel_output = to_intel_output(connector);
+
+ if (intel_output-enc.crtc)
+ /* don't steal connectors */
+ continue;
+
+ if (!drm_encoder_crtc_ok(intel_output-enc, crtc))
+ continue;
+
+ intel_output-enc.crtc = crtc;
+ break;
+ }
+ }
+
+ drm_crtc_helper_set_mode(crtc, load_detect_mode, 0, 0, crtc-fb);
+ BUG_ON(crtc-enabled);
+
+ return crtc;
+}
+
+void intel_require_pipe_a_end(struct drm_device *dev,
+ struct drm_crtc *crtc,
+ int dpms_mode)
+{
+ struct drm_encoder_helper_funcs *encoder_funcs;
+ struct drm_encoder *encoder;
+ struct drm_crtc_helper_funcs *crtc_funcs;
+
+ if (!crtc)
+ return;
+
+ crtc_funcs = crtc-helper_private;
+
+ DRM_DEBUG(i915: require PIPEA, switching off crtc ...\n);
+
+ /* Switch crtc and output back off if necessary */
+ if (crtc-enabled dpms_mode != DRM_MODE_DPMS_ON) {
+ list_for_each_entry(encoder,
+ dev-mode_config.encoder_list, head) {
+ if (encoder-crtc != crtc)
+ continue;
+ encoder_funcs = encoder-helper_private;
+ encoder_funcs-dpms(encoder, dpms_mode);
+ }
+
+ crtc_funcs-dpms(crtc, dpms_mode);
+ }
+}
+
/* Returns the clock of the currently programmed mode of the given pipe. */
static int intel_crtc_clock_get(struct drm_device *dev, struct drm_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d6f92ea..f747dd4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -142,6 +142,11 @@ extern struct drm_crtc *intel_get_load_detect_pipe(struct
intel_output
[PATCH 2/6] [drm/i915] remove open-coded drm_mode_object_find
And clean up a small whitespace goof-up in the same function, while
I was looking at it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d6fce21..bb59356 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3124,30 +3124,26 @@ int intel_get_pipe_from_crtc_id(struct drm_device *dev,
void *data,
{
drm_i915_private_t *dev_priv = dev-dev_private;
struct drm_i915_get_pipe_from_crtc_id *pipe_from_crtc_id = data;
- struct drm_crtc *crtc = NULL;
- int pipe = -1;
+ struct drm_mode_object *drmmode_obj;
+ struct intel_crtc *crtc;
if (!dev_priv) {
DRM_ERROR(called with no initialization\n);
return -EINVAL;
}
- list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- if (crtc-base.id == pipe_from_crtc_id-crtc_id) {
- pipe = intel_crtc-pipe;
- break;
- }
- }
+ drmmode_obj = drm_mode_object_find(dev, pipe_from_crtc_id-crtc_id,
+ DRM_MODE_OBJECT_CRTC);
- if (pipe == -1) {
+ if (!drmmode_obj) {
DRM_ERROR(no such CRTC id\n);
return -EINVAL;
}
- pipe_from_crtc_id-pipe = pipe;
+ crtc = to_intel_crtc(obj_to_crtc(drmmode_obj));
+ pipe_from_crtc_id-pipe = crtc-pipe;
- return 0;
+ return 0;
}
struct drm_crtc *intel_get_crtc_from_pipe(struct drm_device *dev, int pipe)
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 5/6] [drm/i915]: add i915_lp_ring_sync helper
This just waits until the hw passed the current ring position with
cmd execution. This slightly changes the existing i915_wait_request
function to make uninterruptible waiting possible - no point in
returning to userspace while mucking around with the overlay, that
piece of hw is just too fragile.
Also replace a magic 0 with the symbolic constant (and kill the then
superflous comment) while I was looking at the code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 51 +++---
include/drm/drm_os_linux.h |2 +-
3 files changed, 43 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7537f57..2d79ede 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -692,6 +692,7 @@ void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int i915_gem_do_init(struct drm_device *dev, unsigned long start,
unsigned long end);
int i915_gem_idle(struct drm_device *dev);
+int i915_lp_ring_sync(struct drm_device *dev);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int i915_gem_object_set_to_gtt_domain(struct drm_gem_object *obj,
int write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 140bee1..6f1b5f9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1723,12 +1723,8 @@ i915_gem_retire_work_handler(struct work_struct *work)
mutex_unlock(dev-struct_mutex);
}
-/**
- * Waits for a sequence number to be signaled, and cleans up the
- * request and object lists appropriately for that event.
- */
static int
-i915_wait_request(struct drm_device *dev, uint32_t seqno)
+i915_do_wait_request(struct drm_device *dev, uint32_t seqno, int interruptible)
{
drm_i915_private_t *dev_priv = dev-dev_private;
u32 ier;
@@ -1750,10 +1746,17 @@ i915_wait_request(struct drm_device *dev, uint32_t
seqno)
dev_priv-mm.waiting_gem_seqno = seqno;
i915_user_irq_get(dev);
- ret = wait_event_interruptible(dev_priv-irq_queue,
-
i915_seqno_passed(i915_get_gem_seqno(dev),
-seqno) ||
- dev_priv-mm.wedged);
+ if (interruptible)
+ ret = wait_event_interruptible(dev_priv-irq_queue,
+
i915_seqno_passed(i915_get_gem_seqno(dev),
+seqno) ||
+ dev_priv-mm.wedged);
+ else
+ wait_event(dev_priv-irq_queue,
+
i915_seqno_passed(i915_get_gem_seqno(dev),
+seqno) ||
+ dev_priv-mm.wedged);
+
i915_user_irq_put(dev);
dev_priv-mm.waiting_gem_seqno = 0;
}
@@ -1775,6 +1778,34 @@ i915_wait_request(struct drm_device *dev, uint32_t seqno)
return ret;
}
+/**
+ * Waits for a sequence number to be signaled, and cleans up the
+ * request and object lists appropriately for that event.
+ */
+static int
+i915_wait_request(struct drm_device *dev, uint32_t seqno)
+{
+ return i915_do_wait_request(dev, seqno, 1);
+}
+
+/**
+ * Waits for the ring to finish up to the latest request. Usefull for waiting
+ * for flip events, e.g for the overlay support. */
+int i915_lp_ring_sync(struct drm_device *dev)
+{
+ uint32_t seqno;
+ int ret;
+
+ seqno = i915_add_request(dev, NULL, 0);
+
+ if (seqno == 0)
+ return -ENOMEM;
+
+ ret = i915_do_wait_request(dev, seqno, 0);
+ BUG_ON(ret == -ERESTARTSYS);
+ return ret;
+}
+
static void
i915_gem_flush(struct drm_device *dev,
uint32_t invalidate_domains,
@@ -1841,7 +1872,7 @@ i915_gem_flush(struct drm_device *dev,
#endif
BEGIN_LP_RING(2);
OUT_RING(cmd);
- OUT_RING(0); /* noop */
+ OUT_RING(MI_NOOP);
ADVANCE_LP_RING();
}
}
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 26641e9..3933691 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -123,5 +123,5 @@ do {
\
remove_wait_queue((queue), entry);\
} while (0)
-#define DRM_WAKEUP( queue ) wake_up_interruptible( queue )
+#define DRM_WAKEUP( queue ) wake_up( queue )
#define DRM_INIT_WAITQUEUE( queue ) init_waitqueue_head( queue )
--
1.6.3.3
--
Let Crystal
[PATCH 3/6] [drm/i915]: modeset: always set intel_crtc-dpms_mode
... by moving the assignment up. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bb59356..818c703 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1581,6 +1581,8 @@ static void intel_crtc_dpms(struct drm_crtc *crtc, int mode) else i9xx_crtc_dpms(crtc, mode); + intel_crtc-dpms_mode = mode; + if (!dev-primary-master) return; @@ -1603,8 +1605,6 @@ static void intel_crtc_dpms(struct drm_crtc *crtc, int mode) DRM_ERROR(Can't update pipe %d in SAREA\n, pipe); break; } - - intel_crtc-dpms_mode = mode; } static void intel_crtc_prepare (struct drm_crtc *crtc) -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/6] [drm]: make drm_mode_object_find typesafe
I've wasted half a day hunting a bug that could easily be spotted by
gcc. Prevent this from reoccurring.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33be210..addb09d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -243,7 +243,8 @@ static void drm_mode_object_put(struct drm_device *dev,
mutex_unlock(dev-mode_config.idr_mutex);
}
-void *drm_mode_object_find(struct drm_device *dev, uint32_t id, uint32_t type)
+struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type)
{
struct drm_mode_object *obj = NULL;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7300fb8..1946d42 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -691,7 +691,8 @@ extern void drm_mode_connector_detach_encoder(struct
drm_connector *connector,
struct drm_encoder *encoder);
extern bool drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-extern void *drm_mode_object_find(struct drm_device *dev, uint32_t id,
uint32_t type);
+extern struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
+ uint32_t id, uint32_t type);
/* IOCTLs */
extern int drm_mode_getresources(struct drm_device *dev,
void *data, struct drm_file *file_priv);
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 6/6] [drm/i915] implement drmmode overlay support
Open issues:
- Flickering. But when the frame is not changed, this stabilizes
after a few seconds (at most).
- Runs in sync with the gpu, i.e. unnecessary waiting. Unfortunately
changes in this area tend to hang the hw, so let's leave it at this
for the moment. I left some dummy functions as infrastructure.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_dma.c |7 +
drivers/gpu/drm/i915/i915_drv.h |4 +
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_display.c | 26 +-
drivers/gpu/drm/i915/intel_drv.h | 30 +
drivers/gpu/drm/i915/intel_overlay.c | 1289 ++
include/drm/i915_drm.h | 71 ++
8 files changed, 1430 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 30d6b99..d06fece 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -22,6 +22,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_fb.o \
intel_tv.o \
intel_dvo.o \
+ intel_overlay.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
dvo_ivch.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 50d1f78..7763967 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -777,6 +777,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_NUM_FENCES_AVAIL:
value = dev_priv-num_fence_regs - dev_priv-fence_reg_start;
break;
+ case I915_PARAM_HAS_OVERLAY:
+ value = dev_priv-overlay ? 1 : 0;
+ break;
default:
DRM_DEBUG_DRIVER(I915_DRV, Unknown parameter %d\n,
param-param);
@@ -1310,6 +1313,8 @@ int i915_driver_unload(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
drm_mm_takedown(dev_priv-vram);
i915_gem_lastclose(dev);
+
+ intel_cleanup_overlay(dev);
}
kfree(dev-dev_private);
@@ -1416,6 +1421,8 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF(DRM_I915_GEM_GET_TILING, i915_gem_get_tiling, 0),
DRM_IOCTL_DEF(DRM_I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl,
0),
DRM_IOCTL_DEF(DRM_I915_GET_PIPE_FROM_CRTC_ID,
intel_get_pipe_from_crtc_id, 0),
+ DRM_IOCTL_DEF(DRM_I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW),
+ DRM_IOCTL_DEF(DRM_I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW),
};
int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2d79ede..19dd7c3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -149,6 +149,7 @@ struct drm_i915_error_state {
struct timeval time;
};
+struct intel_overlay;
typedef struct drm_i915_private {
struct drm_device *dev;
@@ -206,6 +207,9 @@ typedef struct drm_i915_private {
struct intel_opregion opregion;
+ /* overlay */
+ struct intel_overlay *overlay;
+
/* LVDS info */
int backlight_duty_cycle; /* restore backlight to this value */
bool panel_wants_dither;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2955083..7bb6e88 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -116,6 +116,7 @@
#define MI_NOOPMI_INSTR(0, 0)
#define MI_USER_INTERRUPT MI_INSTR(0x02, 0)
#define MI_WAIT_FOR_EVENT MI_INSTR(0x03, 0)
+#define MI_WAIT_FOR_OVERLAY_FLIP (116)
#define MI_WAIT_FOR_PLANE_B_FLIP (16)
#define MI_WAIT_FOR_PLANE_A_FLIP (12)
#define MI_WAIT_FOR_PLANE_A_SCANLINES (11)
@@ -127,6 +128,10 @@
#define MI_END_SCENE (1 4) /* flush binner and incr scene count */
#define MI_BATCH_BUFFER_ENDMI_INSTR(0x0a, 0)
#define MI_REPORT_HEAD MI_INSTR(0x07, 0)
+#define MI_OVERLAY_FLIPMI_INSTR(0x11,0)
+#define MI_OVERLAY_CONTINUE (0x021)
+#define MI_OVERLAY_ON(0x121)
+#define MI_OVERLAY_OFF (0x221)
#define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
#define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
#define MI_MEM_VIRTUAL (1 22) /* 965+ only */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cb709b8..d2ddcbd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1463,6 +1463,22 @@ static void igdng_crtc_dpms(struct drm_crtc *crtc, int
mode)
}
}
+static void intel_crtc_dpms_overlay(struct intel_crtc *intel_crtc, bool enable)
+{
+ struct intel_overlay
Re: drm sysfs questions
On Tue, 11 Aug 2009 11:23:09 +0200 Thomas Hellström tho...@shipmail.org wrote: Hi! I'm wondering why we are using a struct device as a sysfs representation for connectors instead of a struct kobject? In particular, what stops the drm_sysfs_[suspend|resume] functions to get called for the connectors, having them cast to a struct drm_minor and sending the cpu to the bushes? Hm, maybe we're just getting lucky that the drm minor check fails for everything but the DRM core device. kobjects might make sense to move to, unless we can think of other things we'd like to do with a full device (e.g. runtime power management or some sort of per-connector suspend/resume). -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume] functions to
get called for the connectors, having them cast to a struct drm_minor
and sending the cpu to the bushes?
Hm, maybe we're just getting lucky that the drm minor check fails for
everything but the DRM core device.
Yes, I think that's actually the case.
kobjects might make sense to move
to, unless we can think of other things we'd like to do with a full
device (e.g. runtime power management or some sort of per-connector
suspend/resume).
I can't really think of a case where the device owning the connector
can't handle this?
But we'd lose the /sys/drm/xxx symlinks to the connectors, and if that
does matter, we'd need to recreate those manually.
Anyway, I'd also like to be able to add a virtual ttm device to the drm
sysfs hierarchy, the purpose of which would be to do the right thing
with uncached / write-combined pages at suspend. The virtual device
won't be wrapped in a drm minor so I'm wondering wether we could wrap
the struct device like so:
struct drm_sysfs_device {
enum drm_sysfs_device_type type;
struct device kdev;
}
This way the drm sysfs suspend / resume hooks can check the type of the
structure embedding the struct device and only call the driver hooks for
the relevand device types.
/Thomas
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21682] White screen with compiz/AIGLX on X.org server 1.5.2 when running on 16bpp (intel 945GM)
http://bugs.freedesktop.org/show_bug.cgi?id=21682 Eric Anholt e...@anholt.net changed: What|Removed |Added Keywords||NEEDINFO --- Comment #12 from Eric Anholt e...@anholt.net 2009-08-11 12:54:14 PST --- I read #1, and #1-#5 all show DRI1 in use, not DRI2. Could you attach a Xorg.0.log from reproducing the problem with DRI2? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 19876] 3D acceleration not working on i945GM
http://bugs.freedesktop.org/show_bug.cgi?id=19876 Eric Anholt e...@anholt.net changed: What|Removed |Added AssignedTo|dri-|e...@anholt.net |de...@lists.sourceforge.net | -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Tue, 11 Aug 2009 16:17:46 -0700 Jesse Barnes jesse.bar...@intel.com wrote: On Tue, 11 Aug 2009 15:52:06 +1000 Dave Airlie airl...@gmail.com wrote: From: Tiago Vignatti tiago.vigna...@nokia.com Background: Graphic devices are accessed through ranges in I/O or memory space. While most modern devices allow relocation of such ranges, some Legacy VGA devices implemented on PCI will typically have the same hard-decoded addresses as they did on ISA. For more details see PCI Bus Binding to IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware Revision 2.1 Section 7, Legacy Devices. The Resource Access Control (RAC) module inside the X server currently does the task of arbitration when more than one legacy device co-exists on the same machine. But the problem happens when these devices are trying to be accessed by different userspace clients (e.g. two server in parallel). Their address assignments conflict. Therefore an arbitration scheme _outside_ of the X server is needed to control the sharing of these resources. This document introduces the operation of the VGA arbiter implemented for Linux kernel. Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com Signed-off-by: Dave Airlie airl...@redhat.com Ok, applied this to my linux-next branch, but I'd like to get Ben's s-o-b before pushing it to Linus. Oh yeah, and we should get the documentation merged too. I can handle that or you can send it to Randy. Tiago? -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm sysfs questions
On Tue, 11 Aug 2009 20:29:39 +0200
Thomas Hellström tho...@shipmail.org wrote:
Jesse Barnes wrote:
On Tue, 11 Aug 2009 11:23:09 +0200
Thomas Hellström tho...@shipmail.org wrote:
Hi!
I'm wondering why we are using a struct device as a sysfs
representation for connectors instead of a struct kobject?
In particular, what stops the drm_sysfs_[suspend|resume] functions
to get called for the connectors, having them cast to a struct
drm_minor and sending the cpu to the bushes?
Hm, maybe we're just getting lucky that the drm minor check fails
for everything but the DRM core device.
Yes, I think that's actually the case.
kobjects might make sense to move
to, unless we can think of other things we'd like to do with a full
device (e.g. runtime power management or some sort of per-connector
suspend/resume).
I can't really think of a case where the device owning the connector
can't handle this?
But we'd lose the /sys/drm/xxx symlinks to the connectors, and if
that does matter, we'd need to recreate those manually.
Anyway, I'd also like to be able to add a virtual ttm device to the
drm sysfs hierarchy, the purpose of which would be to do the right
thing with uncached / write-combined pages at suspend. The virtual
device won't be wrapped in a drm minor so I'm wondering wether we
could wrap the struct device like so:
struct drm_sysfs_device {
enum drm_sysfs_device_type type;
struct device kdev;
}
This way the drm sysfs suspend / resume hooks can check the type of
the structure embedding the struct device and only call the driver
hooks for the relevand device types.
Yeah, that could work, but it seems like an explicit callout from
drivers using TTM (or a callout from the core drm suspend/resume
routines conditional on a DRIVER_HAS_TTM check) would be a bit
simpler. Or did you have other TTM info you wanted to expose sysfs as
well?
--
Jesse Barnes, Intel Open Source Technology Center
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Tue, 11 Aug 2009 15:52:06 +1000 Dave Airlie airl...@gmail.com wrote: From: Tiago Vignatti tiago.vigna...@nokia.com Background: Graphic devices are accessed through ranges in I/O or memory space. While most modern devices allow relocation of such ranges, some Legacy VGA devices implemented on PCI will typically have the same hard-decoded addresses as they did on ISA. For more details see PCI Bus Binding to IEEE Std 1275-1994 Standard for Boot (Initialization Configuration) Firmware Revision 2.1 Section 7, Legacy Devices. The Resource Access Control (RAC) module inside the X server currently does the task of arbitration when more than one legacy device co-exists on the same machine. But the problem happens when these devices are trying to be accessed by different userspace clients (e.g. two server in parallel). Their address assignments conflict. Therefore an arbitration scheme _outside_ of the X server is needed to control the sharing of these resources. This document introduces the operation of the VGA arbiter implemented for Linux kernel. Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com Signed-off-by: Dave Airlie airl...@redhat.com Ok, applied this to my linux-next branch, but I'd like to get Ben's s-o-b before pushing it to Linus. Ben? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23234] radeon , kms , xrandr - mouse disspaears on secondary screen
http://bugs.freedesktop.org/show_bug.cgi?id=23234 Adam Goode a...@spicenitz.org changed: What|Removed |Added CC||a...@spicenitz.org --- Comment #4 from Adam Goode a...@spicenitz.org 2009-08-11 17:18:29 PST --- Might this be related to https://bugzilla.redhat.com/show_bug.cgi?id=466623 ? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm: Add more standard TV properties.
Overscan, saturation, hue. Used in the nouveau driver for GPUs with
integrated TV encoders.
---
drivers/gpu/drm/drm_crtc.c | 18 ++
include/drm/drm_crtc.h |3 +++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a8c8311..362a538 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -736,6 +736,24 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
int num_modes,
dev-mode_config.tv_flicker_reduction_property-values[0] = 0;
dev-mode_config.tv_flicker_reduction_property-values[1] = 100;
+ dev-mode_config.tv_overscan_property =
+ drm_property_create(dev, DRM_MODE_PROP_RANGE,
+ overscan, 2);
+ dev-mode_config.tv_overscan_property-values[0] = 0;
+ dev-mode_config.tv_overscan_property-values[1] = 100;
+
+ dev-mode_config.tv_saturation_property =
+ drm_property_create(dev, DRM_MODE_PROP_RANGE,
+ saturation, 2);
+ dev-mode_config.tv_saturation_property-values[0] = 0;
+ dev-mode_config.tv_saturation_property-values[1] = 100;
+
+ dev-mode_config.tv_hue_property =
+ drm_property_create(dev, DRM_MODE_PROP_RANGE,
+ hue, 2);
+ dev-mode_config.tv_hue_property-values[0] = 0;
+ dev-mode_config.tv_hue_property-values[1] = 100;
+
return 0;
}
EXPORT_SYMBOL(drm_mode_create_tv_properties);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5f2cc0c..db92a83 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -575,6 +575,9 @@ struct drm_mode_config {
struct drm_property *tv_brightness_property;
struct drm_property *tv_contrast_property;
struct drm_property *tv_flicker_reduction_property;
+ struct drm_property *tv_overscan_property;
+ struct drm_property *tv_saturation_property;
+ struct drm_property *tv_hue_property;
/* Optional properties */
struct drm_property *scaling_mode_property;
--
1.6.3.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm: Fix drm_cvt_mode() for interlaced modes.
The calculated vdisplay was half the right value. --- drivers/gpu/drm/drm_modes.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 6b4d2dc..9e54925 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -146,7 +146,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device *dev, int hdisplay, if (margins) vmargin = vdisplay_rnd * CVT_MARGIN_PERCENTAGE / 1000; - drm_mode-vdisplay = vdisplay_rnd + 2 * vmargin; + drm_mode-vdisplay = vdisplay + 2 * vmargin; /* Interlaced */ if (interlaced) -- 1.6.3.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23240] Neverwinter Nights freezes, X and nwmain consume 100% cpu, and trace shows radeon to blame.
http://bugs.freedesktop.org/show_bug.cgi?id=23240 --- Comment #2 from Stephen E. Baker cyco...@hotmail.com 2009-08-11 17:02:15 PST --- Today I recreated the freeze I saw this in my messages leading up to it: Aug 11 19:35:59 goodt60 [drm] Num pipes: 1 Aug 11 19:36:05 goodt60 [drm] Num pipes: 1 Aug 11 19:36:10 goodt60 [drm] Num pipes: 1 Aug 11 19:36:12 goodt60 [drm] Num pipes: 1 Aug 11 19:36:12 goodt60 [drm] Num pipes: 1 Aug 11 19:36:14 goodt60 [drm] Num pipes: 1 Aug 11 19:36:21 goodt60 CE: hpet increasing min_delta_ns to 50624 nsec Aug 11 19:36:22 goodt60 [drm] Num pipes: 1 Aug 11 19:36:24 goodt60 [drm] Num pipes: 1 Aug 11 19:36:25 goodt60 [drm] Num pipes: 1 Aug 11 19:36:26 goodt60 [drm] Num pipes: 1 Aug 11 19:36:30 goodt60 [drm] Num pipes: 1 Aug 11 19:36:32 goodt60 [drm] Num pipes: 1 Aug 11 19:36:33 goodt60 [drm] Num pipes: 1 Aug 11 19:36:34 goodt60 [drm] Num pipes: 1 Aug 11 19:36:38 goodt60 [drm] Num pipes: 1 Aug 11 19:36:40 goodt60 [drm] Num pipes: 1 Aug 11 19:36:41 goodt60 [drm] Num pipes: 1 Aug 11 19:36:42 goodt60 [drm] Num pipes: 1 Aug 11 19:36:47 goodt60 [drm] Num pipes: 1 Aug 11 19:36:53 goodt60 [drm] Num pipes: 1 Aug 11 19:36:53 goodt60 [drm] Num pipes: 1 Does this help? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
