[PATCH] [DRM] i915: add support for G41 chipset
Here's drm patch for G41, against drm-next tree.
(agp patch is against agp-next tree, missed to state that...)
[PATCH] [DRM] i915: add support for G41 chipset
Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
drivers/gpu/drm/i915/i915_drv.h |6 --
include/drm/drm_pciids.h|1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 71326ca..e542c1a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -360,7 +360,8 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
(dev)->pci_device == 0x2A42 || \
(dev)->pci_device == 0x2E02 || \
(dev)->pci_device == 0x2E12 || \
- (dev)->pci_device == 0x2E22)
+ (dev)->pci_device == 0x2E22 || \
+ (dev)->pci_device == 0x2E32)
#define IS_I965GM(dev) ((dev)->pci_device == 0x2A02)
@@ -368,7 +369,8 @@ extern int i915_wait_ring(struct drm_device * dev, int n,
const char *caller);
#define IS_G4X(dev) ((dev)->pci_device == 0x2E02 || \
(dev)->pci_device == 0x2E12 || \
-(dev)->pci_device == 0x2E22)
+(dev)->pci_device == 0x2E22 || \
+(dev)->pci_device == 0x2E32)
#define IS_G33(dev)((dev)->pci_device == 0x29C2 || \
(dev)->pci_device == 0x29B2 || \
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 135bd19..0d97c90 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -412,4 +412,5 @@
{0x8086, 0x2e02, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x8086, 0x2e12, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0x8086, 0x2e22, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
+ {0x8086, 0x2e32, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, \
{0, 0, 0}
--
1.5.6.5
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: Digital signature
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 16786] mesa-7.1: googleearth, sauerbraten not working anymore
http://bugs.freedesktop.org/show_bug.cgi?id=16786 --- Comment #1 from Markus Rathgeb <[EMAIL PROTECTED]> 2008-09-11 05:02:23 PST --- I used strace in combination with googleearth and it seems that there is a problem with the fonts (infinite loop). Wenn I comment out all my fontpaths in the file section (xorg.conf) googleearth starts fine. I will look if the problem with sauerbraten can also solved with commenting out some configurations in my xorg.conf. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears crash with latest mesa swrast module
Marco wrote: >> I don't see how that change could be related to a SwapBuffers crash > > Sorry I was misunderstod: that is latest commit I have. > > Last mesa sources I had was from 20/08/2008, and glxgears was running > fine, then I upgraded till the commit of Fri Sep 5 08:06:59 2008 > -0600 and glxgears now crashes. I don't see any problem here and nobody else has reported it. Did you try a clean rebuild? -Brian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] updated GTT mapping for i915/GEM
Here's an updated set of GTT mapping patches against Eric's drm-gem-merge
branch from earlier today and DRM master for the libdrm bits. I fixed up a
couple of bugs, but it looks like UXA/EXA still don't work against GEM even
w/o these changes applied. I'm not quite sure about the zap_vma_ptes code,
that'll need review from one of the MM guys (Nick can you take a look at the
i915-gtt-mapping patch?).
Other than that, I think the code is looking fairly complete, so at this point
we just need to stabilize GEM and play with using GTT mapping for the general
dri_bo_map case to see if we want to do it by default.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/src/i830_exa.c b/src/i830_exa.c
index fd29df1..8213242 100644
--- a/src/i830_exa.c
+++ b/src/i830_exa.c
@@ -767,7 +767,7 @@ i830_uxa_prepare_access (PixmapPtr pixmap, uxa_access_t access)
I830Sync(scrn);
i830->need_sync = FALSE;
}
- if (dri_bo_map (bo, access == UXA_ACCESS_RW) != 0)
+ if (dri_gem_bo_map_gtt(bo, 4096))
return FALSE;
pixmap->devPrivate.ptr = bo->virtual;
}
diff --git a/libdrm/intel/intel_bufmgr.h b/libdrm/intel/intel_bufmgr.h
index c44d596..51b08a4 100644
--- a/libdrm/intel/intel_bufmgr.h
+++ b/libdrm/intel/intel_bufmgr.h
@@ -123,5 +123,7 @@ void intel_bo_fake_disable_backing_store(dri_bo *bo,
void intel_bufmgr_fake_contended_lock_take(dri_bufmgr *bufmgr);
void intel_bufmgr_fake_evict_all(dri_bufmgr *bufmgr);
+int dri_gem_bo_map_gtt(dri_bo *bo, uint32_t alignment);
+
#endif /* INTEL_BUFMGR_H */
diff --git a/libdrm/intel/intel_bufmgr_gem.c b/libdrm/intel/intel_bufmgr_gem.c
index 97e387f..af90a4f 100644
--- a/libdrm/intel/intel_bufmgr_gem.c
+++ b/libdrm/intel/intel_bufmgr_gem.c
@@ -39,6 +39,7 @@
#endif
#include
+#include
#include
#include
#include
@@ -46,6 +47,8 @@
#include
#include
#include
+#include
+#include
#include "errno.h"
#include "intel_bufmgr.h"
@@ -517,6 +520,83 @@ dri_gem_bo_map(dri_bo *bo, int write_enable)
return 0;
}
+int
+dri_gem_bo_map_gtt(dri_bo *bo, uint32_t alignment)
+{
+dri_bufmgr_gem *bufmgr_gem;
+dri_bo_gem *bo_gem = (dri_bo_gem *)bo;
+struct drm_i915_gem_set_domain set_domain;
+int ret;
+
+bufmgr_gem = (dri_bufmgr_gem *)bo->bufmgr;
+
+/* Allow recursive mapping. Mesa may recursively map buffers with
+ * nested display loops.
+ */
+if (!bo_gem->mapped) {
+
+ assert(bo->virtual == NULL);
+
+ DBG("bo_map_gtt: %d (%s)\n", bo_gem->gem_handle, bo_gem->name);
+
+ if (bo_gem->virtual == NULL) {
+ struct drm_i915_gem_mmap_gtt mmap_arg;
+
+ memset(&mmap_arg, 0, sizeof(mmap_arg));
+ mmap_arg.handle = bo_gem->gem_handle;
+ /* Just map the whole object */
+ mmap_arg.offset = 0;
+ mmap_arg.size = bo->size;
+ mmap_arg.alignment = alignment;
+
+ ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_MMAP_GTT,
+ &mmap_arg);
+ if (ret != 0) {
+ fprintf(stderr,
+"%s:%d: Error preparing buffer map %d (%s): %s .\n",
+__FILE__, __LINE__,
+bo_gem->gem_handle, bo_gem->name,
+strerror(errno));
+ return ret;
+ }
+ bo_gem->virtual = mmap(0, bo->size, PROT_READ | PROT_WRITE,
+ MAP_SHARED, bufmgr_gem->fd,
+ mmap_arg.addr_ptr);
+ if (bo_gem->virtual == MAP_FAILED) {
+ fprintf(stderr,
+"%s:%d: Error mapping buffer %d (%s): %s .\n",
+__FILE__, __LINE__,
+bo_gem->gem_handle, bo_gem->name,
+strerror(errno));
+ return errno;
+ }
+ }
+
+ bo->virtual = bo_gem->virtual;
+ bo_gem->swrast = 0;
+ bo_gem->mapped = 1;
+ DBG("bo_map: %d (%s) -> %p\n", bo_gem->gem_handle, bo_gem->name,
+ bo_gem->virtual);
+}
+
+if (!bo_gem->swrast) {
+ set_domain.handle = bo_gem->gem_handle;
+ set_domain.read_domains = I915_GEM_DOMAIN_GTT;
+ set_domain.write_domain = I915_GEM_DOMAIN_GTT;
+ do {
+ ret = ioctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_SET_DOMAIN,
+ &set_domain);
+ } while (ret == -1 && errno == EINTR);
+ if (ret != 0) {
+ fprintf (stderr, "%s:%d: Error setting swrast %d: %s\n",
+ __FILE__, __LINE__, bo_gem->gem_handle, strerror (errno));
+ }
+ bo_gem->swrast = 1;
+}
+
+return 0;
+}
+
static int
dri_gem_bo_unmap(dri_bo *bo)
{
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index bde64b8..9916366 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -262,6 +262,9 @@ static int drm_addmap_core(struct drm_device * dev, unsigned int offset,
DRM_DEBUG("AGP offset = 0x%08lx, size = 0x%08lx\n", map->offset, map->size);
break;
+ case _DRM_GEM:
+ DRM_ERROR("tried to rmmap GEM object\n");
+ break;
}
case _DRM_SCATTER_GATHER:
if (!dev->sg) {
@@ -419,6 +422,9 @@ int drm_rmmap_locked(struct drm_device *dev, drm_local_map_t *map)
dmah.size = map->size;
__drm_pci_free(dev, &dmah);
break;
+ case _DRM_GEM:
+ DRM_ERROR("tried to rmmap GEM object\n");
+ break;
}
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm
Re: [PATCH] updated GTT mapping for i915/GEM
On Thu, Sep 11, 2008 at 06:16:21PM -0700, Jesse Barnes wrote:
> Here's an updated set of GTT mapping patches against Eric's drm-gem-merge
> branch from earlier today and DRM master for the libdrm bits. I fixed up a
> couple of bugs, but it looks like UXA/EXA still don't work against GEM even
> w/o these changes applied. I'm not quite sure about the zap_vma_ptes code,
> that'll need review from one of the MM guys (Nick can you take a look at the
> i915-gtt-mapping patch?).
>
> Other than that, I think the code is looking fairly complete, so at this
> point
> we just need to stabilize GEM and play with using GTT mapping for the general
> dri_bo_map case to see if we want to do it by default.
Well I had a quick look, and the zap_vma_ptes call seems fine. It will just
basically undo the effects of all the vm_insert_pfn calls on that vma, right?
Anything in particular you were worried about?
> return 0;
> }
>
> +void i915_gem_vm_open(struct vm_area_struct *vma)
> +{
> +}
> +
> +void i915_gem_vm_close(struct vm_area_struct *vma)
> +{
> +}
Just a nitpick but can you just skip these if they are empty?
> +int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> +{
> + struct drm_gem_object *obj = vma->vm_private_data;
> + struct drm_device *dev = obj->dev;
> + struct drm_i915_gem_object *obj_priv = obj->driver_private;
> + unsigned long page_offset;
> + unsigned long pfn;
> + int ret = 0;
> +
> + page_offset = ((unsigned long)vmf->virtual_address - vma->vm_start) >>
> + PAGE_SHIFT;
vmf->pgoff?
> +
> + DRM_ERROR("faulting in object %d offset 0x%08lx\n", obj->name,
> + page_offset);
> +
> + /* Now bind it into the GTT */
> + if (i915_gem_object_bind_to_gtt(obj, obj_priv->gtt_alignment))
> + return VM_FAULT_SIGBUS;
> +
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + pfn = ((dev->agp->base + obj_priv->gtt_offset) >> PAGE_SHIFT) +
> + page_offset;
> + /* Finally, remap it using the new GTT offset */
> + ret = vm_insert_pfn(vma, (unsigned long)vmf->virtual_address, pfn);
> +
> + return ret == -EAGAIN ? VM_FAULT_OOM : VM_FAULT_NOPAGE;
> +}
Should better check return from vm_inesrt_pfn, maybe?
-ENOMEM should give VM_FAULT_OOM
-EFAULT would be a bug in the driver probably, but VM_FAULT_SIGBUS maybe
-EBUSY might be a bug (or maybe it can happen if multiple threads fault
the same address, in which case VM_FAULT_NOPAGE is fine).
> +
> +int i915_gem_vm_mkwrite(struct vm_area_struct *vma, struct page *page)
> +{
> + return 0;
> +}
> +
> +int i915_gem_vm_access(struct vm_area_struct *vma, unsigned long addr,
> +void *buf, int len, int write)
> +{
> + return 0;
> +}
Same for these...
> @@ -940,6 +1029,10 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
>
> BUG_ON(obj_priv->active);
>
> + /* blow away mappings if mapped through GTT */
> + if (vma)
> + zap_vma_ptes(vma, vma->vm_start, vma->vm_end - vma->vm_start);
Seems fine to me.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
