Re: 2.6.35-rc4 Graphics performance issue and freeing invalid memtype messages on boot.
Hi, Jerome Glisse just helpfully pointed out that I'm running with KMS disabled (and indeed, CONFIG_DRM_RADEON_KMS is not set). So we have: - a CONFIG_DRM_RADEON_KMS which has some pretty strong wording discouraging its use (which IIRC is exactly the reason that I decided to not enable it yet at that time when KMS stuff has been introduced) - with KMS thus ending up disabled, things failing left and right... Something's not quite right... I'm currently doing a (complete, unfortunately) rebuild to retry with CONFIG_DRM_RADEON_KMS enabled, will report back. Andreas Mohr ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3.3-rc3] drm/i915: Fixes distorted external screen image on HP 2730p
On Mon, Feb 13, 2012 at 09:38:33AM +0100, Daniel Vetter wrote: > On Sun, Feb 12, 2012 at 11:10:32AM +0100, p...@haerkules.de wrote: > > From: Philipp Grete > > > > Fixes LP: #796030 by removing forced pipe A on HP 2730p. > > Quirk has previously been introduced to fix a sleep mode problem that does > > not exist any more. > > > > Signed-off-by: Philipp Grete > > --- > > Fix has been confirmed by at least three people (see > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030) who didn't > > experience any sleep mode problems after applying the patch. > > Can you please supply the corresponding tested-bys for these three people? > I.e. add > > Tested-by: Name > > to the sob part of your commit message. Also please add a reference to the > LP as a full link (easier to handle for people outside of the ubuntu > universe): > > Bugzilla: http://launchpad/direct/link/to/bug Ping. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3.3-rc3] drm/i915: Fixes distorted external screen image on HP 2730p
On Tue, Apr 3, 2012 at 10:48, Daniel Vetter wrote: > On Mon, Feb 13, 2012 at 09:38:33AM +0100, Daniel Vetter wrote: >> On Sun, Feb 12, 2012 at 11:10:32AM +0100, p...@haerkules.de wrote: >> > From: Philipp Grete >> > >> > Fixes LP: #796030 by removing forced pipe A on HP 2730p. >> > Quirk has previously been introduced to fix a sleep mode problem that does >> > not exist any more. >> > >> > Signed-off-by: Philipp Grete >> > --- >> > Fix has been confirmed by at least three people (see >> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030) who didn't >> > experience any sleep mode problems after applying the patch. >> >> Can you please supply the corresponding tested-bys for these three people? >> I.e. add >> >> Tested-by: Name >> >> to the sob part of your commit message. Also please add a reference to the >> LP as a full link (easier to handle for people outside of the ubuntu >> universe): >> >> Bugzilla: http://launchpad/direct/link/to/bug > > Ping. Disregard that ping, I've noticed that I've already picked this up. Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, mainly nouveau fixes, one for a regressions in -rc1, fixes for booting on a ppc G5, and a Kconfig fix. two radeon fix, one oops, one s/r fix. one udl mmap fix. and one core drm fix to stop bad fbdev apps overwriting bits of ram. I have some fixes from Intel I think on the way, but I'm offline until post-Easter from tomorrow, so maybe you'll see them maybe you won't :) Dave. The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: fix fans after resume Ben Skeggs (3): drm/nouveau: oops, create m2mf for nvd9 too Revert "drm/nouveau: inform userspace of new kernel subchannel requirements" drm/nouveau: inform userspace of relaxed kernel subchannel requirements Benjamin Herrenschmidt (2): nouveau: Fix crash when pci_ram_rom() returns a size of 0 nouveau/bios: Fix tracking of BIOS image data Chris Wilson (1): drm: Validate requested virtual size against allocated fb size Dave Airlie (2): Merge branch 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drm/nouveau: select POWER_SUPPLY Konstantin Khlebnikov (1): mm, drm/udl: fixup vma flags on mmap Michel Dänzer (1): drm/radeon: Don't dereference possibly-NULL pointer. drivers/gpu/drm/drm_fb_helper.c |8 ++-- drivers/gpu/drm/nouveau/Kconfig |1 + drivers/gpu/drm/nouveau/nouveau_bios.c|9 ++--- drivers/gpu/drm/nouveau/nouveau_channel.c | 10 +- drivers/gpu/drm/nouveau/nouveau_dma.h |4 ++-- drivers/gpu/drm/nouveau/nouveau_state.c |2 +- drivers/gpu/drm/radeon/atom.c | 15 ++- drivers/gpu/drm/radeon/atom.h |1 + drivers/gpu/drm/radeon/radeon_object.c|3 ++- drivers/gpu/drm/udl/udl_drv.c |2 +- drivers/gpu/drm/udl/udl_drv.h |1 + drivers/gpu/drm/udl/udl_gem.c | 14 ++ 12 files changed, 54 insertions(+), 16 deletions(-)___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/prime: expose capability flags for userspace.
On Mon, 2 Apr 2012 14:11:50 +0100, Dave Airlie wrote: > From: Dave Airlie > > This lets the kernel tell userspace if the device supports prime > import/export. > > This is useful for -modesetting at least, but would be nice for other > drivers. > > Signed-off-by: Dave Airlie Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Process to merge Openchrome work
> > This last year the Openchrome support for the VIA chipsets has > come along way from being in a state of decay. The plan is to release > a Xorg driver June 1 that will have support for the KMS as well as UMS. > The goal is to have this xorg driver out in the wild before the kernel > side is ready so that the migration to the new kernel drivers will be > as painless as possible. My hope is to merge the kernel tree for public > use for Christmas. > This brings up the question I had with the other project leader. > How does one go about merging the tree? What makes this more complex is > that a old via drm kernel driver already exist. Do we just drop in the > code into the staging area? Does it have to be piece meal? Does a rename > of the driver need to happen? What would you recommend ? So what we've done before to avoid regression is a) add a new CONFIG_ option that is default n, so users don't get a regression, b) enable the KMS bits and PCI binding depending on the new option. Now the easiest way may be to make a new driver with a new name, make it bind to PCI devices etc, and just have CONFIG to turn it on/off. It depends on how much code the new driver shares with the old etc. So older distros can share the older code. Then you'd have to generate decent reviewable patches of the codebase and send them to dri-devel, where others could review them. The main thing review looks out for is that the userspace interfaces are sane and secure. I don't generally take git merges until people have built up a bit of trust sending decent patches, and making sure reviews are done. The other question is what to people lose if they switch to VIA KMS in terms of acceleration, is the 2D/3D Xorg/Mesa driver work at the same level as the old driver? does anyone care? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: enable pci bus mastering after card is initialised
From: Dave Airlie
This closes a race seen with kexec where we enable PCI bus mastering
but the card has been reinitialised fully yet.
This was previously fixed by a patch from Jerome, but this should
close the race completely.
Reported-and-tested-by: Markus Trippelsdorf
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r100.c |4
drivers/gpu/drm/radeon/r600.c |3 +++
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_kms.c|2 --
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 81801c1..e11df77 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1180,6 +1180,10 @@ int r100_cp_init(struct radeon_device *rdev, unsigned
ring_size)
WREG32(RADEON_CP_RB_WPTR_DELAY, 0);
WREG32(RADEON_CP_CSQ_MODE, 0x4D4D);
WREG32(RADEON_CP_CSQ_CNTL, RADEON_CSQ_PRIBM_INDBM);
+
+ /* at this point everything should be setup correctly to enable master
*/
+ pci_set_master(rdev->pdev);
+
radeon_ring_start(rdev, RADEON_RING_TYPE_GFX_INDEX,
&rdev->ring[RADEON_RING_TYPE_GFX_INDEX]);
r = radeon_ring_test(rdev, RADEON_RING_TYPE_GFX_INDEX, ring);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 5eb2382..50cf034 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3034,6 +3034,9 @@ int r600_irq_init(struct radeon_device *rdev)
else
r600_disable_interrupt_state(rdev);
+ /* at this point everything should be setup correctly to enable master
*/
+ pci_set_master(rdev->pdev);
+
/* enable irqs */
r600_enable_interrupts(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49f7cb7..a282331 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -951,7 +951,6 @@ int radeon_resume_kms(struct drm_device *dev)
console_unlock();
return -1;
}
- pci_set_master(dev->pdev);
/* resume AGP if in use */
radeon_agp_resume(rdev);
radeon_resume(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 1986eba..d335288 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned
long flags)
}
dev->dev_private = (void *)rdev;
- pci_set_master(dev->pdev);
-
/* update BUS flag */
if (drm_pci_device_is_agp(dev)) {
flags |= RADEON_IS_AGP;
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: enable pci bus mastering after card is initialised
On Tue, Apr 3, 2012 at 8:13 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This closes a race seen with kexec where we enable PCI bus mastering
> but the card has been reinitialised fully yet.
>
> This was previously fixed by a patch from Jerome, but this should
> close the race completely.
>
> Reported-and-tested-by: Markus Trippelsdorf
> Signed-off-by: Dave Airlie
For 3.4, you'll need to update si.c as well.
Alex
> ---
> drivers/gpu/drm/radeon/r100.c | 4
> drivers/gpu/drm/radeon/r600.c | 3 +++
> drivers/gpu/drm/radeon/radeon_device.c | 1 -
> drivers/gpu/drm/radeon/radeon_kms.c | 2 --
> 4 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 81801c1..e11df77 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -1180,6 +1180,10 @@ int r100_cp_init(struct radeon_device *rdev, unsigned
> ring_size)
> WREG32(RADEON_CP_RB_WPTR_DELAY, 0);
> WREG32(RADEON_CP_CSQ_MODE, 0x4D4D);
> WREG32(RADEON_CP_CSQ_CNTL, RADEON_CSQ_PRIBM_INDBM);
> +
> + /* at this point everything should be setup correctly to enable
> master */
> + pci_set_master(rdev->pdev);
> +
> radeon_ring_start(rdev, RADEON_RING_TYPE_GFX_INDEX,
> &rdev->ring[RADEON_RING_TYPE_GFX_INDEX]);
> r = radeon_ring_test(rdev, RADEON_RING_TYPE_GFX_INDEX, ring);
> if (r) {
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 5eb2382..50cf034 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3034,6 +3034,9 @@ int r600_irq_init(struct radeon_device *rdev)
> else
> r600_disable_interrupt_state(rdev);
>
> + /* at this point everything should be setup correctly to enable
> master */
> + pci_set_master(rdev->pdev);
> +
> /* enable irqs */
> r600_enable_interrupts(rdev);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 49f7cb7..a282331 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -951,7 +951,6 @@ int radeon_resume_kms(struct drm_device *dev)
> console_unlock();
> return -1;
> }
> - pci_set_master(dev->pdev);
> /* resume AGP if in use */
> radeon_agp_resume(rdev);
> radeon_resume(rdev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 1986eba..d335288 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned
> long flags)
> }
> dev->dev_private = (void *)rdev;
>
> - pci_set_master(dev->pdev);
> -
> /* update BUS flag */
> if (drm_pci_device_is_agp(dev)) {
> flags |= RADEON_IS_AGP;
> --
> 1.7.7.6
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] updated exynos-drm-fixes
this patch set fixes page align and duplicated allocation issues and removes unnecessary codes for code clean. this patch set is based on git repository below: git://people.freedesktop.org/~airlied/linux.git drm-fixes commit-id: 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e Please let me know if there is any problem. Thanks, Inki Dae Inki Dae (2): drm/exynos: fixed page align and code clean. drm/exynos: fixed duplicated page allocation bug. drivers/gpu/drm/exynos/exynos_drm_buf.c | 47 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 45 +++-- drivers/gpu/drm/exynos/exynos_drm_gem.h |2 + include/drm/exynos_drm.h|3 +- 4 files changed, 54 insertions(+), 43 deletions(-) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/exynos: fixed page align and code clean.
1M section, 64k page count also should be rounded up so this patch
rounds up them and caculates page count of them properly and also
checks memory flags from user.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 13 +++-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 45 --
drivers/gpu/drm/exynos/exynos_drm_gem.h |2 +
include/drm/exynos_drm.h|3 +-
4 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 4a3a5f7..52d42cd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -41,7 +41,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (flags & EXYNOS_BO_NONCONTIG) {
+ if (IS_NONCONTIG_BUFFER(flags)) {
DRM_DEBUG_KMS("not support allocation type.\n");
return -EINVAL;
}
@@ -52,13 +52,13 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
}
if (buf->size >= SZ_1M) {
- npages = (buf->size >> SECTION_SHIFT) + 1;
+ npages = buf->size >> SECTION_SHIFT;
page_size = SECTION_SIZE;
} else if (buf->size >= SZ_64K) {
- npages = (buf->size >> 16) + 1;
+ npages = buf->size >> 16;
page_size = SZ_64K;
} else {
- npages = (buf->size >> PAGE_SHIFT) + 1;
+ npages = buf->size >> PAGE_SHIFT;
page_size = PAGE_SIZE;
}
@@ -119,9 +119,6 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
buf->pages[i] = phys_to_page(start_addr);
- sgl = sg_next(sgl);
- sg_set_page(sgl, buf->pages[i+1], end_addr - start_addr, 0);
-
DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->kvaddr,
(unsigned long)buf->dma_addr,
@@ -150,7 +147,7 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
* non-continuous memory would be released by exynos
* gem framework.
*/
- if (flags & EXYNOS_BO_NONCONTIG) {
+ if (IS_NONCONTIG_BUFFER(flags)) {
DRM_DEBUG_KMS("not support allocation type.\n");
return;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index fa1aa94..26d5197 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -56,9 +56,28 @@ static unsigned int convert_to_vm_err_msg(int msg)
return out_msg;
}
-static unsigned int mask_gem_flags(unsigned int flags)
+static int check_gem_flags(unsigned int flags)
{
- return flags &= EXYNOS_BO_NONCONTIG;
+ if (flags & ~(EXYNOS_BO_MASK)) {
+ DRM_ERROR("invalid flags.\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static unsigned long roundup_gem_size(unsigned long size, unsigned int flags)
+{
+ if (!IS_NONCONTIG_BUFFER(flags)) {
+ if (size >= SZ_1M)
+ return roundup(size, SECTION_SIZE);
+ else if (size >= SZ_64K)
+ return roundup(size, SZ_64K);
+ else
+ goto out;
+ }
+out:
+ return roundup(size, PAGE_SIZE);
}
static struct page **exynos_gem_get_pages(struct drm_gem_object *obj,
@@ -319,10 +338,17 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
struct exynos_drm_gem_buf *buf;
int ret;
- size = roundup(size, PAGE_SIZE);
- DRM_DEBUG_KMS("%s: size = 0x%lx\n", __FILE__, size);
+ if (!size) {
+ DRM_ERROR("invalid size.\n");
+ return ERR_PTR(-EINVAL);
+ }
- flags = mask_gem_flags(flags);
+ size = roundup_gem_size(size, flags);
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ ret = check_gem_flags(flags);
+ if (ret)
+ return ERR_PTR(ret);
buf = exynos_drm_init_buf(dev, size);
if (!buf)
@@ -331,7 +357,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
exynos_gem_obj = exynos_drm_gem_init(dev, size);
if (!exynos_gem_obj) {
ret = -ENOMEM;
- goto err;
+ goto err_fini_buf;
}
exynos_gem_obj->buffer = buf;
@@ -347,18 +373,19 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
ret = exynos_drm_gem_get_pages(&exynos_gem_obj->base);
if (ret < 0) {
drm_gem_object_release(&exynos_gem_obj->base);
- goto err;
+ goto err_fini_buf;
}
} else {
ret = exynos_drm_alloc_buf(dev, buf, flags)
[PATCH 2/2] drm/exynos: fixed duplicated page allocation bug.
this patch fixes that buf->pages is allocated two times when it allocates
physically continuous memory region and removes unnecessary codes
for code clean.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 34 --
1 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 52d42cd..de8d209 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -34,7 +34,7 @@
static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
{
- dma_addr_t start_addr, end_addr;
+ dma_addr_t start_addr;
unsigned int npages, page_size, i = 0;
struct scatterlist *sgl;
int ret = 0;
@@ -76,26 +76,13 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
return -ENOMEM;
}
- buf->kvaddr = dma_alloc_writecombine(dev->dev, buf->size,
- &buf->dma_addr, GFP_KERNEL);
- if (!buf->kvaddr) {
- DRM_ERROR("failed to allocate buffer.\n");
- ret = -ENOMEM;
- goto err1;
- }
-
- start_addr = buf->dma_addr;
- end_addr = buf->dma_addr + buf->size;
-
- buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
- if (!buf->pages) {
- DRM_ERROR("failed to allocate pages.\n");
- ret = -ENOMEM;
- goto err2;
- }
-
- start_addr = buf->dma_addr;
- end_addr = buf->dma_addr + buf->size;
+ buf->kvaddr = dma_alloc_writecombine(dev->dev, buf->size,
+ &buf->dma_addr, GFP_KERNEL);
+ if (!buf->kvaddr) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
if (!buf->pages) {
@@ -105,20 +92,17 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
}
sgl = buf->sgt->sgl;
+ start_addr = buf->dma_addr;
while (i < npages) {
buf->pages[i] = phys_to_page(start_addr);
sg_set_page(sgl, buf->pages[i], page_size, 0);
sg_dma_address(sgl) = start_addr;
start_addr += page_size;
- if (end_addr - start_addr < page_size)
- break;
sgl = sg_next(sgl);
i++;
}
- buf->pages[i] = phys_to_page(start_addr);
-
DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->kvaddr,
(unsigned long)buf->dma_addr,
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] drm-intel-fixes for 3.4
Hi Dave, A few patches for 3.4, major part is 3 regression fixes: - ppgtt broke hibernate on snb/ivb. Somehow our QA claims that it still works, which is why this has not been caught earlier. - ppgtt flails in combination with dmar. I kinda expected this one :( - fence handling bugfix for gen2/3. Iirc this one is about a year old, fix curtesy Chris Wilson. I've created an shockingly simple i-g-t test to catch this in the future. Wrt regressions I've just got a report that gmbus (newly enabled again in 3.4) is a bit noisy. I'm looking into this atm. Also included are the rc6 enable patches for snb from Eugeni. I wanted to include these in the main 3.4 pull but screwed it up. Please hit me. Imo these kind of patches really should go in before -rc1, but in thise case rc6 has brought us tons of press and guinea pigs^W^W testers and ubuntu is already running with it. So I estimate a pretty small chance for this to blow up. And some smaller things: - two minor locking snafus - server gt2 ivb pciid - 2 patches to sanitize the register state left behind by the bios some more - 2 new quirk entries - cs readback trick against missed IRQs from ivb also enabled on snb - sprite fix from Jesse Yours, Daniel The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to b4db1e35ac59c144965f517bc575a0d75b60b03f: drm/i915: treat src w & h as fixed point in sprite handling code (2012-04-03 11:33:33 +0200) Anisse Astier (1): drm/i915: no-lvds quirk on MSI DC500 Chris Wilson (2): drm/i915: Sanitize BIOS debugging bits from PIPECONF drm/i915: Mark untiled BLT commands as fenced on gen2/3 Daniel Vetter (6): drm/i915: properly restore the ppgtt page directory on resume drm/i915: quirk away broken OpRegion VBT drm/i915: apply CS reg readback trick against missed IRQ on snb drm/i915: properly clear SSC1 bit in the pch refclock init code drm/i915: disable ppgtt on snb when dmar is enabled drm/i915: don't leak struct_mutex lock on ppgtt init failures Eugeni Dodonov (3): drm/i915: allow to select rc6 modes via kernel parameter drm/i915: enable plain RC6 on Sandy Bridge by default drm/i915: add Ivy Bridge GT2 Server entries Jesse Barnes (1): drm/i915: treat src w & h as fixed point in sprite handling code Sean Paul (1): drm/i915: Add lock on drm_helper_resume_force_mode drivers/char/agp/intel-agp.h |1 + drivers/char/agp/intel-gtt.c |3 +- drivers/gpu/drm/i915/i915_dma.c| 21 ++- drivers/gpu/drm/i915/i915_drv.c| 13 +++-- drivers/gpu/drm/i915/i915_drv.h| 23 - drivers/gpu/drm/i915/i915_gem.c| 37 ++- drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +- drivers/gpu/drm/i915/i915_gem_gtt.c|9 --- drivers/gpu/drm/i915/i915_reg.h|1 + drivers/gpu/drm/i915/intel_bios.c | 23 - drivers/gpu/drm/i915/intel_display.c | 37 +--- drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_ringbuffer.c|2 +- drivers/gpu/drm/i915/intel_sprite.c|3 ++ include/drm/intel-gtt.h|4 +++ 15 files changed, 152 insertions(+), 35 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix error return code in TN thermal setup
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index caa55d6..17571da 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -520,7 +520,7 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_SI:
/* No support for TN yet */
if (rdev->family == CHIP_ARUBA)
- return err;
+ return -ENOSYS;
rdev->pm.int_hwmon_dev = hwmon_device_register(rdev->dev);
if (IS_ERR(rdev->pm.int_hwmon_dev)) {
err = PTR_ERR(rdev->pm.int_hwmon_dev);
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: attempt to avoid copying data twice on coherent cards. (v2)
From: Dave Airlie
On coherent systems (not-AGP) the IB should be in cached memory so should
be just as fast, so we can avoid copying to temporary pages and just use it
directly.
provides minor speedups on rv530: gears ~1820->1860, ipers: 29.9->30.6,
but always good to use less CPU if we can.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_cs.c | 46 --
drivers/gpu/drm/radeon/radeon_drv.c |4 +++
3 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 138b952..5331b27 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -94,6 +94,7 @@ extern int radeon_disp_priority;
extern int radeon_hw_i2c;
extern int radeon_pcie_gen2;
extern int radeon_msi;
+extern int radeon_copy1;
/*
* Copy from radeon_drv.h so we don't have to include both and have conflicting
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 5cac832..1647be2 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,11 +278,16 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
void *data)
p->chunks[p->chunk_ib_idx].length_dw);
return -EINVAL;
}
- p->chunks[p->chunk_ib_idx].kpage[0] = kmalloc(PAGE_SIZE,
GFP_KERNEL);
- p->chunks[p->chunk_ib_idx].kpage[1] = kmalloc(PAGE_SIZE,
GFP_KERNEL);
- if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
- p->chunks[p->chunk_ib_idx].kpage[1] == NULL)
- return -ENOMEM;
+ if ((p->rdev->flags & RADEON_IS_AGP) || !radeon_copy1) {
+ p->chunks[p->chunk_ib_idx].kpage[0] =
kmalloc(PAGE_SIZE, GFP_KERNEL);
+ p->chunks[p->chunk_ib_idx].kpage[1] =
kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
+ p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {
+ kfree(p->chunks[i].kpage[0]);
+ kfree(p->chunks[i].kpage[1]);
+ return -ENOMEM;
+ }
+ }
p->chunks[p->chunk_ib_idx].kpage_idx[0] = -1;
p->chunks[p->chunk_ib_idx].kpage_idx[1] = -1;
p->chunks[p->chunk_ib_idx].last_copied_page = -1;
@@ -323,8 +328,10 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
kfree(parser->relocs_ptr);
for (i = 0; i < parser->nchunks; i++) {
kfree(parser->chunks[i].kdata);
- kfree(parser->chunks[i].kpage[0]);
- kfree(parser->chunks[i].kpage[1]);
+ if ((parser->rdev->flags & RADEON_IS_AGP) || !radeon_copy1) {
+ kfree(parser->chunks[i].kpage[0]);
+ kfree(parser->chunks[i].kpage[1]);
+ }
}
kfree(parser->chunks);
kfree(parser->chunks_array);
@@ -573,6 +580,8 @@ int radeon_cs_update_pages(struct radeon_cs_parser *p, int
pg_idx)
struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
int i;
int size = PAGE_SIZE;
+ void *ptr;
+ bool copy1 = (p->rdev->flags & RADEON_IS_AGP || !radeon_copy1) ? false
: true;
for (i = ibc->last_copied_page + 1; i < pg_idx; i++) {
if (DRM_COPY_FROM_USER(p->ib->ptr + (i * (PAGE_SIZE/4)),
@@ -583,23 +592,32 @@ int radeon_cs_update_pages(struct radeon_cs_parser *p,
int pg_idx)
}
}
- new_page = ibc->kpage_idx[0] < ibc->kpage_idx[1] ? 0 : 1;
-
if (pg_idx == ibc->last_page_index) {
size = (ibc->length_dw * 4) % PAGE_SIZE;
- if (size == 0)
- size = PAGE_SIZE;
+ if (size == 0)
+ size = PAGE_SIZE;
}
- if (DRM_COPY_FROM_USER(ibc->kpage[new_page],
+ if (!copy1) {
+ new_page = ibc->kpage_idx[0] < ibc->kpage_idx[1] ? 0 : 1;
+ ptr = ibc->kpage[new_page];
+ } else {
+ new_page = ibc->kpage_idx[0] < ibc->kpage_idx[1] ? 0 : 1;
+ ptr = p->ib->ptr + (pg_idx * (PAGE_SIZE / 4));
+ ibc->kpage[new_page] = ptr;
+ }
+
+ if (DRM_COPY_FROM_USER(ptr,
ibc->user_ptr + (pg_idx * PAGE_SIZE),
size)) {
p->parser_error = -EFAULT;
return 0;
}
- /* copy to IB here */
- memcpy((void *)(p->ib->ptr+(pg_idx*(PAGE_SIZE/4))),
ibc->kpage[new_page], size);
+ if (!copy1) {
+ /* copy to IB here */
+ memcpy((void *)(p->ib->ptr+(pg_idx*(PAGE_SIZE/4))),
ibc->kpage[new_pag
[git pull] drm intel fixes
Hi Linus, this pull just contains a forward of the Intel fixes from Daniel, The only annoyance is the RC6 enable, which really should have made -next, but since Ubuntu are shipping it I reckon its getting a good testing now by the time 3.4 comes out. The pull from Daniel contains his pull message to me, "A few patches for 3.4, major part is 3 regression fixes: - ppgtt broke hibernate on snb/ivb. Somehow our QA claims that it still works, which is why this has not been caught earlier. - ppgtt flails in combination with dmar. I kinda expected this one :( - fence handling bugfix for gen2/3. Iirc this one is about a year old, fix curtesy Chris Wilson. I've created an shockingly simple i-g-t test to catch this in the future. Wrt regressions I've just got a report that gmbus (newly enabled again in 3.4) is a bit noisy. I'm looking into this atm. Also included are the rc6 enable patches for snb from Eugeni. I wanted to include these in the main 3.4 pull but screwed it up. Please hit me. Imo these kind of patches really should go in before -rc1, but in thise case rc6 has brought us tons of press and guinea pigs^W^W testers and ubuntu is already running with it. So I estimate a pretty small chance for this to blow up. And some smaller things: - two minor locking snafus - server gt2 ivb pciid - 2 patches to sanitize the register state left behind by the bios some more - 2 new quirk entries - cs readback trick against missed IRQs from ivb also enabled on snb - sprite fix from Jesse" Dave. The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes-intel Anisse Astier (1): drm/i915: no-lvds quirk on MSI DC500 Chris Wilson (2): drm/i915: Sanitize BIOS debugging bits from PIPECONF drm/i915: Mark untiled BLT commands as fenced on gen2/3 Daniel Vetter (6): drm/i915: properly restore the ppgtt page directory on resume drm/i915: quirk away broken OpRegion VBT drm/i915: apply CS reg readback trick against missed IRQ on snb drm/i915: properly clear SSC1 bit in the pch refclock init code drm/i915: disable ppgtt on snb when dmar is enabled drm/i915: don't leak struct_mutex lock on ppgtt init failures Dave Airlie (1): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-intel-fixes Eugeni Dodonov (3): drm/i915: allow to select rc6 modes via kernel parameter drm/i915: enable plain RC6 on Sandy Bridge by default drm/i915: add Ivy Bridge GT2 Server entries Jesse Barnes (1): drm/i915: treat src w & h as fixed point in sprite handling code Sean Paul (1): drm/i915: Add lock on drm_helper_resume_force_mode drivers/char/agp/intel-agp.h |1 + drivers/char/agp/intel-gtt.c |3 +- drivers/gpu/drm/i915/i915_dma.c| 21 ++- drivers/gpu/drm/i915/i915_drv.c| 13 +++-- drivers/gpu/drm/i915/i915_drv.h| 23 - drivers/gpu/drm/i915/i915_gem.c| 37 ++- drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +- drivers/gpu/drm/i915/i915_gem_gtt.c|9 --- drivers/gpu/drm/i915/i915_reg.h|1 + drivers/gpu/drm/i915/intel_bios.c | 23 - drivers/gpu/drm/i915/intel_display.c | 37 +--- drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_ringbuffer.c|2 +- drivers/gpu/drm/i915/intel_sprite.c|3 ++ include/drm/intel-gtt.h|4 +++ 15 files changed, 152 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] vgaarb: Forward declaration of 'struct pci_dev'
Under a minimalist configuration, it is possible for i915 to include vgaarb.h without including any pci header before hand. Silence the compiler by providing an opaque forward declaration of 'struct pci_dev' In file included from drivers/gpu/drm/i915/intel_display.c:33:0: include/linux/vgaarb.h:66:9: warning: ‘struct pci_dev’ declared inside parameter list [enabled by default] include/linux/vgaarb.h:66:9: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/vgaarb.h:97:27: warning: ‘struct pci_dev’ declared inside parameter list [enabled by default] include/linux/vgaarb.h:109:6: warning: ‘struct pci_dev’ declared inside parameter list [enabled by default] include/linux/vgaarb.h: In function ‘vga_get_interruptible’: include/linux/vgaarb.h:111:8: warning: passing argument 1 of ‘vga_get’ from incompatible pointer type [enabled by default] include/linux/vgaarb.h:97:12: note: expected ‘struct pci_dev *’ but argument is of type ‘struct pci_dev *’ include/linux/vgaarb.h: At top level: include/linux/vgaarb.h:121:8: warning: ‘struct pci_dev’ declared inside parameter list [enabled by default] include/linux/vgaarb.h: In function ‘vga_get_uninterruptible’: include/linux/vgaarb.h:123:8: warning: passing argument 1 of ‘vga_get’ from incompatible pointer type [enabled by default] include/linux/vgaarb.h:97:12: note: expected ‘struct pci_dev *’ but argument is of type ‘struct pci_dev *’ include/linux/vgaarb.h: At top level: include/linux/vgaarb.h:138:30: warning: ‘struct pci_dev’ declared inside parameter list [enabled by default] include/linux/vgaarb.h:157:28: warning: ‘struct pci_dev’ declared inside parameter list [enabled by default] Signed-off-by: Chris Wilson --- include/linux/vgaarb.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index 9c3120d..ddfb941 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -31,6 +31,7 @@ #ifndef LINUX_VGA_H #define LINUX_VGA_H +struct pci_dev; /* Legacy VGA regions */ #define VGA_RSRC_NONE 0x00 -- 1.7.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup
https://bugzilla.kernel.org/show_bug.cgi?id=42678 --- Comment #11 from Torsten Kaiser 2012-04-03 19:38:37 --- > Is 3.4 still affected? I don't know, but I suspect it. Because since the fix of my underlying GPU hang in 3.3-rc3 there wasn't a need for a recovery or a change to hang X again. As I tried to explain in comment #8 there where 3 kernel bugs involved for me. 1.: a GPU lockup that happened since 3.1 and was fixed in 3.3-rc3 2.: a regression 3.2 -> 3.3-rc1 in the mutex locking, fixed in 3.3-rc2 3.: a regression 3.2 -> 3.3-rc1 that prevents X to recover from the GPU lockup. 3. was visible in 3.3-rc2 (see comment #3) as 2. was already fixed, but 1. was still happening. But after 3.3-rc3 1. has been fixed, so 3. no longer triggers for me, but I suspect that the GPU lockup recovery is still broken, because I did not see any patch that claimed to fix it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC] drm: support for rotated scanout
On Mon, Apr 2, 2012 at 1:39 PM, Ville Syrjälä
wrote:
> On Mon, Apr 02, 2012 at 08:26:14PM +0300, Ville Syrjälä wrote:
>> On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
>> > On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrjälä wrote:
>> > > On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
>> > >> From: Rob Clark
>> > >>
>> > >> For drivers that can support rotated scanout, the extra parameter
>> > >> checking in drm-core, while nice, tends to get confused. To solve
>> > >> this drivers can set the crtc or plane invert_dimensions field so
>> > >> that the dimension checking takes into account the rotation that
>> > >> the driver is performing.
>> > >> ---
>> > >> Note: RFC still mainly because I've only tested the CRTC rotation so
>> > >> far.. still need to write some test code for plane rotation.
>> > >>
>> > >> drivers/gpu/drm/drm_crtc.c | 50
>> > >> +--
>> > >> include/drm/drm_crtc.h | 9
>> > >> 2 files changed, 43 insertions(+), 16 deletions(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > >> index 0dff444..261c9bd 100644
>> > >> --- a/drivers/gpu/drm/drm_crtc.c
>> > >> +++ b/drivers/gpu/drm/drm_crtc.c
>> > >> @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct
>> > >> drm_crtc *crtc,
>> > >>
>> > >> crtc->dev = dev;
>> > >> crtc->funcs = funcs;
>> > >> + crtc->invert_dimensions = false;
>> > >>
>> > >> mutex_lock(&dev->mode_config.mutex);
>> > >>
>> > >> @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct
>> > >> drm_plane *plane,
>> > >> plane->base.properties = &plane->properties;
>> > >> plane->dev = dev;
>> > >> plane->funcs = funcs;
>> > >> + plane->invert_dimensions = false;
>> > >> plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
>> > >> GFP_KERNEL);
>> > >> if (!plane->format_types) {
>> > >> @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev,
>> > >> void *data,
>> > >> fb_width = fb->width << 16;
>> > >> fb_height = fb->height << 16;
>> > >>
>> > >> + if (plane->invert_dimensions)
>> > >> + swap(fb_width, fb_height);
>> > >> +
>> > >
>> > > In my opinion the only sane way to specify this stuff is that
>> > > the source coordinates are not transformed in any way.
>> >
>> > fwiw, it might be a bit odd that in one case I swapped fb dimensions,
>> > and in the other crtc dimensions.. although it was just laziness
>> > (there were fewer param's to swap that way ;-))
>>
>> Not sure if you got my point, which was that w/ plane rotation the
>> src coordinate check should be correct as is. Instead you should
>> apply the rotation when you clip/process the plane's crtc coordinates.
>>
>> Since we don't clip the crtc coordinates in the common code (to allow
>> partially/fully offscreen planes), all the work ends up happening in
>> driver specific code.
>
> What I write doesn't actually match what I meant to write. I didn't
> mean that you'd rotate the crtc coordinates prior to clipping.
> What I meant is that you (probably) rotate the src coordinates in
> the driver in order to do clipping and scaling factor calculations.
Do you mean that userspace should rotate/swap the src coordinates
before calling setplane ioctl? What I'm perhaps misunderstanding
about what you are getting too is that if the fb is created w/
unrotated coordinates (for ex, 1080x1920 instead of 1920x1080), and
you don't fix up the src coordinates somewhere (either userspace in
the core drm coordinate checking code), then you have a problem, and
the setplane never even reaches the driver's cb fxn.
The fb should of course not be created w/ bogus dimension, because you
might be scanning out one part with one crtc or plane non-rotated, and
other crtc/plane rotated.
> But in any case the bounds checking in the core code is OK, as the
> src coordinates are specified in the orienation of the fb memory
> layout.
Ok, that seems to sound like you are advocating doing the x/y swapping
in userspace for overlays.. which seems ok.
but, fwiw, if we did ever start checking the plane's dst coordinates
vs. the crtc, we would have to do the same w/h swap that we need to do
now for crtc.
BR,
-R
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix DVO setup on some r4xx chips
From: Alex Deucher
Some r4xx chips have the wrong frev in the
DVOEncoderControl table. It should always be 1
on r4xx. Fixes modesetting on DVO on r4xx chips
with the bad frev.
Reported by twied on #radeon.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index b88c460..5e1d0b5 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -230,6 +230,10 @@ atombios_dvo_setup(struct drm_encoder *encoder, int action)
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
return;
+ /* some R4xx chips have the wrong frev */
+ if (rdev->family <= CHIP_RV410)
+ frev = 1;
+
switch (frev) {
case 1:
switch (crev) {
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup
https://bugzilla.kernel.org/show_bug.cgi?id=42678 --- Comment #12 from Jérôme Glisse 2012-04-03 21:24:00 --- Well other things might have fixed it. I will force lockup but code inspection never leaded me to the issue. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8 v7] drm/i915/intel_i2c: handle zero-length writes
On Fri, 30 Mar 2012 19:46:36 +0800, Daniel Kurtz wrote: > A common method of probing an i2c bus is trying to do a zero-length write. > Handle this case by checking the length first before decrementing it. > > This is actually important, since attempting a zero-length write is one > of the ways that i2cdetect and i2c_new_probed_device detect whether > there is device present on the bus with a given address. > > Signed-off-by: Daniel Kurtz Having done a good job with handling zero length writes, can I tempt to submit a similar fix for zero length reads? ;) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: black screen on VGA w/ nouveau in Linux 3.3
CCing Tom Bylander as he sent me a mail off-list saying he experiences a similar issue on an FX 5200. Tom, maybe you'll have better luck bisecting this than I did? On 2012-03-19 10:35 -0400, Nick Bowler wrote: > Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output > on my card w/ nouveau is totally black (both at the console and in X). > Almost everything appears to work normally: DPMS works, modesetting > works, DDC works... all messages indicate that things are working -- > just the image is completely black. OK, so this is still reproducible on Linux 3.4-rc1+ (Linus' master). I captured the dmesg output before (3.2.13, which is a working kernel), and after (3.3.1 and 3.4-rc1-00144-g01627d9 - both fail in an identical manner). All three logs are attached in full (gzipped). One thing that immediately jumps out is the WARNING in the 3.4-rc1+ log that occurs early and did not appear in either of the other logs: [ cut here ] WARNING: at /home/nick/misc/linux-2.6/arch/x86/pci/i386.c:60 pcibios_fwaddrmap_lookup+0x1d/0x3d() Hardware name: K8N-E-Deluxe Modules linked in: Pid: 1, comm: swapper Not tainted 3.4.0-rc1-00144-g01627d9 #47 Call Trace: [] warn_slowpath_common+0x80/0x98 [] warn_slowpath_null+0x15/0x17 [] pcibios_fwaddrmap_lookup+0x1d/0x3d [] pcibios_allocate_resources+0xd4/0x217 [] ? pci_legacy_init+0x3e/0x3e [] pcibios_resource_survey+0x17/0x2d [] pcibios_init+0x28/0x3a [] pci_subsys_init+0x47/0x4d [] do_one_initcall+0x78/0x126 [] kernel_init+0xe9/0x17a [] ? rdinit_setup+0x28/0x28 [] kernel_thread_helper+0x4/0x10 [] ? start_kernel+0x321/0x321 [] ? gs_change+0xb/0xb ---[ end trace 4eaa2a86a8e2da22 ]--- Other than that, I diffed the 3.2.13 log and 3.4-rc1+ log and grepped for nouveau-related differences. I see no obvious errors, but I admit that I don't really know what to look for. % diff -u nouveau-3.2.13.log nouveau-3.4-rc1+.log | grep -C3 '\[drm\]' @@ -418,19 +429,21 @@ Real Time Clock Driver v1.12b Linux agpgart interface v0.103 [drm] Initialized drm 1.1.0 20060810 +VGA switcheroo: detected Optimus DSM method \ handle ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19 -nouveau :01:00.0: PCI INT A -> Link[LNKE] -> GSI 19 (level, low) -> IRQ 19 [drm] nouveau :01:00.0: Detected an NV30 generation card (0x436200a1) -[drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN +[drm] nouveau :01:00.0: Checking PRAMIN for VBIOS [drm] nouveau :01:00.0: ... appears to be valid +[drm] nouveau :01:00.0: Using VBIOS from PRAMIN [drm] nouveau :01:00.0: BMP BIOS found [drm] nouveau :01:00.0: BMP version 5.40 [drm] nouveau :01:00.0: Bios version 04.36.20.21 -[drm] nouveau :01:00.0: Found Display Configuration Block version 2.2 -[drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 9c40 -[drm] nouveau :01:00.0: Raw DCB entry 1: 02010310 9c40 -[drm] nouveau :01:00.0: Raw DCB entry 2: 04000302 -[drm] nouveau :01:00.0: Raw DCB entry 3: 02020321 0303 +[drm] nouveau :01:00.0: MXM: no VBIOS data, nothing to do +[drm] nouveau :01:00.0: DCB version 2.2 +[drm] nouveau :01:00.0: DCB outp 00: 01000300 9c40 +[drm] nouveau :01:00.0: DCB outp 01: 02010310 9c40 +[drm] nouveau :01:00.0: DCB outp 02: 04000302 +[drm] nouveau :01:00.0: DCB outp 03: 02020321 0303 [drm] nouveau :01:00.0: Loading NV17 power sequencing microcode [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xF01D [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xF4E1 @@ -439,11 +452,10 @@ [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xF8B3 [drm] nouveau :01:00.0: Parsing VBIOS init table 5 at offset 0xF8D0 [drm] nouveau :01:00.0: Parsing VBIOS init table 6 at offset 0xF959 -[drm] nouveau :01:00.0: 0 available performance level(s) -[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV -[TTM] Zone kernel: Available graphics memory: 512160 kiB. -[TTM] Initializing pool allocator. -[drm] nouveau :01:00.0: Detected 256MiB VRAM +[TTM] Zone kernel: Available graphics memory: 512142 kiB +[TTM] Initializing pool allocator +[TTM] Initializing DMA pool allocator +[drm] nouveau :01:00.0: Detected 256MiB VRAM (DDR1) agpgart-amd64 :00:00.0: AGP 3.0 bridge agpgart: swapper tried to set rate=x12. Setting to AGP3 x8 mode. agpgart-amd64 :00:00.0: putting AGP V3 device into 8x mode @@ -452,11 +464,14 @@ [drm] nouveau :01:00.0: Saving VGA fonts [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. +[drm] nouveau :01:00.0: 0 available performance level(s) +[drm] nouveau :01:00.0: c: core 425MHz memory 501MHz voltage 1350mV +[drm] nouveau :01:00.0: 0xE51A: Parsing digital output script table [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0) [drm] nouveau :01:00.0: Setting dpm
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #44 from Alexandre Demers 2012-04-03 19:24:36 PDT --- Just to let you know I've moved from Ubuntu to Arch. This week, kernel 3.0 came in and the problem is obviously appearing as expected. Still locks up, still hangs, still fails to resume: [ 1454.142346] radeon :01:00.0: offset 0x10 is in reserved area 0x80 [ 1454.142955] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x10 [ 1454.142959] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [ 1454.155602] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x10 [ 1454.155606] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [ 1465.203216] radeon :01:00.0: GPU lockup CP stall for more than 10030msec [ 1465.203220] GPU lockup (waiting for 0x0001E557 last fence id 0x0001E554) [ 1465.418088] radeon :01:00.0: GPU softreset [ 1465.418092] radeon :01:00.0: GRBM_STATUS=0xF5700828 [ 1465.418094] radeon :01:00.0: GRBM_STATUS_SE0=0xFC01 [ 1465.418096] radeon :01:00.0: GRBM_STATUS_SE1=0xFC01 [ 1465.418098] radeon :01:00.0: SRBM_STATUS=0x20020FC0 [ 1465.418101] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_ADDR 0x000779DD [ 1465.418103] radeon :01:00.0: VM_CONTEXT0_PROTECTION_FAULT_STATUS 0x00072001 [ 1465.418105] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x05B9 [ 1465.418108] radeon :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x020A400C [ 1465.579826] radeon :01:00.0: Wait for MC idle timedout ! [ 1465.579828] radeon :01:00.0: GRBM_SOFT_RESET=0xDF7B [ 1465.579936] radeon :01:00.0: GRBM_STATUS=0x80103828 [ 1465.579938] radeon :01:00.0: GRBM_STATUS_SE0=0x0407 [ 1465.579940] radeon :01:00.0: GRBM_STATUS_SE1=0x0407 [ 1465.579941] radeon :01:00.0: SRBM_STATUS=0x20020FC0 [ 1465.580943] radeon :01:00.0: GPU reset succeed [ 1465.771511] radeon :01:00.0: Wait for MC idle timedout ! [ 1465.942884] radeon :01:00.0: Wait for MC idle timedout ! [ 1465.944796] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 1465.944872] radeon :01:00.0: WB enabled [ 1465.944874] [drm] fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88021ea01c00 [ 1465.944876] [drm] fence driver on ring 1 use gpu addr 0x4c04 and cpu addr 0x88021ea01c04 [ 1465.944878] [drm] fence driver on ring 2 use gpu addr 0x4c08 and cpu addr 0x88021ea01c08 [ 1466.140829] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8500)=0xCAFEDEAD) [ 1466.140831] [drm:cayman_resume] *ERROR* cayman startup failed on resume I'll be testing kernel 3.4-rc1 soon and I'll play with 2D tiling. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH] drm/i915: enable semaphores on gen6 if dmar is not active
On Mon, Apr 02, 2012 at 02:44:14PM -0700, Andrew Lutomirski wrote: > On Mon, Apr 2, 2012 at 1:52 PM, Daniel Vetter wrote: > > On Mon, Apr 02, 2012 at 01:45:39PM -0700, Andrew Lutomirski wrote: > >> On Mon, Apr 2, 2012 at 11:48 AM, Daniel Vetter > >> wrote: > >> > Inspired by the recent ppgtt regression report, where switching of > >> > dmar only for the gpu seems to fix things completely, I've looked > >> > again at the semaphores+vt-d situation. > >> > > >> > Contrary to my earlier testing a few months back my system is now > >> > stable with dmar disabled for the igd, and not only when disabling > >> > dmar completely. > >> > > >> > So I'm rather hopeful that all our recent fixes for snb have changed > >> > things for code and it's time to try enabling semaphores again. We've > >> > also had issues with enabling semaphores which are not vt-d related, > >> > but I guess these are all fixed by the autoreport-disabling and lazy > >> > request fix. And there's only one way to find out whether there are > >> > still other issues ... > >> > > >> > Signed-Off-by: Daniel Vetter > >> > > >> > --- > >> > > >> > If no further vt-d regressions show up in the 3.4 cycle I plan to > >> > merge this into -next for 3.5 (in a month or so). Comments about how > >> > unfeasibly you deem this highly welcome. > >> > -Daniel > >> > --- > >> > ?drivers/gpu/drm/i915/i915_gem_execbuffer.c | ? ?8 +--- > >> > ?1 files changed, 5 insertions(+), 3 deletions(-) > >> > > >> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >> > index 8e0b686..ac52433 100644 > >> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c > >> > @@ -849,9 +849,11 @@ intel_enable_semaphores(struct drm_device *dev) > >> > ? ? ? ?if (i915_semaphores >= 0) > >> > ? ? ? ? ? ? ? ?return i915_semaphores; > >> > > >> > - ? ? ? /* Disable semaphores on SNB */ > >> > - ? ? ? if (INTEL_INFO(dev)->gen == 6) > >> > - ? ? ? ? ? ? ? return 0; > >> > +#ifdef CONFIG_INTEL_IOMMU > >> > + ? ? ? /* Disable semaphores on SNB if VT-d is on. */ > >> > + ? ? ? if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) > >> > + ? ? ? ? ? ? ? return false; > >> > >> It might be nice to have a printk here giving instructions for how to work > >> around this. ?For example: > >> > >> i915: Disabling semaphores to work around a DMAR issue. ?As an > >> alternative, boot with intel_iommu=igfx_off [or on, igfx_off, or > >> whatever it's supposed to be]. > >> > >> The documentation in kernel-parameters.txt is at best unclear to the > >> uninitiated. > > > > If this really does work, I'll look into this. Atm it's still unclear > > where to exactly put the plain, we need to annoy internal hardware people > > to analyze this. Once we have enough evidence that the combination of gpu > > with various features enable plus VT-d just doesn't seem to work reliably. > > > > So can you check whether things do indeed work with this patch, atop > > kernel 3.4-rc1? Iirc you've been the one with the most trouble when > > semaphores are enabled ... > > I've had a hard time reproducing the problems lately. The > unconditional instant hard hang went away a few months ago, I think. > I'll give it another shot when I get home to that machine. Well, I've managed to kill my machine shortly after login with semaphores, rc6 and dmar enabled. It hasn't died in the same configuration after a few hours of light usage (in my case that seems to be the best killer) with dmar disabled for just the gpu. So if you can give your machine some serious beating with the different options, that's really great. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
2.6.35-rc4 Graphics performance issue and freeing invalid memtype messages on boot.
Hi, Jerome Glisse just helpfully pointed out that I'm running with KMS disabled (and indeed, CONFIG_DRM_RADEON_KMS is not set). So we have: - a CONFIG_DRM_RADEON_KMS which has some pretty strong wording discouraging its use (which IIRC is exactly the reason that I decided to not enable it yet at that time when KMS stuff has been introduced) - with KMS thus ending up disabled, things failing left and right... Something's not quite right... I'm currently doing a (complete, unfortunately) rebuild to retry with CONFIG_DRM_RADEON_KMS enabled, will report back. Andreas Mohr
[PATCH 3.3-rc3] drm/i915: Fixes distorted external screen image on HP 2730p
On Mon, Feb 13, 2012 at 09:38:33AM +0100, Daniel Vetter wrote: > On Sun, Feb 12, 2012 at 11:10:32AM +0100, phil at haerkules.de wrote: > > From: Philipp Grete > > > > Fixes LP: #796030 by removing forced pipe A on HP 2730p. > > Quirk has previously been introduced to fix a sleep mode problem that does > > not exist any more. > > > > Signed-off-by: Philipp Grete > > --- > > Fix has been confirmed by at least three people (see > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030) who didn't > > experience any sleep mode problems after applying the patch. > > Can you please supply the corresponding tested-bys for these three people? > I.e. add > > Tested-by: Name > > to the sob part of your commit message. Also please add a reference to the > LP as a full link (easier to handle for people outside of the ubuntu > universe): > > Bugzilla: http://launchpad/direct/link/to/bug Ping. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH 3.3-rc3] drm/i915: Fixes distorted external screen image on HP 2730p
On Tue, Apr 3, 2012 at 10:48, Daniel Vetter wrote: > On Mon, Feb 13, 2012 at 09:38:33AM +0100, Daniel Vetter wrote: >> On Sun, Feb 12, 2012 at 11:10:32AM +0100, phil at haerkules.de wrote: >> > From: Philipp Grete >> > >> > Fixes LP: #796030 by removing forced pipe A on HP 2730p. >> > Quirk has previously been introduced to fix a sleep mode problem that does >> > not exist any more. >> > >> > Signed-off-by: Philipp Grete >> > --- >> > Fix has been confirmed by at least three people (see >> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030) who didn't >> > experience any sleep mode problems after applying the patch. >> >> Can you please supply the corresponding tested-bys for these three people? >> I.e. add >> >> Tested-by: Name >> >> to the sob part of your commit message. Also please add a reference to the >> LP as a full link (easier to handle for people outside of the ubuntu >> universe): >> >> Bugzilla: http://launchpad/direct/link/to/bug > > Ping. Disregard that ping, I've noticed that I've already picked this up. Cheers, Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[git pull] drm fixes
Hi Linus, mainly nouveau fixes, one for a regressions in -rc1, fixes for booting on a ppc G5, and a Kconfig fix. two radeon fix, one oops, one s/r fix. one udl mmap fix. and one core drm fix to stop bad fbdev apps overwriting bits of ram. I have some fixes from Intel I think on the way, but I'm offline until post-Easter from tomorrow, so maybe you'll see them maybe you won't :) Dave. The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: fix fans after resume Ben Skeggs (3): drm/nouveau: oops, create m2mf for nvd9 too Revert "drm/nouveau: inform userspace of new kernel subchannel requirements" drm/nouveau: inform userspace of relaxed kernel subchannel requirements Benjamin Herrenschmidt (2): nouveau: Fix crash when pci_ram_rom() returns a size of 0 nouveau/bios: Fix tracking of BIOS image data Chris Wilson (1): drm: Validate requested virtual size against allocated fb size Dave Airlie (2): Merge branch 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes drm/nouveau: select POWER_SUPPLY Konstantin Khlebnikov (1): mm, drm/udl: fixup vma flags on mmap Michel D?nzer (1): drm/radeon: Don't dereference possibly-NULL pointer. drivers/gpu/drm/drm_fb_helper.c |8 ++-- drivers/gpu/drm/nouveau/Kconfig |1 + drivers/gpu/drm/nouveau/nouveau_bios.c|9 ++--- drivers/gpu/drm/nouveau/nouveau_channel.c | 10 +- drivers/gpu/drm/nouveau/nouveau_dma.h |4 ++-- drivers/gpu/drm/nouveau/nouveau_state.c |2 +- drivers/gpu/drm/radeon/atom.c | 15 ++- drivers/gpu/drm/radeon/atom.h |1 + drivers/gpu/drm/radeon/radeon_object.c|3 ++- drivers/gpu/drm/udl/udl_drv.c |2 +- drivers/gpu/drm/udl/udl_drv.h |1 + drivers/gpu/drm/udl/udl_gem.c | 14 ++ 12 files changed, 54 insertions(+), 16 deletions(-)
[PATCH] drm/prime: expose capability flags for userspace.
On Mon, 2 Apr 2012 14:11:50 +0100, Dave Airlie wrote: > From: Dave Airlie > > This lets the kernel tell userspace if the device supports prime > import/export. > > This is useful for -modesetting at least, but would be nice for other > drivers. > > Signed-off-by: Dave Airlie Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
Process to merge Openchrome work
> > ? ? ? ?This last year the Openchrome support for the VIA chipsets has > come along way from being in a state of decay. The plan is to release > a Xorg driver June 1 that will have support for the KMS as well as UMS. > The goal is to have this xorg driver out in the wild before the kernel > side is ready so that the migration to the new kernel drivers will be > as painless as possible. My hope is to merge the kernel tree for public > use for Christmas. > ? ? ? ?This brings up the question I had with the other project leader. > How does one go about merging the tree? What makes this more complex is > that a old via drm kernel driver already exist. Do we just drop in the > code into the staging area? Does it have to be piece meal? Does a rename > of the driver need to happen? What would you recommend ? So what we've done before to avoid regression is a) add a new CONFIG_ option that is default n, so users don't get a regression, b) enable the KMS bits and PCI binding depending on the new option. Now the easiest way may be to make a new driver with a new name, make it bind to PCI devices etc, and just have CONFIG to turn it on/off. It depends on how much code the new driver shares with the old etc. So older distros can share the older code. Then you'd have to generate decent reviewable patches of the codebase and send them to dri-devel, where others could review them. The main thing review looks out for is that the userspace interfaces are sane and secure. I don't generally take git merges until people have built up a bit of trust sending decent patches, and making sure reviews are done. The other question is what to people lose if they switch to VIA KMS in terms of acceleration, is the 2D/3D Xorg/Mesa driver work at the same level as the old driver? does anyone care? Dave.
[PATCH] drm/radeon: enable pci bus mastering after card is initialised
From: Dave Airlie
This closes a race seen with kexec where we enable PCI bus mastering
but the card has been reinitialised fully yet.
This was previously fixed by a patch from Jerome, but this should
close the race completely.
Reported-and-tested-by: Markus Trippelsdorf
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/r100.c |4
drivers/gpu/drm/radeon/r600.c |3 +++
drivers/gpu/drm/radeon/radeon_device.c |1 -
drivers/gpu/drm/radeon/radeon_kms.c|2 --
4 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 81801c1..e11df77 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1180,6 +1180,10 @@ int r100_cp_init(struct radeon_device *rdev, unsigned
ring_size)
WREG32(RADEON_CP_RB_WPTR_DELAY, 0);
WREG32(RADEON_CP_CSQ_MODE, 0x4D4D);
WREG32(RADEON_CP_CSQ_CNTL, RADEON_CSQ_PRIBM_INDBM);
+
+ /* at this point everything should be setup correctly to enable master
*/
+ pci_set_master(rdev->pdev);
+
radeon_ring_start(rdev, RADEON_RING_TYPE_GFX_INDEX,
&rdev->ring[RADEON_RING_TYPE_GFX_INDEX]);
r = radeon_ring_test(rdev, RADEON_RING_TYPE_GFX_INDEX, ring);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 5eb2382..50cf034 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3034,6 +3034,9 @@ int r600_irq_init(struct radeon_device *rdev)
else
r600_disable_interrupt_state(rdev);
+ /* at this point everything should be setup correctly to enable master
*/
+ pci_set_master(rdev->pdev);
+
/* enable irqs */
r600_enable_interrupts(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 49f7cb7..a282331 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -951,7 +951,6 @@ int radeon_resume_kms(struct drm_device *dev)
console_unlock();
return -1;
}
- pci_set_master(dev->pdev);
/* resume AGP if in use */
radeon_agp_resume(rdev);
radeon_resume(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 1986eba..d335288 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned
long flags)
}
dev->dev_private = (void *)rdev;
- pci_set_master(dev->pdev);
-
/* update BUS flag */
if (drm_pci_device_is_agp(dev)) {
flags |= RADEON_IS_AGP;
--
1.7.7.6
[PATCH] drm/radeon: enable pci bus mastering after card is initialised
On Tue, Apr 3, 2012 at 8:13 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This closes a race seen with kexec where we enable PCI bus mastering
> but the card has been reinitialised fully yet.
>
> This was previously fixed by a patch from Jerome, but this should
> close the race completely.
>
> Reported-and-tested-by: Markus Trippelsdorf
> Signed-off-by: Dave Airlie
For 3.4, you'll need to update si.c as well.
Alex
> ---
> ?drivers/gpu/drm/radeon/r100.c ? ? ? ? ?| ? ?4
> ?drivers/gpu/drm/radeon/r600.c ? ? ? ? ?| ? ?3 +++
> ?drivers/gpu/drm/radeon/radeon_device.c | ? ?1 -
> ?drivers/gpu/drm/radeon/radeon_kms.c ? ?| ? ?2 --
> ?4 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 81801c1..e11df77 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -1180,6 +1180,10 @@ int r100_cp_init(struct radeon_device *rdev, unsigned
> ring_size)
> ? ? ? ?WREG32(RADEON_CP_RB_WPTR_DELAY, 0);
> ? ? ? ?WREG32(RADEON_CP_CSQ_MODE, 0x4D4D);
> ? ? ? ?WREG32(RADEON_CP_CSQ_CNTL, RADEON_CSQ_PRIBM_INDBM);
> +
> + ? ? ? /* at this point everything should be setup correctly to enable
> master */
> + ? ? ? pci_set_master(rdev->pdev);
> +
> ? ? ? ?radeon_ring_start(rdev, RADEON_RING_TYPE_GFX_INDEX,
> &rdev->ring[RADEON_RING_TYPE_GFX_INDEX]);
> ? ? ? ?r = radeon_ring_test(rdev, RADEON_RING_TYPE_GFX_INDEX, ring);
> ? ? ? ?if (r) {
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 5eb2382..50cf034 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3034,6 +3034,9 @@ int r600_irq_init(struct radeon_device *rdev)
> ? ? ? ?else
> ? ? ? ? ? ? ? ?r600_disable_interrupt_state(rdev);
>
> + ? ? ? /* at this point everything should be setup correctly to enable
> master */
> + ? ? ? pci_set_master(rdev->pdev);
> +
> ? ? ? ?/* enable irqs */
> ? ? ? ?r600_enable_interrupts(rdev);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 49f7cb7..a282331 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -951,7 +951,6 @@ int radeon_resume_kms(struct drm_device *dev)
> ? ? ? ? ? ? ? ?console_unlock();
> ? ? ? ? ? ? ? ?return -1;
> ? ? ? ?}
> - ? ? ? pci_set_master(dev->pdev);
> ? ? ? ?/* resume AGP if in use */
> ? ? ? ?radeon_agp_resume(rdev);
> ? ? ? ?radeon_resume(rdev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 1986eba..d335288 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -57,8 +57,6 @@ int radeon_driver_load_kms(struct drm_device *dev, unsigned
> long flags)
> ? ? ? ?}
> ? ? ? ?dev->dev_private = (void *)rdev;
>
> - ? ? ? pci_set_master(dev->pdev);
> -
> ? ? ? ?/* update BUS flag */
> ? ? ? ?if (drm_pci_device_is_agp(dev)) {
> ? ? ? ? ? ? ? ?flags |= RADEON_IS_AGP;
> --
> 1.7.7.6
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] updated exynos-drm-fixes
this patch set fixes page align and duplicated allocation issues and removes unnecessary codes for code clean. this patch set is based on git repository below: git://people.freedesktop.org/~airlied/linux.git drm-fixes commit-id: 62fb376e214d3c1bfdf6fbb77dac162f6da04d7e Please let me know if there is any problem. Thanks, Inki Dae Inki Dae (2): drm/exynos: fixed page align and code clean. drm/exynos: fixed duplicated page allocation bug. drivers/gpu/drm/exynos/exynos_drm_buf.c | 47 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 45 +++-- drivers/gpu/drm/exynos/exynos_drm_gem.h |2 + include/drm/exynos_drm.h|3 +- 4 files changed, 54 insertions(+), 43 deletions(-) -- 1.7.4.1
[PATCH 1/2] drm/exynos: fixed page align and code clean.
1M section, 64k page count also should be rounded up so this patch
rounds up them and caculates page count of them properly and also
checks memory flags from user.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 13 +++-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 45 --
drivers/gpu/drm/exynos/exynos_drm_gem.h |2 +
include/drm/exynos_drm.h|3 +-
4 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 4a3a5f7..52d42cd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -41,7 +41,7 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (flags & EXYNOS_BO_NONCONTIG) {
+ if (IS_NONCONTIG_BUFFER(flags)) {
DRM_DEBUG_KMS("not support allocation type.\n");
return -EINVAL;
}
@@ -52,13 +52,13 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
}
if (buf->size >= SZ_1M) {
- npages = (buf->size >> SECTION_SHIFT) + 1;
+ npages = buf->size >> SECTION_SHIFT;
page_size = SECTION_SIZE;
} else if (buf->size >= SZ_64K) {
- npages = (buf->size >> 16) + 1;
+ npages = buf->size >> 16;
page_size = SZ_64K;
} else {
- npages = (buf->size >> PAGE_SHIFT) + 1;
+ npages = buf->size >> PAGE_SHIFT;
page_size = PAGE_SIZE;
}
@@ -119,9 +119,6 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
buf->pages[i] = phys_to_page(start_addr);
- sgl = sg_next(sgl);
- sg_set_page(sgl, buf->pages[i+1], end_addr - start_addr, 0);
-
DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->kvaddr,
(unsigned long)buf->dma_addr,
@@ -150,7 +147,7 @@ static void lowlevel_buffer_deallocate(struct drm_device
*dev,
* non-continuous memory would be released by exynos
* gem framework.
*/
- if (flags & EXYNOS_BO_NONCONTIG) {
+ if (IS_NONCONTIG_BUFFER(flags)) {
DRM_DEBUG_KMS("not support allocation type.\n");
return;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index fa1aa94..26d5197 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -56,9 +56,28 @@ static unsigned int convert_to_vm_err_msg(int msg)
return out_msg;
}
-static unsigned int mask_gem_flags(unsigned int flags)
+static int check_gem_flags(unsigned int flags)
{
- return flags &= EXYNOS_BO_NONCONTIG;
+ if (flags & ~(EXYNOS_BO_MASK)) {
+ DRM_ERROR("invalid flags.\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static unsigned long roundup_gem_size(unsigned long size, unsigned int flags)
+{
+ if (!IS_NONCONTIG_BUFFER(flags)) {
+ if (size >= SZ_1M)
+ return roundup(size, SECTION_SIZE);
+ else if (size >= SZ_64K)
+ return roundup(size, SZ_64K);
+ else
+ goto out;
+ }
+out:
+ return roundup(size, PAGE_SIZE);
}
static struct page **exynos_gem_get_pages(struct drm_gem_object *obj,
@@ -319,10 +338,17 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
struct exynos_drm_gem_buf *buf;
int ret;
- size = roundup(size, PAGE_SIZE);
- DRM_DEBUG_KMS("%s: size = 0x%lx\n", __FILE__, size);
+ if (!size) {
+ DRM_ERROR("invalid size.\n");
+ return ERR_PTR(-EINVAL);
+ }
- flags = mask_gem_flags(flags);
+ size = roundup_gem_size(size, flags);
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ ret = check_gem_flags(flags);
+ if (ret)
+ return ERR_PTR(ret);
buf = exynos_drm_init_buf(dev, size);
if (!buf)
@@ -331,7 +357,7 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
exynos_gem_obj = exynos_drm_gem_init(dev, size);
if (!exynos_gem_obj) {
ret = -ENOMEM;
- goto err;
+ goto err_fini_buf;
}
exynos_gem_obj->buffer = buf;
@@ -347,18 +373,19 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct
drm_device *dev,
ret = exynos_drm_gem_get_pages(&exynos_gem_obj->base);
if (ret < 0) {
drm_gem_object_release(&exynos_gem_obj->base);
- goto err;
+ goto err_fini_buf;
}
} else {
ret = exynos_drm_alloc_buf(dev, buf, flags);
[PATCH 2/2] drm/exynos: fixed duplicated page allocation bug.
this patch fixes that buf->pages is allocated two times when it allocates
physically continuous memory region and removes unnecessary codes
for code clean.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_buf.c | 34 --
1 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 52d42cd..de8d209 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -34,7 +34,7 @@
static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
{
- dma_addr_t start_addr, end_addr;
+ dma_addr_t start_addr;
unsigned int npages, page_size, i = 0;
struct scatterlist *sgl;
int ret = 0;
@@ -76,26 +76,13 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
return -ENOMEM;
}
- buf->kvaddr = dma_alloc_writecombine(dev->dev, buf->size,
- &buf->dma_addr, GFP_KERNEL);
- if (!buf->kvaddr) {
- DRM_ERROR("failed to allocate buffer.\n");
- ret = -ENOMEM;
- goto err1;
- }
-
- start_addr = buf->dma_addr;
- end_addr = buf->dma_addr + buf->size;
-
- buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
- if (!buf->pages) {
- DRM_ERROR("failed to allocate pages.\n");
- ret = -ENOMEM;
- goto err2;
- }
-
- start_addr = buf->dma_addr;
- end_addr = buf->dma_addr + buf->size;
+ buf->kvaddr = dma_alloc_writecombine(dev->dev, buf->size,
+ &buf->dma_addr, GFP_KERNEL);
+ if (!buf->kvaddr) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
buf->pages = kzalloc(sizeof(struct page) * npages, GFP_KERNEL);
if (!buf->pages) {
@@ -105,20 +92,17 @@ static int lowlevel_buffer_allocate(struct drm_device *dev,
}
sgl = buf->sgt->sgl;
+ start_addr = buf->dma_addr;
while (i < npages) {
buf->pages[i] = phys_to_page(start_addr);
sg_set_page(sgl, buf->pages[i], page_size, 0);
sg_dma_address(sgl) = start_addr;
start_addr += page_size;
- if (end_addr - start_addr < page_size)
- break;
sgl = sg_next(sgl);
i++;
}
- buf->pages[i] = phys_to_page(start_addr);
-
DRM_DEBUG_KMS("vaddr(0x%lx), dma_addr(0x%lx), size(0x%lx)\n",
(unsigned long)buf->kvaddr,
(unsigned long)buf->dma_addr,
--
1.7.4.1
[pull] drm-intel-fixes for 3.4
Hi Dave, A few patches for 3.4, major part is 3 regression fixes: - ppgtt broke hibernate on snb/ivb. Somehow our QA claims that it still works, which is why this has not been caught earlier. - ppgtt flails in combination with dmar. I kinda expected this one :( - fence handling bugfix for gen2/3. Iirc this one is about a year old, fix curtesy Chris Wilson. I've created an shockingly simple i-g-t test to catch this in the future. Wrt regressions I've just got a report that gmbus (newly enabled again in 3.4) is a bit noisy. I'm looking into this atm. Also included are the rc6 enable patches for snb from Eugeni. I wanted to include these in the main 3.4 pull but screwed it up. Please hit me. Imo these kind of patches really should go in before -rc1, but in thise case rc6 has brought us tons of press and guinea pigs^W^W testers and ubuntu is already running with it. So I estimate a pretty small chance for this to blow up. And some smaller things: - two minor locking snafus - server gt2 ivb pciid - 2 patches to sanitize the register state left behind by the bios some more - 2 new quirk entries - cs readback trick against missed IRQs from ivb also enabled on snb - sprite fix from Jesse Yours, Daniel The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to b4db1e35ac59c144965f517bc575a0d75b60b03f: drm/i915: treat src w & h as fixed point in sprite handling code (2012-04-03 11:33:33 +0200) Anisse Astier (1): drm/i915: no-lvds quirk on MSI DC500 Chris Wilson (2): drm/i915: Sanitize BIOS debugging bits from PIPECONF drm/i915: Mark untiled BLT commands as fenced on gen2/3 Daniel Vetter (6): drm/i915: properly restore the ppgtt page directory on resume drm/i915: quirk away broken OpRegion VBT drm/i915: apply CS reg readback trick against missed IRQ on snb drm/i915: properly clear SSC1 bit in the pch refclock init code drm/i915: disable ppgtt on snb when dmar is enabled drm/i915: don't leak struct_mutex lock on ppgtt init failures Eugeni Dodonov (3): drm/i915: allow to select rc6 modes via kernel parameter drm/i915: enable plain RC6 on Sandy Bridge by default drm/i915: add Ivy Bridge GT2 Server entries Jesse Barnes (1): drm/i915: treat src w & h as fixed point in sprite handling code Sean Paul (1): drm/i915: Add lock on drm_helper_resume_force_mode drivers/char/agp/intel-agp.h |1 + drivers/char/agp/intel-gtt.c |3 +- drivers/gpu/drm/i915/i915_dma.c| 21 ++- drivers/gpu/drm/i915/i915_drv.c| 13 +++-- drivers/gpu/drm/i915/i915_drv.h| 23 - drivers/gpu/drm/i915/i915_gem.c| 37 ++- drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +- drivers/gpu/drm/i915/i915_gem_gtt.c|9 --- drivers/gpu/drm/i915/i915_reg.h|1 + drivers/gpu/drm/i915/intel_bios.c | 23 - drivers/gpu/drm/i915/intel_display.c | 37 +--- drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_ringbuffer.c|2 +- drivers/gpu/drm/i915/intel_sprite.c|3 ++ include/drm/intel-gtt.h|4 +++ 15 files changed, 152 insertions(+), 35 deletions(-) -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm/radeon: fix error return code in TN thermal setup
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index caa55d6..17571da 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -520,7 +520,7 @@ static int radeon_hwmon_init(struct radeon_device *rdev)
case THERMAL_TYPE_SI:
/* No support for TN yet */
if (rdev->family == CHIP_ARUBA)
- return err;
+ return -ENOSYS;
rdev->pm.int_hwmon_dev = hwmon_device_register(rdev->dev);
if (IS_ERR(rdev->pm.int_hwmon_dev)) {
err = PTR_ERR(rdev->pm.int_hwmon_dev);
--
1.7.7.5
[PATCH] drm/radeon/kms: attempt to avoid copying data twice on coherent cards. (v2)
From: Dave Airlie
On coherent systems (not-AGP) the IB should be in cached memory so should
be just as fast, so we can avoid copying to temporary pages and just use it
directly.
provides minor speedups on rv530: gears ~1820->1860, ipers: 29.9->30.6,
but always good to use less CPU if we can.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h |1 +
drivers/gpu/drm/radeon/radeon_cs.c | 46 --
drivers/gpu/drm/radeon/radeon_drv.c |4 +++
3 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 138b952..5331b27 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -94,6 +94,7 @@ extern int radeon_disp_priority;
extern int radeon_hw_i2c;
extern int radeon_pcie_gen2;
extern int radeon_msi;
+extern int radeon_copy1;
/*
* Copy from radeon_drv.h so we don't have to include both and have conflicting
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 5cac832..1647be2 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -278,11 +278,16 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p,
void *data)
p->chunks[p->chunk_ib_idx].length_dw);
return -EINVAL;
}
- p->chunks[p->chunk_ib_idx].kpage[0] = kmalloc(PAGE_SIZE,
GFP_KERNEL);
- p->chunks[p->chunk_ib_idx].kpage[1] = kmalloc(PAGE_SIZE,
GFP_KERNEL);
- if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
- p->chunks[p->chunk_ib_idx].kpage[1] == NULL)
- return -ENOMEM;
+ if ((p->rdev->flags & RADEON_IS_AGP) || !radeon_copy1) {
+ p->chunks[p->chunk_ib_idx].kpage[0] =
kmalloc(PAGE_SIZE, GFP_KERNEL);
+ p->chunks[p->chunk_ib_idx].kpage[1] =
kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (p->chunks[p->chunk_ib_idx].kpage[0] == NULL ||
+ p->chunks[p->chunk_ib_idx].kpage[1] == NULL) {
+ kfree(p->chunks[i].kpage[0]);
+ kfree(p->chunks[i].kpage[1]);
+ return -ENOMEM;
+ }
+ }
p->chunks[p->chunk_ib_idx].kpage_idx[0] = -1;
p->chunks[p->chunk_ib_idx].kpage_idx[1] = -1;
p->chunks[p->chunk_ib_idx].last_copied_page = -1;
@@ -323,8 +328,10 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error)
kfree(parser->relocs_ptr);
for (i = 0; i < parser->nchunks; i++) {
kfree(parser->chunks[i].kdata);
- kfree(parser->chunks[i].kpage[0]);
- kfree(parser->chunks[i].kpage[1]);
+ if ((parser->rdev->flags & RADEON_IS_AGP) || !radeon_copy1) {
+ kfree(parser->chunks[i].kpage[0]);
+ kfree(parser->chunks[i].kpage[1]);
+ }
}
kfree(parser->chunks);
kfree(parser->chunks_array);
@@ -573,6 +580,8 @@ int radeon_cs_update_pages(struct radeon_cs_parser *p, int
pg_idx)
struct radeon_cs_chunk *ibc = &p->chunks[p->chunk_ib_idx];
int i;
int size = PAGE_SIZE;
+ void *ptr;
+ bool copy1 = (p->rdev->flags & RADEON_IS_AGP || !radeon_copy1) ? false
: true;
for (i = ibc->last_copied_page + 1; i < pg_idx; i++) {
if (DRM_COPY_FROM_USER(p->ib->ptr + (i * (PAGE_SIZE/4)),
@@ -583,23 +592,32 @@ int radeon_cs_update_pages(struct radeon_cs_parser *p,
int pg_idx)
}
}
- new_page = ibc->kpage_idx[0] < ibc->kpage_idx[1] ? 0 : 1;
-
if (pg_idx == ibc->last_page_index) {
size = (ibc->length_dw * 4) % PAGE_SIZE;
- if (size == 0)
- size = PAGE_SIZE;
+ if (size == 0)
+ size = PAGE_SIZE;
}
- if (DRM_COPY_FROM_USER(ibc->kpage[new_page],
+ if (!copy1) {
+ new_page = ibc->kpage_idx[0] < ibc->kpage_idx[1] ? 0 : 1;
+ ptr = ibc->kpage[new_page];
+ } else {
+ new_page = ibc->kpage_idx[0] < ibc->kpage_idx[1] ? 0 : 1;
+ ptr = p->ib->ptr + (pg_idx * (PAGE_SIZE / 4));
+ ibc->kpage[new_page] = ptr;
+ }
+
+ if (DRM_COPY_FROM_USER(ptr,
ibc->user_ptr + (pg_idx * PAGE_SIZE),
size)) {
p->parser_error = -EFAULT;
return 0;
}
- /* copy to IB here */
- memcpy((void *)(p->ib->ptr+(pg_idx*(PAGE_SIZE/4))),
ibc->kpage[new_page], size);
+ if (!copy1) {
+ /* copy to IB here */
+ memcpy((void *)(p->ib->ptr+(pg_idx*(PAGE_SIZE/4))),
ibc->kpage[new_page], s
[git pull] drm intel fixes
Hi Linus, this pull just contains a forward of the Intel fixes from Daniel, The only annoyance is the RC6 enable, which really should have made -next, but since Ubuntu are shipping it I reckon its getting a good testing now by the time 3.4 comes out. The pull from Daniel contains his pull message to me, "A few patches for 3.4, major part is 3 regression fixes: - ppgtt broke hibernate on snb/ivb. Somehow our QA claims that it still works, which is why this has not been caught earlier. - ppgtt flails in combination with dmar. I kinda expected this one :( - fence handling bugfix for gen2/3. Iirc this one is about a year old, fix curtesy Chris Wilson. I've created an shockingly simple i-g-t test to catch this in the future. Wrt regressions I've just got a report that gmbus (newly enabled again in 3.4) is a bit noisy. I'm looking into this atm. Also included are the rc6 enable patches for snb from Eugeni. I wanted to include these in the main 3.4 pull but screwed it up. Please hit me. Imo these kind of patches really should go in before -rc1, but in thise case rc6 has brought us tons of press and guinea pigs^W^W testers and ubuntu is already running with it. So I estimate a pretty small chance for this to blow up. And some smaller things: - two minor locking snafus - server gt2 ivb pciid - 2 patches to sanitize the register state left behind by the bios some more - 2 new quirk entries - cs readback trick against missed IRQs from ivb also enabled on snb - sprite fix from Jesse" Dave. The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928: Linux 3.4-rc1 (2012-03-31 16:24:09 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes-intel Anisse Astier (1): drm/i915: no-lvds quirk on MSI DC500 Chris Wilson (2): drm/i915: Sanitize BIOS debugging bits from PIPECONF drm/i915: Mark untiled BLT commands as fenced on gen2/3 Daniel Vetter (6): drm/i915: properly restore the ppgtt page directory on resume drm/i915: quirk away broken OpRegion VBT drm/i915: apply CS reg readback trick against missed IRQ on snb drm/i915: properly clear SSC1 bit in the pch refclock init code drm/i915: disable ppgtt on snb when dmar is enabled drm/i915: don't leak struct_mutex lock on ppgtt init failures Dave Airlie (1): Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-intel-fixes Eugeni Dodonov (3): drm/i915: allow to select rc6 modes via kernel parameter drm/i915: enable plain RC6 on Sandy Bridge by default drm/i915: add Ivy Bridge GT2 Server entries Jesse Barnes (1): drm/i915: treat src w & h as fixed point in sprite handling code Sean Paul (1): drm/i915: Add lock on drm_helper_resume_force_mode drivers/char/agp/intel-agp.h |1 + drivers/char/agp/intel-gtt.c |3 +- drivers/gpu/drm/i915/i915_dma.c| 21 ++- drivers/gpu/drm/i915/i915_drv.c| 13 +++-- drivers/gpu/drm/i915/i915_drv.h| 23 - drivers/gpu/drm/i915/i915_gem.c| 37 ++- drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +- drivers/gpu/drm/i915/i915_gem_gtt.c|9 --- drivers/gpu/drm/i915/i915_reg.h|1 + drivers/gpu/drm/i915/intel_bios.c | 23 - drivers/gpu/drm/i915/intel_display.c | 37 +--- drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_ringbuffer.c|2 +- drivers/gpu/drm/i915/intel_sprite.c|3 ++ include/drm/intel-gtt.h|4 +++ 15 files changed, 152 insertions(+), 35 deletions(-)
[PATCH] vgaarb: Forward declaration of 'struct pci_dev'
Under a minimalist configuration, it is possible for i915 to include vgaarb.h without including any pci header before hand. Silence the compiler by providing an opaque forward declaration of 'struct pci_dev' In file included from drivers/gpu/drm/i915/intel_display.c:33:0: include/linux/vgaarb.h:66:9: warning: ?struct pci_dev? declared inside parameter list [enabled by default] include/linux/vgaarb.h:66:9: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] include/linux/vgaarb.h:97:27: warning: ?struct pci_dev? declared inside parameter list [enabled by default] include/linux/vgaarb.h:109:6: warning: ?struct pci_dev? declared inside parameter list [enabled by default] include/linux/vgaarb.h: In function ?vga_get_interruptible?: include/linux/vgaarb.h:111:8: warning: passing argument 1 of ?vga_get? from incompatible pointer type [enabled by default] include/linux/vgaarb.h:97:12: note: expected ?struct pci_dev *? but argument is of type ?struct pci_dev *? include/linux/vgaarb.h: At top level: include/linux/vgaarb.h:121:8: warning: ?struct pci_dev? declared inside parameter list [enabled by default] include/linux/vgaarb.h: In function ?vga_get_uninterruptible?: include/linux/vgaarb.h:123:8: warning: passing argument 1 of ?vga_get? from incompatible pointer type [enabled by default] include/linux/vgaarb.h:97:12: note: expected ?struct pci_dev *? but argument is of type ?struct pci_dev *? include/linux/vgaarb.h: At top level: include/linux/vgaarb.h:138:30: warning: ?struct pci_dev? declared inside parameter list [enabled by default] include/linux/vgaarb.h:157:28: warning: ?struct pci_dev? declared inside parameter list [enabled by default] Signed-off-by: Chris Wilson --- include/linux/vgaarb.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index 9c3120d..ddfb941 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -31,6 +31,7 @@ #ifndef LINUX_VGA_H #define LINUX_VGA_H +struct pci_dev; /* Legacy VGA regions */ #define VGA_RSRC_NONE 0x00 -- 1.7.9.1
[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup
https://bugzilla.kernel.org/show_bug.cgi?id=42678 --- Comment #11 from Torsten Kaiser 2012-04-03 19:38:37 --- > Is 3.4 still affected? I don't know, but I suspect it. Because since the fix of my underlying GPU hang in 3.3-rc3 there wasn't a need for a recovery or a change to hang X again. As I tried to explain in comment #8 there where 3 kernel bugs involved for me. 1.: a GPU lockup that happened since 3.1 and was fixed in 3.3-rc3 2.: a regression 3.2 -> 3.3-rc1 in the mutex locking, fixed in 3.3-rc2 3.: a regression 3.2 -> 3.3-rc1 that prevents X to recover from the GPU lockup. 3. was visible in 3.3-rc2 (see comment #3) as 2. was already fixed, but 1. was still happening. But after 3.3-rc3 1. has been fixed, so 3. no longer triggers for me, but I suspect that the GPU lockup recovery is still broken, because I did not see any patch that claimed to fix it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH RFC] drm: support for rotated scanout
On Mon, Apr 2, 2012 at 1:39 PM, Ville Syrj?l?
wrote:
> On Mon, Apr 02, 2012 at 08:26:14PM +0300, Ville Syrj?l? wrote:
>> On Mon, Apr 02, 2012 at 10:31:47AM -0500, Rob Clark wrote:
>> > On Sat, Mar 31, 2012 at 4:09 PM, Ville Syrj?l? wrote:
>> > > On Fri, Mar 30, 2012 at 05:59:32PM -0500, Rob Clark wrote:
>> > >> From: Rob Clark
>> > >>
>> > >> For drivers that can support rotated scanout, the extra parameter
>> > >> checking in drm-core, while nice, tends to get confused. ?To solve
>> > >> this drivers can set the crtc or plane invert_dimensions field so
>> > >> that the dimension checking takes into account the rotation that
>> > >> the driver is performing.
>> > >> ---
>> > >> Note: RFC still mainly because I've only tested the CRTC rotation so
>> > >> far.. still need to write some test code for plane rotation.
>> > >>
>> > >> ?drivers/gpu/drm/drm_crtc.c | ? 50
>> > >> +--
>> > >> ?include/drm/drm_crtc.h ? ? | ? ?9
>> > >> ?2 files changed, 43 insertions(+), 16 deletions(-)
>> > >>
>> > >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > >> index 0dff444..261c9bd 100644
>> > >> --- a/drivers/gpu/drm/drm_crtc.c
>> > >> +++ b/drivers/gpu/drm/drm_crtc.c
>> > >> @@ -375,6 +375,7 @@ int drm_crtc_init(struct drm_device *dev, struct
>> > >> drm_crtc *crtc,
>> > >>
>> > >> ? ? ? crtc->dev = dev;
>> > >> ? ? ? crtc->funcs = funcs;
>> > >> + ? ? crtc->invert_dimensions = false;
>> > >>
>> > >> ? ? ? mutex_lock(&dev->mode_config.mutex);
>> > >>
>> > >> @@ -609,6 +610,7 @@ int drm_plane_init(struct drm_device *dev, struct
>> > >> drm_plane *plane,
>> > >> ? ? ? plane->base.properties = &plane->properties;
>> > >> ? ? ? plane->dev = dev;
>> > >> ? ? ? plane->funcs = funcs;
>> > >> + ? ? plane->invert_dimensions = false;
>> > >> ? ? ? plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
>> > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL);
>> > >> ? ? ? if (!plane->format_types) {
>> > >> @@ -1758,6 +1760,9 @@ int drm_mode_setplane(struct drm_device *dev,
>> > >> void *data,
>> > >> ? ? ? fb_width = fb->width << 16;
>> > >> ? ? ? fb_height = fb->height << 16;
>> > >>
>> > >> + ? ? if (plane->invert_dimensions)
>> > >> + ? ? ? ? ? ? swap(fb_width, fb_height);
>> > >> +
>> > >
>> > > In my opinion the only sane way to specify this stuff is that
>> > > the source coordinates are not transformed in any way.
>> >
>> > fwiw, it might be a bit odd that in one case I swapped fb dimensions,
>> > and in the other crtc dimensions.. ?although it was just laziness
>> > (there were fewer param's to swap that way ;-))
>>
>> Not sure if you got my point, which was that w/ plane rotation the
>> src coordinate check should be correct as is. Instead you should
>> apply the rotation when you clip/process the plane's crtc coordinates.
>>
>> Since we don't clip the crtc coordinates in the common code (to allow
>> partially/fully offscreen planes), all the work ends up happening in
>> driver specific code.
>
> What I write doesn't actually match what I meant to write. I didn't
> mean that you'd rotate the crtc coordinates prior to clipping.
> What I meant is that you (probably) rotate the src coordinates in
> the driver in order to do clipping and scaling factor calculations.
Do you mean that userspace should rotate/swap the src coordinates
before calling setplane ioctl? What I'm perhaps misunderstanding
about what you are getting too is that if the fb is created w/
unrotated coordinates (for ex, 1080x1920 instead of 1920x1080), and
you don't fix up the src coordinates somewhere (either userspace in
the core drm coordinate checking code), then you have a problem, and
the setplane never even reaches the driver's cb fxn.
The fb should of course not be created w/ bogus dimension, because you
might be scanning out one part with one crtc or plane non-rotated, and
other crtc/plane rotated.
> But in any case the bounds checking in the core code is OK, as the
> src coordinates are specified in the orienation of the fb memory
> layout.
Ok, that seems to sound like you are advocating doing the x/y swapping
in userspace for overlays.. which seems ok.
but, fwiw, if we did ever start checking the plane's dst coordinates
vs. the crtc, we would have to do the same w/h swap that we need to do
now for crtc.
BR,
-R
> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix DVO setup on some r4xx chips
From: Alex Deucher
Some r4xx chips have the wrong frev in the
DVOEncoderControl table. It should always be 1
on r4xx. Fixes modesetting on DVO on r4xx chips
with the bad frev.
Reported by twied on #radeon.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index b88c460..5e1d0b5 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -230,6 +230,10 @@ atombios_dvo_setup(struct drm_encoder *encoder, int action)
if (!atom_parse_cmd_header(rdev->mode_info.atom_context, index, &frev,
&crev))
return;
+ /* some R4xx chips have the wrong frev */
+ if (rdev->family <= CHIP_RV410)
+ frev = 1;
+
switch (frev) {
case 1:
switch (crev) {
--
1.7.7.5
[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup
https://bugzilla.kernel.org/show_bug.cgi?id=42678 --- Comment #12 from J?r?me Glisse 2012-04-03 21:24:00 --- Well other things might have fixed it. I will force lockup but code inspection never leaded me to the issue. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/8 v7] drm/i915/intel_i2c: handle zero-length writes
On Fri, 30 Mar 2012 19:46:36 +0800, Daniel Kurtz wrote: > A common method of probing an i2c bus is trying to do a zero-length write. > Handle this case by checking the length first before decrementing it. > > This is actually important, since attempting a zero-length write is one > of the ways that i2cdetect and i2c_new_probed_device detect whether > there is device present on the bus with a given address. > > Signed-off-by: Daniel Kurtz Having done a good job with handling zero length writes, can I tempt to submit a similar fix for zero length reads? ;) -Chris -- Chris Wilson, Intel Open Source Technology Centre
Regression: black screen on VGA w/ nouveau in Linux 3.3
r (output 0) [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 1) [drm] nouveau :01:00.0: Setting dpms mode 3 on tmds encoder (output 2) [drm] nouveau :01:00.0: Setting dpms mode 3 on TV encoder (output 3) -[drm] nouveau :01:00.0: allocated 1280x1024 fb: 0x49000, bo 88003da11400 +[drm] nouveau :01:00.0: allocated 1280x1024 fb: 0x49000, bo 88003e314c00 fbcon: nouveaufb (fb0) is primary device [drm] nouveau :01:00.0: 0xE51A: Parsing digital output script table [drm] nouveau :01:00.0: Setting dpms mode 0 on tmds encoder (output 2) @@ -466,12 +481,11 @@ Console: switching to colour frame buffer device 160x64 fb0: nouveaufb frame buffer device drm: registered panic notifier -[drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 +[drm] Initialized nouveau 1.0.0 20120316 for :01:00.0 on minor 0 brd: module loaded sata_nv :00:0a.0: version 3.5 ACPI: PCI Interrupt Link [LTID] BIOS reported IRQ 0, using IRQ 22 -- +NFS: Registering the id_resolver key type it87: Found IT8712F chip at 0xd00, revision 7 it87: VID is disabled (pins used for GPIO) [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 1) > The VGA is one of two outputs in use: the other (DVI) output works > normally. The card also has an unused TV-out port, FWIW. > > The card is an NV36 generation (Geforce FX5700 AGP). This is a > regression from Linux 3.2 -- unfortunately, bisection has proved > extremely difficult because the intermediate kernels git is asking me > to test panic immediately on boot (and compiling Linux takes a fairly > long time on this box too). The failed attempt went like this: > > git bisect start 'drivers/gpu' > # bad: [c16fa4f2ad19908a47c63d8fa436a1178438c7e7] Linux 3.3 > git bisect bad c16fa4f2ad19908a47c63d8fa436a1178438c7e7 > # good: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2 > git bisect good 805a6af8dba5dfdd35ec35dc52ec0122400b2610 > # skip: [5d56fe5fd794a98c4f446f8665fd06b82e93ff64] Merge branch > 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 > into drm-core-next > git bisect skip 5d56fe5fd794a98c4f446f8665fd06b82e93ff64 > # good: [dffc9ceb55695f121adc57dd1fde7304c3afe81e] gma500: kill virtual > mapping support > git bisect good dffc9ceb55695f121adc57dd1fde7304c3afe81e > # skip: [5c2a5ce689c99037771a6c110374461781a6f042] drm: add missing exports > for i810 driver. > git bisect skip 5c2a5ce689c99037771a6c110374461781a6f042 > # skip: [44517c44496062180a6376cc704b33129441ce60] drm/radeon/kms: Add an > MSI quirk for Dell RS690 > git bisect skip 44517c44496062180a6376cc704b33129441ce60 > > (I stopped at this point) > > I'm running the latest git xf86-video-nouveau, but since the issue > occurs at the console it's probably not too important... Please let me know if you need any more info, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- next part -- A non-text attachment was scrubbed... Name: nouveau-3.2.13.log.gz Type: application/octet-stream Size: 10448 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120403/88cf954a/attachment-0003.obj> -- next part -- A non-text attachment was scrubbed... Name: nouveau-3.3.1.log.gz Type: application/octet-stream Size: 10298 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120403/88cf954a/attachment-0004.obj> -- next part -- A non-text attachment was scrubbed... Name: nouveau-3.4-rc1+.log.gz Type: application/octet-stream Size: 10747 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120403/88cf954a/attachment-0005.obj>
