Re: Bug in warning message from MTRR rework in uvesafb
On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
wrote:
> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
> MTRR code" contains the following change:
>
> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
> }
> }
>
> +if (mtrr != 3 && mtrr != 1)
> +pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is
> unsupported", mtrr);
> +
> return 0;
> }
> #endif /* !MODULE */
>
> Shouldn't this be && mtrr != 0?
Indeed, and Sylvain Hitier (cc'd) sent a patch (off-list) that must
have gotten lost somewhere.
--Andy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] DRM: use anon_inode instead of delayed inode init
On Thu, Jul 11, 2013 at 01:45:30AM +0200, David Herrmann wrote:
> Instead of delaying inode initialization until first ->open(), we can use
> an anonymous inode. This avoids modifying FS internal inode fields and
> provides us a private address_space right during initialization.
>
> Delayed TTM dev_mapping initialization is currently left untouched to keep
> this simple. But we could now safely provide the address_space during
> ttm_bo_device_init() instead of delaying until first buffer ->mmap().
>
> Note that this also fixes several bugs:
> - We currently call iput(container_of(..dev_mapping..)) before
>drm_lastclose(), but we reset dev_mapping to zero at the end of
>drm_lastclose(). This fails if dev_mapping points to an address_space
>other than the current inode and the char-dev got already removed.
> - We also drop dev_mapping during any drm_lastclose() call. So if
>user-space still has VMAs to our buffers, we will be unable to unmap
>them if the next ->firstopen() is on another inode. dev_mapping will
>then point to a new address_space and we leak mappings that we no
>longer control.
It's certainly ugly, but I don't think we have a real problem here. vma
grabs a reference to the open file at mmap time and we grab a reference to
the underlying gem object. So it shouldn't be possible to observe a
non-NULL dev_mapping while the inode refcount has already reached 0
anywhere we actually care. At least in drm/i915 since we never call
unmap_mapping_range if we know that there's no ptes around pointing at
this specific object (which we accurately keep track of in our fault
handler).
TTM might be different, and it's certainly good to rid us of this code.
> - We ignore inode->i_mapping completely. It is unlikely that a FS uses it
>to overwrite inode->i_data for char-devs, but it definitely doesn't
>look very nice to ignore it silently.
Tbh I have no idea what the rules are here ... But since core vfs code
uses the filp->f_mapping at mmap time not frobbing inode->i_mapping looks
like the sane to do.
> Regarding legacy drivers: We no longer reset the address_space during
> drm_lastclose() to avoid re-allocating inodes all the time. However,
> legacy UMS drivers are weird and it is not clear to me whether some of the
> old drivers might depend on this (for what reason?), but I remember Daniel
> told me that i810 might.
i915 in gem+ums mode might. i810 is a different level of horror show
entirely, but since it doesn't do gem we can ignore it here.
>
> Tested with nouveau on x86_64.
>
> Signed-off-by: David Herrmann
Reviewed-by: Daniel Vetter
I guess it makes sense to merge that after your drm vma offset manager
changes with the little pte shootdown helper since that'll reduce the
diff?
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 1 -
> drivers/gpu/drm/drm_fops.c | 24 +++-
> drivers/gpu/drm/drm_stub.c | 12 +++-
> drivers/gpu/drm/i915/i915_gem.c| 4 ++--
> drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_gem.c | 7 ---
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 +-
> include/drm/drmP.h | 2 +-
> 12 files changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99fcd7c..9797613 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
> !drm_core_check_feature(dev, DRIVER_MODESET))
> drm_dma_takedown(dev);
>
> - dev->dev_mapping = NULL;
> mutex_unlock(&dev->struct_mutex);
>
> DRM_DEBUG("lastclose completed\n");
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 3a24385..6752f59 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
> struct drm_minor *minor;
> int retcode = 0;
> int need_setup = 0;
> - struct address_space *old_mapping;
> - struct address_space *old_imapping;
>
> minor = idr_find(&drm_minors_idr, minor_id);
> if (!minor)
> @@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)
>
> if (!dev->open_count++)
> need_setup = 1;
> - mutex_lock(&dev->struct_mutex);
> - old_imapping = inode->i_mapping;
> - old_mapping = dev->dev_mapping;
> - if (old_mapping == NULL)
> - dev->dev_mapping = &inode->i_data;
> - /* ihold ensures nobody can remove inode with our i_data */
> - ihold(container_of(dev->dev_mapping, struct inode, i_data));
> - inode->i_mapping = dev->dev_mapping;
> - filp->f_map
Re: Bug in warning message from MTRR rework in uvesafb
On Thu, Jul 11, 2013 at 3:36 AM, Andy Lutomirski wrote:
> On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
> wrote:
>> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
>> MTRR code" contains the following change:
>>
>> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
>> }
>> }
>>
>> +if (mtrr != 3 && mtrr != 1)
>> +pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is
>> unsupported", mtrr);
>> +
>> return 0;
>> }
>> #endif /* !MODULE */
>>
>> Shouldn't this be && mtrr != 0?
>
> Indeed, and Sylvain Hitier (cc'd) sent a patch (off-list) that must
> have gotten lost somewhere.
>
Yeah I should get an email reply thing for off-list stuff, as its even
more likely I'll lose it.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: don't call ->firstopen for KMS drivers
Hi Daniel,
On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces the complexity of the drm core -> driver interface a
> notch.
>
> v2: Don't forget to update DocBook.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 2 ++
> drivers/gpu/drm/drm_fops.c | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..0e8a5a3 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
> The firstopen method is called by the DRM
> core when an application opens a device that has no other opened file
> handle.
> + Not that this callback is only called for legacy ums drm drivers, not
> + for drm drivers that implement modesetting in the kernel.
> Similarly the lastclose method is called when
> the last application holding a file handle opened on the device closes
> it. Both methods are mostly used for UMS (User Mode Setting) drivers to
What about
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d1278e..afa8d40 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file
*);
The firstopen method is called by the DRM core
- when an application opens a device that has no other opened file handle.
- Similarly the lastclose method is called when
- the last application holding a file handle opened on the device closes
- it. Both methods are mostly used for UMS (User Mode Setting) drivers to
- acquire and release device resources which should be done in the
- load and unload
- methods for KMS drivers.
+ for legacy UMS (User Mode Setting) drivers only when an application
+ opens a device that has no other opened file handle. UMS drivers can
+ implement it to acquire device resources. KMS drivers can't use the
+ method and must acquire resources in the load
+ method instead.
-Note that the lastclose method is also called
- at module unload time or, for hot-pluggable devices, when the device is
- unplugged. The firstopen and
+ Similarly the lastclose method is called when
+ the last application holding a file handle opened on the device closes
+ it, for both UMS and KMS drivers. Additionally, the method is also
+ called at module unload time or, for hot-pluggable devices, when the
+ device is unplugged. The firstopen and
lastclose calls can thus be unbalanced.
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 57e3014..fcde7d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
> int i;
> int ret;
>
> - if (dev->driver->firstopen) {
> + if (dev->driver->firstopen &&
> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
> ret = dev->driver->firstopen(dev);
> if (ret != 0)
> return ret;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/prime: remove cargo-cult locking from map_sg helper
Hi Daniel,
Thanks for the patch.
On Wednesday 10 July 2013 16:48:45 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
>
> Only the grabbing of the underlying page array is anything we need to
> be concerned about, and either those pages are pinned independently,
> or we're screwed no matter what.
>
> And indeed, nouveau/radeon pin the backing storage in their
> attach/detach functions.
>
> Since I've created this patch cma prime support for dma_buf was added.
> drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
> the sg table with dma_get_sgtable. It doesn't touch any gem object
> state otherwise. So the cma helpers also look safe.
>
> The only thing we might claim it does is prevent concurrent mapping of
> dma_buf attachments. But a) that's not allowed and b) the current code
> is racy already since it checks whether the sg mapping exists _before_
> grabbing the lock.
>
> So the dev->struct_mutex locking here does absolutely nothing useful,
> but only distracts. Remove it.
>
> This should also help Maarten's work to eventually pin the backing
> storage more dynamically by preventing locking inversions around
> dev->struct_mutex.
>
> v2: Add analysis for recently added cma helper prime code.
>
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_prime.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 85e450e..64a99b3 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -167,8 +167,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach, if (WARN_ON(prime_attach->dir != DMA_NONE))
> return ERR_PTR(-EBUSY);
>
> - mutex_lock(&obj->dev->struct_mutex);
> -
> sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
>
> if (!IS_ERR(sgt)) {
> @@ -182,7 +180,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach, }
> }
>
> - mutex_unlock(&obj->dev->struct_mutex);
> return sgt;
> }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66805] [radeonsi] half life 2 base games are segfaulting
https://bugs.freedesktop.org/show_bug.cgi?id=66805 --- Comment #1 from Michel Dänzer --- Can you provide the output from running with the environment variable RADEON_DUMP_SHADERS=1 ? Beware that it might be large if the game compiles many shaders before the failure. -- 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
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 Christian König changed: What|Removed |Added Attachment #81770|0 |1 is obsolete|| Attachment #82190|0 |1 is obsolete|| Attachment #82194|0 |1 is obsolete|| Attachment #82196|0 |1 is obsolete|| Attachment #82198|0 |1 is obsolete|| Attachment #82226|0 |1 is obsolete|| Attachment #82304|0 |1 is obsolete|| --- Comment #20 from Christian König --- Created attachment 82325 --> https://bugs.freedesktop.org/attachment.cgi?id=82325&action=edit Possible fix. I was able to reproduce the problem, and this patch (only a slightly modified version of the old one) seems to fix it for me. Please retest and provide new dmesg logs (as far as that is possible). Also please try it a couple of times, cause at least on my test system suspend/resume on 3.10 seems to be a bit unstable (even without the radeon driver). -- 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
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 --- Comment #21 from Austin Lund --- (In reply to comment #20) > Created attachment 82325 [details] [review] > Possible fix. > > I was able to reproduce the problem, and this patch (only a slightly > modified version of the old one) seems to fix it for me. > > Please retest and provide new dmesg logs (as far as that is possible). > > Also please try it a couple of times, cause at least on my test system > suspend/resume on 3.10 seems to be a bit unstable (even without the radeon > driver). I got this compile warning: /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function ‘radeon_uvd_fini’: /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning: ‘return’ with a value, in function returning void [enabled by default] return 0; ^ Haven't had a chance to test just yet. Will report back as soon as possible. -- 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
[Bug 66805] [radeonsi] half life 2 base games are segfaulting
https://bugs.freedesktop.org/show_bug.cgi?id=66805 --- Comment #2 from Laurent carlier --- Created attachment 82327 --> https://bugs.freedesktop.org/attachment.cgi?id=82327&action=edit shader dump from portal with RADEON_DUMP_SHADERS=1 -- 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
[PATCH 1/2] drm/gem: simplify object initialization
drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.
Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.
Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.
Cc: Patrik Jakobsson
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 20
drivers/gpu/drm/gma500/framebuffer.c | 6 ++
drivers/gpu/drm/gma500/gem.c | 7 ---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
include/drm/drmP.h | 4 ++--
7 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 603f256..1ad9e7e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
- BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+ struct file *filp;
- obj->dev = dev;
- obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
- if (IS_ERR(obj->filp))
- return PTR_ERR(obj->filp);
+ filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
+ if (IS_ERR(filp))
+ return PTR_ERR(filp);
- kref_init(&obj->refcount);
- atomic_set(&obj->handle_count, 0);
- obj->size = size;
+ drm_gem_private_object_init(dev, obj, size);
+ obj->filp = filp;
return 0;
}
@@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
* no GEM provided backing store. Instead the caller is responsible for
* backing the object and handling it.
*/
-int drm_gem_private_object_init(struct drm_device *dev,
- struct drm_gem_object *obj, size_t size)
+void drm_gem_private_object_init(struct drm_device *dev,
+struct drm_gem_object *obj, size_t size)
{
BUG_ON((size & (PAGE_SIZE - 1)) != 0);
@@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
kref_init(&obj->refcount);
atomic_set(&obj->handle_count, 0);
obj->size = size;
-
- return 0;
}
EXPORT_SYMBOL(drm_gem_private_object_init);
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 8b1b6d9..362dd2a 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
*dev, int aligned_size)
/* Begin by trying to use stolen memory backing */
backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
if (backing) {
- if (drm_gem_private_object_init(dev,
- &backing->gem, aligned_size) == 0)
- return backing;
- psb_gtt_free_range(dev, backing);
+ drm_gem_private_object_init(dev, &backing->gem, aligned_size);
+ return backing;
}
return NULL;
}
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index eefd6cc..fe1d332 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
struct drm_device *dev,
struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
if (gtt == NULL)
return -ENOMEM;
- if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
- goto free_gtt;
+
+ drm_gem_private_object_init(dev, >t->gem, size);
if (drm_gem_handle_create(file, >t->gem, handle) == 0)
return 0;
-free_gtt:
+
+ drm_gem_object_release(>t->gem);
psb_gtt_free_range(dev, gtt);
return -ENOMEM;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..f2e185c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
goto fail_detach;
}
- ret = drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
- if (ret) {
- i915_gem_object_free(obj);
- goto fail_detach;
- }
-
+ drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops);
obj->base.import_attach
[PATCH 2/2] drm/pci: remove useles #if 1
These don't make any sense, really..
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 80c0b2b..a7b46ff 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -52,10 +52,8 @@
drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t
align)
{
drm_dma_handle_t *dmah;
-#if 1
unsigned long addr;
size_t sz;
-#endif
/* pci_alloc_consistent only guarantees alignment to the smallest
* PAGE_SIZE order which is greater than or equal to the requested size.
@@ -97,10 +95,8 @@ EXPORT_SYMBOL(drm_pci_alloc);
*/
void __drm_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
{
-#if 1
unsigned long addr;
size_t sz;
-#endif
if (dmah->vaddr) {
/* XXX - Is virt_to_page() legal for consistent mem? */
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66731] texture issues in xonotic with llvm+sb and offset mapping
https://bugs.freedesktop.org/show_bug.cgi?id=66731 --- Comment #2 from Stefano Teso --- Thanks for the quick response. I just wanted to note that the glitch is still there with llvm 3.4 trunk. -- 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
Re: [PATCH] drm: don't call ->firstopen for KMS drivers
On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
>> It has way too much potential for driver writers to do stupid things
>> like delayed hw setup because the load sequence is somehow racy (e.g.
>> the imx driver in staging). So don't call it for modesetting drivers,
>> which reduces the complexity of the drm core -> driver interface a
>> notch.
>>
>> v2: Don't forget to update DocBook.
>>
>> Cc: Laurent Pinchart
>> Signed-off-by: Daniel Vetter
>> ---
>> Documentation/DocBook/drm.tmpl | 2 ++
>> drivers/gpu/drm/drm_fops.c | 3 ++-
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 4d54ac8..0e8a5a3 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
>> drm_file *);
>> The firstopen method is called by the DRM
>> core when an application opens a device that has no other opened file
>> handle.
>> + Not that this callback is only called for legacy ums drm drivers, not
>> + for drm drivers that implement modesetting in the kernel.
>> Similarly the lastclose method is called when
>> the last application holding a file handle opened on the device closes
>> it. Both methods are mostly used for UMS (User Mode Setting) drivers to
>
> What about
So if you think we should go overboard I guess it'd be useful to
explain what KMS drivers should and shouldn't do in lastclose:
- Delayed gpu switching with vga switcheroo.
- Restoring of the fbcon, as long as the core is still a bit deficient
in getting rid of mouse cursors and stupid sprite setups when X dies
untimely and leaves dirt behind. Eventually we should be able to get
rid of this though and rely on the magic sysrq to get out of graphics
mode and restore fbcon fully.
- Nothing else, ever, especially resource cleanups.
Can you maybe add a sentence or two to your proposed update for about
this? UMS drivers tend to do a lot of nefarious stuff in lastclose, so
stressing the difference would be good.
Otherwise I like your doc update much more than mine ;-)
-Daniel
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7d1278e..afa8d40 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
>
>
> The firstopen method is called by the DRM
> core
> - when an application opens a device that has no other opened file
> handle.
> - Similarly the lastclose method is called when
> - the last application holding a file handle opened on the device closes
> - it. Both methods are mostly used for UMS (User Mode Setting) drivers
> to
> - acquire and release device resources which should be done in the
> - load and unload
> - methods for KMS drivers.
> + for legacy UMS (User Mode Setting) drivers only when an application
> + opens a device that has no other opened file handle. UMS drivers can
> + implement it to acquire device resources. KMS drivers can't use the
> + method and must acquire resources in the load
> + method instead.
>
>
> -Note that the lastclose method is also
> called
> - at module unload time or, for hot-pluggable devices, when the device
> is
> - unplugged. The firstopen and
> + Similarly the lastclose method is called when
> + the last application holding a file handle opened on the device closes
> + it, for both UMS and KMS drivers. Additionally, the method is also
> + called at module unload time or, for hot-pluggable devices, when the
> + device is unplugged. The firstopen and
> lastclose calls can thus be unbalanced.
>
>
>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 57e3014..fcde7d4 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>> int i;
>> int ret;
>>
>> - if (dev->driver->firstopen) {
>> + if (dev->driver->firstopen &&
>> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>> ret = dev->driver->firstopen(dev);
>> if (ret != 0)
>> return ret;
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote: > drm_gem_object_init() and drm_gem_private_object_init() do exactly the > same (except for shmem alloc) so make the first use the latter to reduce > code duplication. > > Also drop the return code from drm_gem_private_object_init(). It seems > unlikely that we will extend it any time soon so no reason to keep it > around. This simplifies code paths in drivers, too. > > Last but not least, fix gma500 to call drm_gem_object_release() before > freeing objects that were allocated via drm_gem_private_object_init(). > That isn't actually necessary for now, but might be in the future. > > Cc: Patrik Jakobsson > Signed-off-by: David Herrmann You should also CC any driver maintainers that the patch touches. They should be acking it at the very least. -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: [PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
Generally commmit messages that have too many "also do foo" paragraphs
tack on scream for a patch split up ;-) But the diff here is little enough
that it's imo still ok. So for both patches in this series:
Reviewed-by: Daniel Vetter
>
> Cc: Patrik Jakobsson
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 20
> drivers/gpu/drm/gma500/framebuffer.c | 6 ++
> drivers/gpu/drm/gma500/gem.c | 7 ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
> include/drm/drmP.h | 4 ++--
> 7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
> int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
> {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>
> - kref_init(&obj->refcount);
> - atomic_set(&obj->handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>
> return 0;
> }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
> * no GEM provided backing store. Instead the caller is responsible for
> * backing the object and handling it.
> */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> + struct drm_gem_object *obj, size_t size)
> {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> obj->size = size;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> - if (drm_gem_private_object_init(dev,
> - &backing->gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, &backing->gem, aligned_size);
> + return backing;
> }
> return NULL;
> }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >t->gem, size);
> if (drm_gem_handle_create(file, >t->gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>t->gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_obj
Re: [PATCH v2 02/20] drm/gem: convert to new unified vma manager
Hi
On Sun, Jul 7, 2013 at 7:17 PM, David Herrmann wrote:
> Use the new vma manager instead of the old hashtable. Also convert all
> drivers to use the new convenience helpers. This drops all the
> (map_list.hash.key << PAGE_SHIFT) non-sense.
>
> Locking and access-management is exactly the same as before with an
> additional lock inside of the vma-manager, which strictly wouldn't be
> needed for gem.
>
> v2:
> - rebase on drm-next
> - init nodes via drm_vma_node_reset() in drm_gem.c
I missed the tegra driver and any staging driver. I will fix that in
v3 and reduce the series to a minimum.
Regards
David
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 90
> ++
> drivers/gpu/drm/drm_gem_cma_helper.c | 9 +--
> drivers/gpu/drm/exynos/exynos_drm_gem.c| 7 ++-
> drivers/gpu/drm/gma500/gem.c | 8 +--
> drivers/gpu/drm/i915/i915_gem.c| 9 +--
> drivers/gpu/drm/omapdrm/omap_gem.c | 11 ++--
> drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 49 +---
> drivers/gpu/drm/udl/udl_gem.c | 6 +-
> include/drm/drmP.h | 7 +--
> include/drm/drm_vma_manager.h | 1 -
> include/uapi/drm/drm.h | 2 +-
> 11 files changed, 49 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..b5db89b 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> /** @file drm_gem.c
> *
> @@ -102,14 +103,9 @@ drm_gem_init(struct drm_device *dev)
> }
>
> dev->mm_private = mm;
> -
> - if (drm_ht_create(&mm->offset_hash, 12)) {
> - kfree(mm);
> - return -ENOMEM;
> - }
> -
> - drm_mm_init(&mm->offset_manager, DRM_FILE_PAGE_OFFSET_START,
> - DRM_FILE_PAGE_OFFSET_SIZE);
> + drm_vma_offset_manager_init(&mm->vma_manager,
> + DRM_FILE_PAGE_OFFSET_START,
> + DRM_FILE_PAGE_OFFSET_SIZE);
>
> return 0;
> }
> @@ -119,8 +115,7 @@ drm_gem_destroy(struct drm_device *dev)
> {
> struct drm_gem_mm *mm = dev->mm_private;
>
> - drm_mm_takedown(&mm->offset_manager);
> - drm_ht_remove(&mm->offset_hash);
> + drm_vma_offset_manager_destroy(&mm->vma_manager);
> kfree(mm);
> dev->mm_private = NULL;
> }
> @@ -141,6 +136,7 @@ int drm_gem_object_init(struct drm_device *dev,
>
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> + drm_vma_node_reset(&obj->vma_node);
> obj->size = size;
>
> return 0;
> @@ -162,6 +158,7 @@ int drm_gem_private_object_init(struct drm_device *dev,
>
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> + drm_vma_node_reset(&obj->vma_node);
> obj->size = size;
>
> return 0;
> @@ -306,12 +303,8 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
> {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> - struct drm_map_list *list = &obj->map_list;
>
> - drm_ht_remove_item(&mm->offset_hash, &list->hash);
> - drm_mm_put_block(list->file_offset_node);
> - kfree(list->map);
> - list->map = NULL;
> + drm_vma_offset_remove(&mm->vma_manager, &obj->vma_node);
> }
> EXPORT_SYMBOL(drm_gem_free_mmap_offset);
>
> @@ -331,54 +324,9 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
> {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> - struct drm_map_list *list;
> - struct drm_local_map *map;
> - int ret;
> -
> - /* Set the object up for mmap'ing */
> - list = &obj->map_list;
> - list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
> - if (!list->map)
> - return -ENOMEM;
> -
> - map = list->map;
> - map->type = _DRM_GEM;
> - map->size = obj->size;
> - map->handle = obj;
> -
> - /* Get a DRM GEM mmap offset allocated... */
> - list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
> - obj->size / PAGE_SIZE, 0, false);
> -
> - if (!list->file_offset_node) {
> - DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
> - ret = -ENOSPC;
> - goto out_free_list;
> - }
>
> - list->file_offset_node = drm_mm_get_block(list->file_offset_node,
> - obj->size / PAGE_SIZE, 0);
> - if (!list->file_offset_node) {
> - ret = -ENOMEM;
> - goto out_free_list;
> - }
> -
> - list->hash.key = list->file_offset_node->start;
> - ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
> - if (ret) {
> -
Re: [PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 11:56 AM, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
>
> Cc: Patrik Jakobsson
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 20
> drivers/gpu/drm/gma500/framebuffer.c | 6 ++
> drivers/gpu/drm/gma500/gem.c | 7 ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
> include/drm/drmP.h | 4 ++--
> 7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
> int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
> {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>
> - kref_init(&obj->refcount);
> - atomic_set(&obj->handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>
> return 0;
> }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
> * no GEM provided backing store. Instead the caller is responsible for
> * backing the object and handling it.
> */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +struct drm_gem_object *obj, size_t size)
> {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> obj->size = size;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> - if (drm_gem_private_object_init(dev,
> - &backing->gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, &backing->gem, aligned_size);
> + return backing;
> }
> return NULL;
> }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >t->gem, size);
> if (drm_gem_handle_create(file, >t->gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>t->gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
> goto fail_detach;
> }
>
> - ret = drm_gem_private_object_init(dev, &obj->base, dma
Re: [PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)
Hi On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote: > On 07/07/2013 19:17, David Herrmann wrote: >> >> Hi >> >> This is v2 of the unified VMA offset manager series. The first draft is >> available at LWN [1]. This series replaces the VMA offset managers in GEM >> and >> TTM with a unified implementation. >> >> The first 4 patches contain the new VMA offset manager and are the only >> patches >> that I propose for mainline inclusion. >> Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar >> patches in i915-next and I will rebase them once it is merged. Ignore >> them if you're not interested. >> Patches 9-19 implement mmap access control. Comments are welcome! They are >> intended for mainline inclusion, too, but probably require some more >> review >> rounds. I'd really appreciate if driver authors could comment on the >> implementation. >> Patch 20 shows the main motivation behind this whole series: render nodes. >> It is >> marked RFC and I will resend once the VMA manager is merged upstream. Feel >> free >> to test it. >> >> One more note regarding DRM-Master: Render-clients are independent of >> DRM-Master >> (see the DocBook documentation). It really doesn't make sense to >> create/bind a >> DRM-Master object to render-clients. However, a lot of core DRM code >> depends on >> ->master != NULL. Drivers need to take care not to call into those core >> modules >> if they implement DRIVER_RENDER. >> I plan on removing multiple-master-support in the next series. So there >> will be >> only one global master and each open-file is bound to it. This will make >> it very >> easy to phase out "drm_master". The planned "modeset" nodes provide a nice >> replacement. If anyone knows a **currently used** use-case for >> multiple-masters, >> please tell me. I couldn't find one that _actually works_. >> (SetMaster+DropMaster >> will obviously stay functional even with drm_master removed). >> >> >> (series available at: https://github.com/dvdhrm/linux/tree/rnodes) >> >> Comments welcome! >> Cheers >> David > > Hi David, > > Thanks for this patchset. I am away from my computers for testing but I was > wondering if you based your vma rework on Dave's implementation. If so, > you may have the same bug that I had with it. > > I cannot remember the details of the bug, but I could trigger it by > rebooting > kde around 13 times on radeon. I didn't have this problem with Nouveau. It is based on Dave's code, but I rewrote all of it and fixed several bugs. For instance, there was a TTM ref-count leak for BOs in TTM core and a TTM locking issue. I didn't encounter any bugs so far, but I didn't try to restart the xserver 13 times. I will do some more stress-tests, but it is quite likely you hit one of those two bugs with radeon. > I am not competent to judge this work but I will try to test it and check > with my security tests that I wrote that the problem is indeed solved > on nouveau and radeon. The changes are actually quite simple. I intentionally kept TTM locking as it was before, even though I think we could reduce it now. Anyway, I will resend v3 (which now includes tegra and staging) this weekend. Hopefully we can get it into linux-next soon. Thanks! David > Looking forward to seeing your proposition for the userspace :) > > Cheers, > Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work
https://bugs.freedesktop.org/show_bug.cgi?id=66450 --- Comment #7 from Christian König --- Created attachment 82331 --> https://bugs.freedesktop.org/attachment.cgi?id=82331&action=edit Possible fix v2 Update patch, should work better this time. But please note that shader based decoding is far away from beeing perfect either. -- 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
Re: [PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 5:56 AM, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
>
> Cc: Patrik Jakobsson
> Signed-off-by: David Herrmann
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem.c | 20
> drivers/gpu/drm/gma500/framebuffer.c | 6 ++
> drivers/gpu/drm/gma500/gem.c | 7 ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
> include/drm/drmP.h | 4 ++--
> 7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
> int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
> {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>
> - kref_init(&obj->refcount);
> - atomic_set(&obj->handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>
> return 0;
> }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
> * no GEM provided backing store. Instead the caller is responsible for
> * backing the object and handling it.
> */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +struct drm_gem_object *obj, size_t size)
> {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> obj->size = size;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> - if (drm_gem_private_object_init(dev,
> - &backing->gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, &backing->gem, aligned_size);
> + return backing;
> }
> return NULL;
> }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >t->gem, size);
> if (drm_gem_handle_create(file, >t->gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>t->gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
> goto fail_detach;
> }
>
> - ret = drm_gem_private_object_ini
Re: [PULL] drm-intel-fixes
Cc lists this time around ... -Daniel On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter wrote: > Hi Dave, > > One feature latecomer, I've forgotten to merge the patch to reeanble the > Haswell power well feature now that the audio interaction is fixed up. > Since that was the only unfixed issue with it I've figured I could throw > it in a bit late, and it's trivial to revert in case I'm wrong. > > Otherwise all bug/regression fixes: > - Fix status page reinit after gpu hangs, spotted by more paranoid igt > checks. > - Fix object list walking fumble regression in the shrinker (only the > counting part, the actual shrinking code was correct so no Oops > potential), from Xiong Zhang. > - Fix DP 1.2 bw limits (Imre). > - Restore legacy forcewake on ivb, too many broken biosen out there. We > dump a warn though that recent userspace might fall over with that > config (Guenter Roeck). > - Patch up the gen2 cs tlb w/a. > - Improve the fence coherency w/a now that we have a better understanding > what's going on. The removed wbinvd+ipi should make -rt folks happy. Big > thanks to Jon Bloomfield for figuring this out, patches from Chris. > - Fix write-read race when switching ring (Chris). Spotted with code > inspection, but now we also have an igt for it. > > There's an ugly regression we're still working on introduced between > 3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since > that one fixes another regression :( I've asked Steven to include my > -fixes branch into linux-next to prevent such fallout in the future, > hopefully. > > Otherwise pretty calm thus far. > > Cheers, Daniel > > The following changes since commit 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e: > > drm/i915: Don't try to tear down the stolen drm_mm if it's not there > (2013-07-02 11:47:19 +0200) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm-intel > tags/drm-intel-fixes-2013-07-11 > > for you to fetch changes up to 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: > > Revert "drm/i915: Workaround incoherence between fences and LLC across > multiple CPUs" (2013-07-10 15:31:12 +0200) > > > Chris Wilson (3): > drm/i915: Fix write-read race with multiple rings > drm/i915: Fix incoherence with fence updates on Sandybridge+ > Revert "drm/i915: Workaround incoherence between fences and LLC across > multiple CPUs" > > Daniel Vetter (2): > drm/i915: reinit status page registers after gpu reset > drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a > > Guenter Roeck (1): > Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" > > Imre Deak (1): > drm/i915: fix lane bandwidth capping for DP 1.2 sinks > > Paulo Zanoni (1): > drm/i915: switch disable_power_well default value to 1 > > Xiong Zhang (1): > drm/i915: Correct obj->mm_list link to > dev_priv->dev_priv->mm.inactive_list > > drivers/gpu/drm/i915/i915_drv.c | 4 +- > drivers/gpu/drm/i915/i915_gem.c | 83 > + > drivers/gpu/drm/i915/intel_dp.c | 5 ++ > drivers/gpu/drm/i915/intel_pm.c | 31 +++- > drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +-- > 5 files changed, 93 insertions(+), 68 deletions(-) > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
On Thu, Jul 11, 2013 at 3:41 AM, Paul Menzel wrote: > Dear Linux folks, > > > using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged > and built with `make deb-pkg`, it failed the last boot. > > [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). > > The strange thing is that it worked the last time I tried with the same > Linux kernel image as I posted to the list [1]. I just booted an old > 3.2.46 distribution Linux in between. (And it looked like the > modesetting did not work when doing so. But I did not look further into > it.) Make sure you have the updated rlc and uvd ucode installed and that the correct ucode is being used in your initrd, etc. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 --- Comment #22 from Christian König --- (In reply to comment #21) > I got this compile warning: > > /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function > ‘radeon_uvd_fini’: > /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning: > ‘return’ with a value, in function returning void [enabled by default] >return 0; >^ Just a stupid typo, going to fix that before I send it out to the list. > Haven't had a chance to test just yet. Will report back as soon as possible. That would be greate, cause it's actually a quite serious bug. I'm currently also locking into the other stability issues with 3.10, but can't (yet) say if it's radeons fault or not. -- 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
Re: Questions about TTM buffer object maping
On Thu, Jul 11, 2013 at 2:24 AM, Daniel Vetter wrote: > On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote: >> On Wed, Jul 10, 2013 at 8:27 PM, Jean-Sébastien Pédron >> wrote: >> > Hello, >> > >> > I'm trying to understand how TTM buffer object mapping works on Linux, to >> > make this behave properly on FreeBSD. >> > >> > Here's what I think I understand: >> > >> > When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's >> > a >> > page fault, the page is looked up and inserted in the VMA using >> > vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is >> > called, which drops a reference. When the last reference is dropped, the >> > buffer object is destroyed. >> > >> > What's still not clear to me is how munmap() works here. After talking >> > about >> > this on IRC with some people, I think that unmap_mapping_range() (called by >> > ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from >> > userland. Is that true? >> >> Yes that's true. > > Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma. > So not equivalent to a munmap from userspace. It simply allows us to > intercept the next access in the page fault handler and move the buffer > back into place. > -Daniel Yes, i was talking from a page point of view, ie page no longer have mapping and can be free. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/39] clean out drm cruft and hide it better for kms drivers
On Wed, Jul 10, 2013 at 8:11 AM, Daniel Vetter wrote: > Hi all, > > I've figured that it's again time for a bit of (late) drm spring cleanup. This > series here consists of a pile of "rip old stuff out" patches interleaved with > "disable old cruft for kms drivers and hide it better". > > Comments, flames and review highly welcome. I'd be especially happy if the arm > guys could check whether I haven't badly broken their drivers - > compile-testing > arm is a pita, so I haven't yet done that. > > There's a few driver-wide patches included, but the more invasive ones (i.e. > changing more than the drm driver vtable) are split out per-driver for easier > merging. If no one screams my plan is to rebase this pile on top of -rc1, give > it some more testing (check arm, ugh) and then send a pull request to Dave. > That should reduce interference with ongoing driver work as much as possible I > hope. > > My drm cruft todo list still has a pile of ideas, but I've figured I need to > stop now for 3.12. For those interested further cleanups could include: > > - setversion/set_busid: All drm core version 1.1 is legacy cruft, kms drivers > should never run in this mode. We could clean up the setversion ioclt (and > move the drm core version handling into a legacy function) and set up the > bus > id unconditionally at driver load time. > > - There's a few more legacy ioctls/subsystems that could be blocked out for > kms > drivers (but the required git history digging tends to be tedious). Also I > think we could more aggressively move legacy cruft setup/teardown code > out-of-line from the main code by extracting it into drm_legacy_ functions > (like this series here already does for the context and dma stuff). > > - I think creating a drm_internal.h header for functions not exported to > drivers > would be useful. That way we could move all the legacy functions out of > drmP.h > (which are a lot of them), which should make it much clearer what the real > drm > driver interface actually is. > > - drm_os_linux.h should just die in fire. > > - There's a pile of needless indirection around our agp handling, we duplicate > the agp core's CONFIG_AGP=n no-oping function handling in large parts, among > other stuff. > > - The drm coherent dma alloc helpers could get ripped out, at least for kms > drivers. For ums drivers there's some funny cases where this mapping is > exchanged with userspace for e.g. register access. In a least one case > (i810.ko) userspace even sets up that mapping, which allows it to crash the > kernel at will (since those maps aren't refcounted). Maybe we need to shovel > those interfaces into a drm_legacy.ko module to keep them around but make > sure > that no new driver even thinks about using them. > > - There's also the matter of the vblank support code, imo that should be split > int a ums and a kms part. That'd would allow us to use struct drm_crtc * in > interfaces and proper locking (by grabbing crtc->mutex to exclude races with > dpms/modesets). > > If anyone wants to dig around in those areas please poke me. > For the series: Reviewed-by: Alex Deucher > Cheers, Daniel > > Daniel Vetter (39): > drm: remove drm_modctx ioctl and use drm_noop instead > drm: kill dev->context_wait > drm: remove dev->last_switch > drm: kill dev->interrupt_flag and dev->dma_flag > drm: kill dev->ctx_start and dev->lck_start > drm/radoen: kill radeon_dma_ioctl_kms > drm: kill dev->buf_readers and dev->buf_writers > drm: remove redundant clears from drm_setup > drm/omap: kill firstopen callback > drm/radeon: kill firstopen callback for kms driver > drm/imx: kill firstopen callback > drm/vmwgfx: remove ->firstopen callback > drm: don't call ->firstopen for KMS drivers > drm: kill dev->driver->set_version > drm/radeon: remove DRIVER_HAS_DMA/SG/PCI_DMA from the kms driver > drm: fold in drm_sg_alloc into the ioctl > drm: hide legacy sg cleanup better from common code > drm: disallow legacy sg ioctls for modesetting drivers > drm: mark dma setup/teardown as legacy systems > drm/nouveau: drop DRIVER_PCI_DMA and DRIVER_SG > drm: disallow legacy dma ioctls for modesetting drivers > drm: move drm_getsarea into drm_bufs.c > drm/bufs: s/drm_order/order_base_2/ > drm/r128: s/drm_order/order_base_2/ > drm/radeon: s/drm_order/order_base_2/ > drm: remove drm_order > drm: mark context support as a legacy subsystem > drm/vmwgfx: remove redundant clearing of driver->dma_quiescent > drm: remove FASYNC support > drm: rip out DRIVER_FB_DMA and related code > drm: rip out a few unused DRIVER flags > drm: remove a bunch of unused #defines from drmP.h > drm: rip out drm_core_has_MTRR checks > drm: remove the dma_ioctl special-case > drm/memory: don't export agp helpers > drm: hollow-out GET_CLIENT ioctl > drm: no-op out GET_STATS ioctl > drm: fix locking in gem debugfs/procfs file > drm: remove procfs code, take
[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=44772 Harald Judt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Harald Judt --- Reopened because it happens with 3.10 now even with pm_async set to 0. It happens with older kernel releases too when pm_async is set to 0, but is much harder to reproduce. -- 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
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 --- Comment #23 from Harald Judt --- Thanks, I confirm that the patch fixes the problem! I've tested this at least 5 times with both the vanilla and the tuxonice hibernation, and both now work pretty stable with 3.10. (As a side note: The BFQ IO scheduler patch makes my system hang when suspending, but that is a different issue and really not a concern for this bug report.) Now I'm still plagued by bug #44772, which is similar in that it only happens when resuming from hibernation, not when suspending, and it seems to occur much more often with 3.10 with pm_async=0 than before. As far as my machine is concerned, I consider this solved and 3.10 has become usable for me. Thanks! -- 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
[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=44772 Harald Judt changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #12 from Harald Judt --- Just for reference: Since I've never got a response here, I've opened a bug report at kernel bugzilla in the hope of someone helping me collect more debug data: https://bugzilla.kernel.org/show_bug.cgi?id=57381 Since everything's documented there, I'll finally close this bug. -- 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
[PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon: implement bo copy callback using CP DMA (v2)
From: Alex Deucher
Lighter weight than using the 3D engine.
v2: fix ring count
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c| 81 ++
drivers/gpu/drm/radeon/r600d.h |1 +
drivers/gpu/drm/radeon/radeon_asic.h |3 +
3 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2d3655f..f7d494f 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3145,6 +3145,87 @@ int r600_copy_blit(struct radeon_device *rdev,
}
/**
+ * r600_copy_cpdma - copy pages using the CP DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the CP DMA engine (r6xx+).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int r600_copy_cpdma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence)
+{
+ struct radeon_semaphore *sem = NULL;
+ int ring_index = rdev->asic->copy.blit_ring_index;
+ struct radeon_ring *ring = &rdev->ring[ring_index];
+ u32 size_in_bytes, cur_size_in_bytes, tmp;
+ int i, num_loops;
+ int r = 0;
+
+ r = radeon_semaphore_create(rdev, &sem);
+ if (r) {
+ DRM_ERROR("radeon: moving bo (%d).\n", r);
+ return r;
+ }
+
+ size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
+ num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
+ r = radeon_ring_lock(rdev, ring, num_loops * 6 + 21);
+ if (r) {
+ DRM_ERROR("radeon: moving bo (%d).\n", r);
+ radeon_semaphore_free(rdev, &sem, NULL);
+ return r;
+ }
+
+ if (radeon_fence_need_sync(*fence, ring->idx)) {
+ radeon_semaphore_sync_rings(rdev, sem, (*fence)->ring,
+ ring->idx);
+ radeon_fence_note_sync(*fence, ring->idx);
+ } else {
+ radeon_semaphore_free(rdev, &sem, NULL);
+ }
+
+ for (i = 0; i < num_loops; i++) {
+ cur_size_in_bytes = size_in_bytes;
+ if (cur_size_in_bytes > 0x1f)
+ cur_size_in_bytes = 0x1f;
+ size_in_bytes -= cur_size_in_bytes;
+ tmp = upper_32_bits(src_offset) & 0xff;
+ if (size_in_bytes == 0)
+ tmp |= PACKET3_CP_DMA_CP_SYNC;
+ radeon_ring_write(ring, PACKET3(PACKET3_CP_DMA, 4));
+ radeon_ring_write(ring, src_offset & 0x);
+ radeon_ring_write(ring, tmp);
+ radeon_ring_write(ring, dst_offset & 0x);
+ radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
+ radeon_ring_write(ring, cur_size_in_bytes);
+ src_offset += cur_size_in_bytes;
+ dst_offset += cur_size_in_bytes;
+ }
+ radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+ radeon_ring_write(ring, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET) >>
2);
+ radeon_ring_write(ring, WAIT_CP_DMA_IDLE_bit);
+
+ r = radeon_fence_emit(rdev, fence, ring->idx);
+ if (r) {
+ radeon_ring_unlock_undo(rdev, ring);
+ return r;
+ }
+
+ radeon_ring_unlock_commit(rdev, ring);
+ radeon_semaphore_free(rdev, &sem, *fence);
+
+ return r;
+}
+
+/**
* r600_copy_dma - copy pages using the DMA engine
*
* @rdev: radeon_device pointer
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index f1b3084..8e3fe81 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -602,6 +602,7 @@
#defineL2_BUSY (1 << 0)
#defineWAIT_UNTIL 0x8040
+#define WAIT_CP_DMA_IDLE_bit(1 << 8)
#define WAIT_2D_IDLE_bit(1 << 14)
#define WAIT_3D_IDLE_bit(1 << 15)
#define WAIT_2D_IDLECLEAN_bit (1 << 16)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 45d0693..b04b578 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -340,6 +340,9 @@ int r600_uvd_ring_test(struct radeon_device *rdev, struct
radeon_ring *ring);
int r600_copy_blit(struct radeon_device *rdev,
uint64_t src_offset, uint64_t dst_offset,
unsigned num_gpu_pages, struct radeon_fence **fence);
+int r600_copy_cpdma(struct radeon_device *rdev,
+
[PATCH 3/3] drm/radeon: use CP DMA on r6xx for bo moves
From: Alex Deucher
Lighter weight than using the 3D engine.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index ea5c52b..fea997e 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,7 +1026,7 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_blit,
+ .copy = &r600_copy_cpdma,
.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
@@ -1119,7 +1119,7 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_blit,
+ .copy = &r600_copy_cpdma,
.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
@@ -1229,7 +1229,7 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_blit,
+ .copy = &r600_copy_cpdma,
.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate
I've picked up the patch for my fixes queue. Thanks!
Alex
On Wed, Jul 10, 2013 at 6:26 AM, Maarten Lankhorst
wrote:
> Op 10-07-13 12:03, Markus Trippelsdorf schreef:
>> On 2013.07.10 at 11:56 +0200, Maarten Lankhorst wrote:
>>> Op 10-07-13 11:46, Markus Trippelsdorf schreef:
On 2013.07.10 at 11:29 +0200, Maarten Lankhorst wrote:
> Op 10-07-13 11:22, Markus Trippelsdorf schreef:
>> By simply copy/pasting a big document under LibreOffice my system hangs
>> itself up. Only a hard reset gets it working again.
>> see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551
>>
>> I've bisected the issue to:
>>
>> commit ecff665f5e3f1c6909353e00b9420e45ae23d995
>> Author: Maarten Lankhorst
>> Date: Thu Jun 27 13:48:17 2013 +0200
>>
>> drm/ttm: make ttm reservation calls behave like reservation calls
>>
>> This commit converts the source of the val_seq counter to
>> the ww_mutex api. The reservation objects are converted later,
>> because there is still a lockdep splat in nouveau that has to
>> resolved first.
>>
>> Signed-off-by: Maarten Lankhorst
>> Reviewed-by: Jerome Glisse
>> Signed-off-by: Dave Airlie
> Hey,
>
> Can you try current head with CONFIG_PROVE_LOCKING set and post the
> lockdep splat from dmesg, if any? If there is any locking issue
> lockdep should warn about it. Lockdep will turn itself off after the
> first splat, so if the lockdep splat happens before running the
> affected parts those will have to be fixed first.
There was an unrelated EDAC lockdep splat, so I simply disabled it.
This is what I get:
Jul 10 11:40:44 x4 kernel:
Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
Jul 10 11:40:44 x4 kernel:
Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still
held!
Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
Jul 10 11:40:44 x4 kernel: #0: (reservation_ww_class_acquire){+.+.+.},
at: [] radeon_bo_list_validate+0x20/0xd0
Jul 10 11:40:44 x4 kernel: #1: (reservation_ww_class_mutex){+.+.+.}, at:
[] ttm_eu_reserve_buffers+0x126/0x4b0
Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
Jul 10 11:40:53 x4 kernel: Emergency Sync complete
>>> Thanks, exactly what I thought. I missed a backoff somewhere..
>>>
>>> Does the below patch fix it?
>> Yes. Thank you for your quick reply.
>
> 8<--
> If radeon_cs_parser_relocs fails ttm_eu_backoff_reservation doesn't get
> called.
> This left open a bug where ttm_eu_reserve_buffers succeeded but the bo's were
> not unlocked afterwards:
>
> Jul 10 11:40:44 x4 kernel:
> Jul 10 11:40:44 x4 kernel: [ BUG: lock held when returning to user space! ]
> Jul 10 11:40:44 x4 kernel: 3.10.0-08587-g496322b #35 Not tainted
> Jul 10 11:40:44 x4 kernel:
> Jul 10 11:40:44 x4 kernel: X/211 is leaving the kernel with locks still held!
> Jul 10 11:40:44 x4 kernel: 2 locks held by X/211:
> Jul 10 11:40:44 x4 kernel: #0: (reservation_ww_class_acquire){+.+.+.}, at:
> [] radeon_bo_list_validate+0x20/0xd0
> Jul 10 11:40:44 x4 kernel: #1: (reservation_ww_class_mutex){+.+.+.}, at:
> [] ttm_eu_reserve_buffers+0x126/0x4b0
> Jul 10 11:40:52 x4 kernel: SysRq : Emergency Sync
> Jul 10 11:40:53 x4 kernel: Emergency Sync complete
>
> This is a regression caused by commit ecff665f5e.
> "drm/ttm: make ttm reservation calls behave like reservation calls"
>
> Reported-by: Markus Trippelsdorf
> Tested-by: Markus Trippelsdorf
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 0219d26..2020bf4 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -377,6 +377,7 @@ int radeon_bo_list_validate(struct ww_acquire_ctx *ticket,
> domain = lobj->alt_domain;
> goto retry;
> }
> + ttm_eu_backoff_reservation(ticket, head);
> return r;
> }
> }
>
> ___
> 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: use radeon device for request firmware
From: Jerome Glisse
Avoid creating temporary platform device that will lead to issue
when several radeon gpu are in same computer. Instead directly use
the radeon device for requesting firmware.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/cik.c| 25 +++--
drivers/gpu/drm/radeon/ni.c | 21 +
drivers/gpu/drm/radeon/r100.c | 11 +--
drivers/gpu/drm/radeon/r600.c | 19 ---
drivers/gpu/drm/radeon/radeon_uvd.c | 13 +
drivers/gpu/drm/radeon/si.c | 23 ++-
6 files changed, 24 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index db507a4..b893165 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -22,7 +22,6 @@
* Authors: Alex Deucher
*/
#include
-#include
#include
#include
#include "drmP.h"
@@ -742,7 +741,6 @@ static int ci_mc_load_microcode(struct radeon_device *rdev)
*/
static int cik_init_microcode(struct radeon_device *rdev)
{
- struct platform_device *pdev;
const char *chip_name;
size_t pfp_req_size, me_req_size, ce_req_size,
mec_req_size, rlc_req_size, mc_req_size,
@@ -752,13 +750,6 @@ static int cik_init_microcode(struct radeon_device *rdev)
DRM_DEBUG("\n");
- pdev = platform_device_register_simple("radeon_cp", 0, NULL, 0);
- err = IS_ERR(pdev);
- if (err) {
- printk(KERN_ERR "radeon_cp: Failed to register firmware\n");
- return -EINVAL;
- }
-
switch (rdev->family) {
case CHIP_BONAIRE:
chip_name = "BONAIRE";
@@ -794,7 +785,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
DRM_INFO("Loading %s Microcode\n", chip_name);
snprintf(fw_name, sizeof(fw_name), "radeon/%s_pfp.bin", chip_name);
- err = request_firmware(&rdev->pfp_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->pfp_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->pfp_fw->size != pfp_req_size) {
@@ -806,7 +797,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", chip_name);
- err = request_firmware(&rdev->me_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->me_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->me_fw->size != me_req_size) {
@@ -817,7 +808,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_ce.bin", chip_name);
- err = request_firmware(&rdev->ce_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->ce_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->ce_fw->size != ce_req_size) {
@@ -828,7 +819,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_mec.bin", chip_name);
- err = request_firmware(&rdev->mec_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->mec_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->mec_fw->size != mec_req_size) {
@@ -839,7 +830,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_rlc.bin", chip_name);
- err = request_firmware(&rdev->rlc_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->rlc_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->rlc_fw->size != rlc_req_size) {
@@ -850,7 +841,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_sdma.bin", chip_name);
- err = request_firmware(&rdev->sdma_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->sdma_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->sdma_fw->size != sdma_req_size) {
@@ -863,7 +854,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
/* No MC ucode on APUs */
if (!(rdev->flags & RADEON_IS_IGP)) {
snprintf(fw_name, sizeof(fw_name), "radeon/%s_mc.bin",
chip_name);
- err = request_firmware(&rdev->mc_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->mc_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->mc_fw->size != mc_req_size) {
@@ -875,8 +866,6 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
out:
- platform_device_unregister(pdev);
-
if (err) {
if (err != -EINVAL)
printk(KERN_ERR
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index f30127c..465b17e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++
Re: [PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx
On Thu, Jul 11, 2013 at 3:59 PM, Ilija Hadzic
wrote:
>
> Alex,
>
> Can you please share some details about the nature or symptom of the
> "instability". One problem that I have been seeing on my end is that when I
> use the DMA ring intensively (by intensively I mean, calling the copy
> function every frame), combined with some 3D rendering that causes a lot of
> cs_ioctl calls, that I can provoke a corruption of the olist field in
> radeon_sa_bo structure, consequently causing an oops in
> radeon_sa_bo_try_free(). I have also found that I can suppress the problem
> if I add some padding fields at the beginnig of the radeon_sa_bo structure
> (essentially moving the olist field down).
>
> So I speculate that the use of DMA somehow results in corrupting that
> structure, but I have not yet done enough experiments to prove or disprove
> that theory (so I have not spoke up yet). Also my kernel is full of my own
> internal hacks, and I have not yet taken the time to reproduce the problem
> with the "stock" kernel. However, after seeing your patch series, I am
> wondering if the instability you are referring to may be of the same or
> similar nature.
Basically using the DMA engine on r6xx seems to lead to hangs on
certain chips when the bo copy callback gets triggered a lot (e.g., a
web page with lots of images, etc.). Switching back to the 3D engine
fixes the issue. R6xx was the first asic family with the async dma
engines, so there are likely some hw bugs at play. Unfortunately, the
hw guys haven't looked at 6xx in probably 8 years, so I don't hold out
much chance of getting to the root of the problem at this point.
Alex
>
> thanks,
>
> Ilija
>
>
>
> On Thu, 11 Jul 2013, alexdeuc...@gmail.com wrote:
>
>> From: Alex Deucher
>>
>> They still seem to cause instability on some r6xx parts.
>> As a follow up, we can switch to using CP DMA for bo
>> moves on r6xx as a lighter weight alternative to using
>> the 3D engine.
>>
>> A version of this patch should also go to stable kernels.
>>
>> Tested-by: J.N.
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
>> 1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
>> b/drivers/gpu/drm/radeon/radeon_asic.c
>> index 0970774..ea5c52b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_asic.c
>> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
>> @@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
>> .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> .dma = &r600_copy_dma,
>> .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
>> - .copy = &r600_copy_dma,
>> - .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> + .copy = &r600_copy_blit,
>> + .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> },
>> .surface = {
>> .set_reg = r600_set_surface_reg,
>> @@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
>> .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> .dma = &r600_copy_dma,
>> .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
>> - .copy = &r600_copy_dma,
>> - .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> + .copy = &r600_copy_blit,
>> + .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> },
>> .surface = {
>> .set_reg = r600_set_surface_reg,
>> @@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
>> .blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> .dma = &r600_copy_dma,
>> .dma_ring_index = R600_RING_TYPE_DMA_INDEX,
>> - .copy = &r600_copy_dma,
>> - .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
>> + .copy = &r600_copy_blit,
>> + .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
>> },
>> .surface = {
>> .set_reg = r600_set_surface_reg,
>> --
>> 1.7.7.5
>>
>> ___
>> 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
Re: [PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx
Alex,
Can you please share some details about the nature or symptom of the
"instability". One problem that I have been seeing on my end is that when
I use the DMA ring intensively (by intensively I mean, calling the copy
function every frame), combined with some 3D rendering that causes a lot
of cs_ioctl calls, that I can provoke a corruption of the olist field in
radeon_sa_bo structure, consequently causing an oops in
radeon_sa_bo_try_free(). I have also found that I can suppress the problem
if I add some padding fields at the beginnig of the radeon_sa_bo structure
(essentially moving the olist field down).
So I speculate that the use of DMA somehow results in corrupting that
structure, but I have not yet done enough experiments to prove or disprove
that theory (so I have not spoke up yet). Also my kernel is full of my own
internal hacks, and I have not yet taken the time to reproduce the problem
with the "stock" kernel. However, after seeing your patch series, I am
wondering if the instability you are referring to may be of the same
or similar nature.
thanks,
Ilija
On Thu, 11 Jul 2013, alexdeuc...@gmail.com wrote:
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5
___
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
[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work
https://bugs.freedesktop.org/show_bug.cgi?id=66450 --- Comment #8 from Eugene Shalygin --- With this patch playback works. Thank you! -- 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
[Bug 61470] Driver does not turn on LCD backlight on resume
https://bugs.freedesktop.org/show_bug.cgi?id=61470 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 43829 *** -- 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
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 Alex Deucher changed: What|Removed |Added CC||webmas...@jamescobban.net --- Comment #25 from Alex Deucher --- *** Bug 61470 has been marked as a duplicate of this bug. *** -- 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
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 --- Comment #26 from Alex Deucher --- Created attachment 82347 --> https://bugs.freedesktop.org/attachment.cgi?id=82347&action=edit possible fix Does the attached patch help? -- 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
[PATCH 1/3] drm/radeon: add fault decode function for cayman/TN (v2)
From: Alex Deucher
Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.
v2: simplify fault decoding
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/evergreen.c | 10 ++-
drivers/gpu/drm/radeon/ni.c| 161
drivers/gpu/drm/radeon/nid.h | 16
3 files changed, 185 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 9e14007..bc6936a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -139,6 +139,8 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
void evergreen_program_aspm(struct radeon_device *rdev);
extern void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
int ring, u32 cp_int_cntl);
+extern void cayman_vm_decode_fault(struct radeon_device *rdev,
+ u32 status, u32 addr);
static const u32 evergreen_golden_registers[] =
{
@@ -4629,6 +4631,7 @@ int evergreen_irq_process(struct radeon_device *rdev)
bool queue_hotplug = false;
bool queue_hdmi = false;
bool queue_thermal = false;
+ u32 status, addr;
if (!rdev->ih.enabled || rdev->shutdown)
return IRQ_NONE;
@@ -4915,11 +4918,14 @@ restart_ih:
break;
case 146:
case 147:
+ addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
+ status = RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS);
dev_err(rdev->dev, "GPU fault detected: %d 0x%08x\n",
src_id, src_data);
dev_err(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR
0x%08X\n",
- RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+ addr);
dev_err(rdev->dev, "
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
- RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+ status);
+ cayman_vm_decode_fault(rdev, status, addr);
/* reset addr and status */
WREG32_P(VM_CONTEXT1_CNTL2, 1, ~1);
break;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 465b17e..56bd4f3 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2450,6 +2450,167 @@ void cayman_vm_fini(struct radeon_device *rdev)
{
}
+/**
+ * cayman_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (cayman/TN).
+ */
+void cayman_vm_decode_fault(struct radeon_device *rdev,
+ u32 status, u32 addr)
+{
+ u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
+ u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
+ u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
+ char *block;
+
+ switch (mc_id) {
+ case 32:
+ case 16:
+ case 96:
+ case 80:
+ case 160:
+ case 144:
+ case 224:
+ case 208:
+ block = "CB";
+ break;
+ case 33:
+ case 17:
+ case 97:
+ case 81:
+ case 161:
+ case 145:
+ case 225:
+ case 209:
+ block = "CB_FMASK";
+ break;
+ case 34:
+ case 18:
+ case 98:
+ case 82:
+ case 162:
+ case 146:
+ case 226:
+ case 210:
+ block = "CB_CMASK";
+ break;
+ case 35:
+ case 19:
+ case 99:
+ case 83:
+ case 163:
+ case 147:
+ case 227:
+ case 211:
+ block = "CB_IMMED";
+ break;
+ case 36:
+ case 20:
+ case 100:
+ case 84:
+ case 164:
+ case 148:
+ case 228:
+ case 212:
+ block = "DB";
+ break;
+ case 37:
+ case 21:
+ case 101:
+ case 85:
+ case 165:
+ case 149:
+ case 229:
+ case 213:
+ block = "DB_HTILE";
+ break;
+ case 38:
+ case 22:
+ case 102:
+ case 86:
+ case 166:
+ case 150:
+ case 230:
+ case 214:
+ block = "SX";
+ break;
+ case 39:
+ case 23:
+ case 103:
+ case 87:
+ case 167:
+ case 151:
+ case 231:
+ case 215:
+ block = "DB_STEN";
+ break;
+ case 40:
+ case 24:
+ case 104:
+ case 88:
+ case 232:
+ case 216:
+ case
[PATCH 2/3] drm/radeon: add fault decode function for SI (v2)
From: Alex Deucher
Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.
v2: simplify fault decoding
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/si.c | 272 +-
drivers/gpu/drm/radeon/sid.h | 14 ++
2 files changed, 284 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f305768..d3f0507 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4390,6 +4390,270 @@ void si_vm_fini(struct radeon_device *rdev)
}
/**
+ * si_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (SI).
+ */
+static void si_vm_decode_fault(struct radeon_device *rdev,
+ u32 status, u32 addr)
+{
+ u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
+ u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
+ u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
+ char *block;
+
+ if (rdev->family == CHIP_TAHITI) {
+ switch (mc_id) {
+ case 160:
+ case 144:
+ case 96:
+ case 80:
+ case 224:
+ case 208:
+ case 32:
+ case 16:
+ block = "CB";
+ break;
+ case 161:
+ case 145:
+ case 97:
+ case 81:
+ case 225:
+ case 209:
+ case 33:
+ case 17:
+ block = "CB_FMASK";
+ break;
+ case 162:
+ case 146:
+ case 98:
+ case 82:
+ case 226:
+ case 210:
+ case 34:
+ case 18:
+ block = "CB_CMASK";
+ break;
+ case 163:
+ case 147:
+ case 99:
+ case 83:
+ case 227:
+ case 211:
+ case 35:
+ case 19:
+ block = "CB_IMMED";
+ break;
+ case 164:
+ case 148:
+ case 100:
+ case 84:
+ case 228:
+ case 212:
+ case 36:
+ case 20:
+ block = "DB";
+ break;
+ case 165:
+ case 149:
+ case 101:
+ case 85:
+ case 229:
+ case 213:
+ case 37:
+ case 21:
+ block = "DB_HTILE";
+ break;
+ case 167:
+ case 151:
+ case 103:
+ case 87:
+ case 231:
+ case 215:
+ case 39:
+ case 23:
+ block = "DB_STEN";
+ break;
+ case 72:
+ case 68:
+ case 64:
+ case 8:
+ case 4:
+ case 0:
+ case 136:
+ case 132:
+ case 128:
+ case 200:
+ case 196:
+ case 192:
+ block = "TC";
+ break;
+ case 112:
+ case 48:
+ block = "CP";
+ break;
+ case 49:
+ case 177:
+ case 50:
+ case 178:
+ block = "SH";
+ break;
+ case 53:
+ case 190:
+ block = "VGT";
+ break;
+ case 117:
+ block = "IH";
+ break;
+ case 51:
+ case 115:
+ block = "RLC";
+ break;
+ case 119:
+ case 183:
+ block = "DMA0";
+ break;
+ case 61:
+ block = "DMA1";
+ break;
+ case 248:
+ case 120:
+ block = "HDP";
+ break;
+ default:
+ block = "unknown";
+ break;
+ }
+ } else {
+ switch (mc_id) {
+ case 32:
+ case 16:
+ case 96:
+ case 80:
+ case 160:
+ case 144:
+ case 224:
+ ca
[PATCH 3/3] drm/radeon: add fault decode function for CIK
From: Alex Deucher
Helpful for debugging GPUVM errors as we can see what
hw block and page generated the fault in the log.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cik.c | 32 ++--
drivers/gpu/drm/radeon/cikd.h | 16
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 27891d8..68b4fc5 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4442,6 +4442,29 @@ void cik_vm_fini(struct radeon_device *rdev)
}
/**
+ * cik_vm_decode_fault - print human readable fault info
+ *
+ * @rdev: radeon_device pointer
+ * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value
+ * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value
+ *
+ * Print human readable fault information (CIK).
+ */
+static void cik_vm_decode_fault(struct radeon_device *rdev,
+ u32 status, u32 addr, u32 mc_client)
+{
+ u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT;
+ u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT;
+ u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT;
+ char *block = (char *)&mc_client;
+
+ printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n",
+ protections, vmid, addr,
+ (status & MEMORY_CLIENT_RW_MASK) ? "write" : "read",
+ block, mc_id);
+}
+
+/**
* cik_vm_flush - cik vm flush using the CP
*
* @rdev: radeon_device pointer
@@ -5496,6 +5519,7 @@ int cik_irq_process(struct radeon_device *rdev)
u32 ring_index;
bool queue_hotplug = false;
bool queue_reset = false;
+ u32 addr, status, mc_client;
if (!rdev->ih.enabled || rdev->shutdown)
return IRQ_NONE;
@@ -5731,11 +5755,15 @@ restart_ih:
break;
case 146:
case 147:
+ addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR);
+ status = RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS);
+ mc_client =
RREG32(VM_CONTEXT1_PROTECTION_FAULT_MCCLIENT);
dev_err(rdev->dev, "GPU fault detected: %d 0x%08x\n",
src_id, src_data);
dev_err(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR
0x%08X\n",
- RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR));
+ addr);
dev_err(rdev->dev, "
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n",
- RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS));
+ status);
+ cik_vm_decode_fault(rdev, status, addr, mc_client);
/* reset addr and status */
WREG32_P(VM_CONTEXT1_CNTL2, 1, ~1);
break;
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 63514b9..7e9275e 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -136,6 +136,22 @@
#define VM_INVALIDATE_RESPONSE 0x147c
#defineVM_CONTEXT1_PROTECTION_FAULT_STATUS 0x14DC
+#definePROTECTIONS_MASK(0xf << 0)
+#definePROTECTIONS_SHIFT 0
+ /* bit 0: range
+* bit 1: pde0
+* bit 2: valid
+* bit 3: read
+* bit 4: write
+*/
+#defineMEMORY_CLIENT_ID_MASK (0xff << 12)
+#defineMEMORY_CLIENT_ID_SHIFT 12
+#defineMEMORY_CLIENT_RW_MASK (1 << 24)
+#defineMEMORY_CLIENT_RW_SHIFT 24
+#defineFAULT_VMID_MASK (0xf << 25)
+#defineFAULT_VMID_SHIFT25
+
+#defineVM_CONTEXT1_PROTECTION_FAULT_MCCLIENT 0x14E4
#defineVM_CONTEXT1_PROTECTION_FAULT_ADDR 0x14FC
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Questions about TTM buffer object maping
Hi, Thank you Jérôme and Daniel for your input, that's really helpful! I have another question: in ttm_bo_mmap(), a reference to the buffer object is acquired at the beginning of the function. Another reference is acquired in ttm_bo_vm_open() (released in ttm_bo_vm_close()). But where is the first reference released? -- Jean-Sébastien Pédron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Questions about TTM buffer object maping
On Thu, Jul 11, 2013 at 5:43 PM, Jean-Sébastien Pédron wrote: > Hi, > > Thank you Jérôme and Daniel for your input, that's really helpful! > > I have another question: in ttm_bo_mmap(), a reference to the buffer object > is acquired at the beginning of the function. Another reference is acquired > in ttm_bo_vm_open() (released in ttm_bo_vm_close()). > > But where is the first reference released? > > -- > Jean-Sébastien Pédron the ttm_bo_vm_open is not call on first time a vma is mmap, ie when userspace do mmap it call driver mmap callback which call ttm_bo_mmap but ttm_bo_vm_open is never call. If the same process or another process mmap the same area or subarea the ttm_bo_vm_open is call. Then on each unmap ttm_bo_vm_close is call. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Questions about TTM buffer object maping
Hi On Thu, Jul 11, 2013 at 11:43 PM, Jean-Sébastien Pédron wrote: > Hi, > > Thank you Jérôme and Daniel for your input, that's really helpful! > > I have another question: in ttm_bo_mmap(), a reference to the buffer object > is acquired at the beginning of the function. Another reference is acquired > in ttm_bo_vm_open() (released in ttm_bo_vm_close()). > > But where is the first reference released? ->vm_open() isn't called for the first mmap(), afaik (only called during fork()s or similar). So the reference in ttm_bo_mmap() is a replacement for the reference you take in the ->vm_open() callback. Cheers David > -- > Jean-Sébastien Pédron > > ___ > 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
Re: Questions about TTM buffer object maping
Le 11/07/2013 23:51, David Herrmann a écrit : ->vm_open() isn't called for the first mmap(), afaik (only called during fork()s or similar). So the reference in ttm_bo_mmap() is a replacement for the reference you take in the ->vm_open() callback. So the reference is acquired either in ttm_bo_mmap() or in ttm_bo_vm_open(), and always released in ttm_bo_vm_close(). Thanks to both of you! -- Jean-Sébastien Pédron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66836] New: [r600g] WoW is crashing with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=66836 Priority: medium Bug ID: 66836 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] WoW is crashing with HD6450 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ranki...@googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa WoW has started crashing with my Hd6450. A "git bisect" pinpoints this commit: 862f69fbe1e54e0e9a3c439450a14f0319648b60 is the first bad commit commit 862f69fbe1e54e0e9a3c439450a14f0319648b60 Author: Marek Olšák Date: Sun Jun 30 14:57:17 2013 +0200 r600g: don't call buffer_wait in buffer_mmap_sync_with_rings The winsys should do this, because it measures how much time we spend in buffer_map doing synchronization, which can be viewed with the gallium HUD. Reviewed-by: Alex Deucher :04 04 7443defc91af969379873fc85698e78cc0731b12 9a18818193c561b6aff233efc290f7655924cbd1 Msrc WoW's own crash dump analysis is attached, but the relevant part appears to be: --- Thread ID: 74 [Current Thread] --- 7FEEB939E2AD radeon_get_reloc+45 (,,,) 7FEEB939D6C7 radeon_bo_map+551 (,,,) 7FEEB933C89B r600_buffer_transfer_map+107 (,,,) 7FEEB917A0D7 st_bufferobj_get_subdata+119 (,000 (It turns out that I was running WoW in DXD9 mode rather than OpenGL mode, but it still shouldn't have crashed.) -- 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
[Bug 66836] [r600g] WoW is crashing with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=66836 --- Comment #1 from Chris Rankin --- Created attachment 82348 --> https://bugs.freedesktop.org/attachment.cgi?id=82348&action=edit Crash dump analysis -- 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
[Bug 66836] [r600g] WoW is crashing with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=66836 --- Comment #2 from Chris Rankin --- Created attachment 82349 --> https://bugs.freedesktop.org/attachment.cgi?id=82349&action=edit dmesg output -- 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
[Bug 66837] New: [regression] X hangs since commit 098316211ce65db79d00c5975fa30873426450a6
https://bugs.freedesktop.org/show_bug.cgi?id=66837 Priority: medium Bug ID: 66837 Assignee: dri-devel@lists.freedesktop.org Summary: [regression] X hangs since commit 098316211ce65db79d00c5975fa30873426450a6 Severity: critical Classification: Unclassified OS: Linux (All) Reporter: nonno.cic...@tiscali.it Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Since commit 098316211ce65db79d00c5975fa30873426450a6 every time I go to gmail with chromium 28.0.1500.89, less than 10 seconds after it loads the page, the bookmarks bar get filled with weird colours, as the portraits of my contacts in hangouts, then X hangs and the keyboard stops working (even pressing Num Lock doesn't turn the LED off). The system can still be shut down cleanly with acpid and the power button. I have some changed flags in chrome://flags, but with the same flags it always worked. HD3850 AGP 512MB (RV670) kernel 3.9.9 X.Org server 1.12.4 libdrm 2.4.46 -- 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
[Bug 64695] Enabling both MLAA and MLAA color 2D crashes Gnome Shell on Cayman (6950)
https://bugs.freedesktop.org/show_bug.cgi?id=64695 --- Comment #6 from Alexandre Demers --- Quickly tested with today's git and it still does the same "Oops". However, KDE doesn't have any problem to load. I'll give more info soon, I just don't have much time right now. -- 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
Re: [PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)
On 07/07/2013 19:17, David Herrmann wrote: Hi This is v2 of the unified VMA offset manager series. The first draft is available at LWN [1]. This series replaces the VMA offset managers in GEM and TTM with a unified implementation. The first 4 patches contain the new VMA offset manager and are the only patches that I propose for mainline inclusion. Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar patches in i915-next and I will rebase them once it is merged. Ignore them if you're not interested. Patches 9-19 implement mmap access control. Comments are welcome! They are intended for mainline inclusion, too, but probably require some more review rounds. I'd really appreciate if driver authors could comment on the implementation. Patch 20 shows the main motivation behind this whole series: render nodes. It is marked RFC and I will resend once the VMA manager is merged upstream. Feel free to test it. One more note regarding DRM-Master: Render-clients are independent of DRM-Master (see the DocBook documentation). It really doesn't make sense to create/bind a DRM-Master object to render-clients. However, a lot of core DRM code depends on ->master != NULL. Drivers need to take care not to call into those core modules if they implement DRIVER_RENDER. I plan on removing multiple-master-support in the next series. So there will be only one global master and each open-file is bound to it. This will make it very easy to phase out "drm_master". The planned "modeset" nodes provide a nice replacement. If anyone knows a **currently used** use-case for multiple-masters, please tell me. I couldn't find one that _actually works_. (SetMaster+DropMaster will obviously stay functional even with drm_master removed). (series available at: https://github.com/dvdhrm/linux/tree/rnodes) Comments welcome! Cheers David Hi David, Thanks for this patchset. I am away from my computers for testing but I was wondering if you based your vma rework on Dave's implementation. If so, you may have the same bug that I had with it. I cannot remember the details of the bug, but I could trigger it by rebooting kde around 13 times on radeon. I didn't have this problem with Nouveau. I am not competent to judge this work but I will try to test it and check with my security tests that I wrote that the problem is indeed solved on nouveau and radeon. Looking forward to seeing your proposition for the userspace :) Cheers, Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)
On 11/07/2013 13:21, David Herrmann wrote: Hi On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote: On 07/07/2013 19:17, David Herrmann wrote: Hi This is v2 of the unified VMA offset manager series. The first draft is available at LWN [1]. This series replaces the VMA offset managers in GEM and TTM with a unified implementation. The first 4 patches contain the new VMA offset manager and are the only patches that I propose for mainline inclusion. Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar patches in i915-next and I will rebase them once it is merged. Ignore them if you're not interested. Patches 9-19 implement mmap access control. Comments are welcome! They are intended for mainline inclusion, too, but probably require some more review rounds. I'd really appreciate if driver authors could comment on the implementation. Patch 20 shows the main motivation behind this whole series: render nodes. It is marked RFC and I will resend once the VMA manager is merged upstream. Feel free to test it. One more note regarding DRM-Master: Render-clients are independent of DRM-Master (see the DocBook documentation). It really doesn't make sense to create/bind a DRM-Master object to render-clients. However, a lot of core DRM code depends on ->master != NULL. Drivers need to take care not to call into those core modules if they implement DRIVER_RENDER. I plan on removing multiple-master-support in the next series. So there will be only one global master and each open-file is bound to it. This will make it very easy to phase out "drm_master". The planned "modeset" nodes provide a nice replacement. If anyone knows a **currently used** use-case for multiple-masters, please tell me. I couldn't find one that _actually works_. (SetMaster+DropMaster will obviously stay functional even with drm_master removed). (series available at: https://github.com/dvdhrm/linux/tree/rnodes) Comments welcome! Cheers David Hi David, Thanks for this patchset. I am away from my computers for testing but I was wondering if you based your vma rework on Dave's implementation. If so, you may have the same bug that I had with it. I cannot remember the details of the bug, but I could trigger it by rebooting kde around 13 times on radeon. I didn't have this problem with Nouveau. It is based on Dave's code, but I rewrote all of it and fixed several bugs. For instance, there was a TTM ref-count leak for BOs in TTM core and a TTM locking issue. I didn't encounter any bugs so far, but I didn't try to restart the xserver 13 times. I will do some more stress-tests, but it is quite likely you hit one of those two bugs with radeon. Yeah, the problem I had was related to ref-count and I was trying to fix the locking too. I am not competent to judge this work but I will try to test it and check with my security tests that I wrote that the problem is indeed solved on nouveau and radeon. The changes are actually quite simple. I intentionally kept TTM locking as it was before, even though I think we could reduce it now. Anyway, I will resend v3 (which now includes tegra and staging) this weekend. Hopefully we can get it into linux-next soon. Very nice! Looking forward to it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/gpio/nv50: post nv92 cards have 32 interrupt lines
Since the original merge of nouveau to upstream kernel, we were assuming that
nv90 (and later) cards have 32 lines.
Based on mmio traces of the binary driver, as well as PBUS error messages
during read/write of the e070/e074 registers, we can conclude that nv92 has
only 16 lines whereas nv94 (and later) cards have 32.
Reported-and-tested-by: David M. Lloyd
Signed-off-by: Emil Velikov
Cc: dri-devel@lists.freedesktop.org
Cc: Ben Skeggs
---
Considering that no-one has reported this issue before, I'm rather curious
if we should CC stable
---
drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
index bf489dc..c4c1d41 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c
@@ -103,7 +103,7 @@ nv50_gpio_intr(struct nouveau_subdev *subdev)
int i;
intr0 = nv_rd32(priv, 0xe054) & nv_rd32(priv, 0xe050);
- if (nv_device(priv)->chipset >= 0x90)
+ if (nv_device(priv)->chipset > 0x92)
intr1 = nv_rd32(priv, 0xe074) & nv_rd32(priv, 0xe070);
hi = (intr0 & 0x) | (intr1 << 16);
@@ -115,7 +115,7 @@ nv50_gpio_intr(struct nouveau_subdev *subdev)
}
nv_wr32(priv, 0xe054, intr0);
- if (nv_device(priv)->chipset >= 0x90)
+ if (nv_device(priv)->chipset > 0x92)
nv_wr32(priv, 0xe074, intr1);
}
@@ -146,7 +146,7 @@ nv50_gpio_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
int ret;
ret = nouveau_gpio_create(parent, engine, oclass,
- nv_device(parent)->chipset >= 0x90 ? 32 : 16,
+ nv_device(parent)->chipset > 0x92 ? 32 : 16,
&priv);
*pobject = nv_object(priv);
if (ret)
@@ -182,7 +182,7 @@ nv50_gpio_init(struct nouveau_object *object)
/* disable, and ack any pending gpio interrupts */
nv_wr32(priv, 0xe050, 0x);
nv_wr32(priv, 0xe054, 0x);
- if (nv_device(priv)->chipset >= 0x90) {
+ if (nv_device(priv)->chipset > 0x92) {
nv_wr32(priv, 0xe070, 0x);
nv_wr32(priv, 0xe074, 0x);
}
@@ -195,7 +195,7 @@ nv50_gpio_fini(struct nouveau_object *object, bool suspend)
{
struct nv50_gpio_priv *priv = (void *)object;
nv_wr32(priv, 0xe050, 0x);
- if (nv_device(priv)->chipset >= 0x90)
+ if (nv_device(priv)->chipset > 0x92)
nv_wr32(priv, 0xe070, 0x);
return nouveau_gpio_fini(&priv->base, suspend);
}
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and and based on ww-mutexes[2] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and user application. This framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v5: - Rmove a dependence on reservation_object: the reservation_object is used to hook up to ttm and dma-buf for easy sharing of reservations across devices. However, the dmabuf sync can be used for all dma devices; v4l2 and drm based drivers, so doesn't need the reservation_object anymore. With regared to this, it adds 'void *sync' to dma_buf structure. - All patches are rebased on mainline, Linux v3.10. Changelog v4: - Add user side interface for buffer synchronization mechanism and update descriptions related to the user side interface. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); ... And the below can be used as access types: DMA_BUF_ACCESS_R - CPU will access a buffer for read. DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use interfaces for device driver: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed:
[RFC PATCH 0/2 v5] Introduce buffer synchronization framework
Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. For generic user mode interface, we have used fcntl system call[3]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ Moreover, we had tried to find how we could utilize limited hardware resources more using buffer synchronization mechanism. And finally, we have realized that it could enhance performance using multi threads with this buffer synchronization mechanism: DMA and CPU works individually so CPU could perform other works while DMA is performing some works, and vise versa. However, in the conventional way, that is not easy to do so because DMA operation is depend on CPU operation, and vice versa. Conventional way: User Kernel - CPU writes something to src send the src to driver-> update DMA register request DMA start(1)---> DMA start <-completion signal(2)-- CPU accesses dst (1) Request DMA start after the CPU access to src buffer is completed. (2) Access dst buffer after DMA access to the dst buffer is completed. On the other hand, if there is something to control buffer access between CPU and DMA? The below shows that: User(thread a) User(thread b)Kernel - send a src to driver--> update DMA register lock the src request DMA start(1)--> CPU acccess to src unlock the srclock src and dst DMA start <-completion signal(2)- lock dst DMA completion CPU access to dst unlock src and dst unlock DST (1) Try to start DMA operation while CPU is accessing the src buffer. (2) Try CPU access to dst buffer while DMA is accessing the dst buffer. This means that CPU or DMA could do more works. In the same way, we could reduce hand shaking overhead between two processes when those processes need to share a shared buffer. There may be other cases that we could reduce overhead as well. References: [1] http://lwn.net/Articles/470339/ [2] https://patchwork.kernel.org/patch/2625361/ [3] http://linux.die.net/man/2/fcntl Inki Dae (2): [RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization framework [RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call Documentation/dma-buf-sync.txt | 290 + drivers/base/Kconfig |7 + drivers/base/Makefile |1 + drivers/base/dma-buf.c | 37 +++ drivers/base/dmabuf-sync.c | 674 include/linux/dma-buf.h| 16 + include/linux/dmabuf-sync.h| 178 +++ 7 files changed, 1203 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.5.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call
This patch adds lock callback to dma buf file operations,
and this callback will be called by fcntl system call.
With this patch, fcntl system call can be used for buffer
synchronization between CPU and CPU, and CPU and DMA in user mode.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/base/dma-buf.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 9a26981..e1b8583 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -80,9 +80,42 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
return dmabuf->ops->mmap(dmabuf, vma);
}
+static int dma_buf_lock(struct file *file, int cmd, struct file_lock *fl)
+{
+ struct dma_buf *dmabuf;
+ unsigned int type;
+ bool wait = false;
+
+ if (!is_dma_buf_file(file))
+ return -EINVAL;
+
+ dmabuf = file->private_data;
+
+ if ((fl->fl_type & F_UNLCK) == F_UNLCK) {
+ dmabuf_sync_single_unlock(dmabuf);
+ return 0;
+ }
+
+ /* convert flock type to dmabuf sync type. */
+ if ((fl->fl_type & F_WRLCK) == F_WRLCK)
+ type = DMA_BUF_ACCESS_W;
+ else if ((fl->fl_type & F_RDLCK) == F_RDLCK)
+ type = DMA_BUF_ACCESS_R;
+ else
+ return -EINVAL;
+
+ if (fl->fl_flags & FL_SLEEP)
+ wait = true;
+
+ /* TODO. the locking to certain region should also be considered. */
+
+ return dmabuf_sync_single_lock(dmabuf, type, wait);
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
+ .lock = dma_buf_lock,
};
/*
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/nvc0-/gr: shift wrapping bug in nvc0_grctx_generate_r406800()
We care about the upper 32 bits here so we have to use 1ULL instead of 1 to avoid a shift wrapping bug. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c index 64dca26..fe67415 100644 --- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c +++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnvc0.c @@ -1039,7 +1039,7 @@ nvc0_grctx_generate_r406800(struct nvc0_graph_priv *priv) } while (!tpcnr[gpc]); tpc = priv->tpc_nr[gpc] - tpcnr[gpc]--; - tpc_set |= 1 << ((gpc * 8) + tpc); + tpc_set |= 1ULL << ((gpc * 8) + tpc); } nv_wr32(priv, 0x406800 + (i * 0x20), lower_32_bits(tpc_set)); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx
Am 11.07.2013 21:35, schrieb alexdeuc...@gmail.com:
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex Deucher
Well since we have an easy to use alternative, isn't it time to kill off
all the blitter code?
Anyway this patch series is:
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx
Am 11.07.2013 21:59, schrieb Ilija Hadzic:
Alex,
Can you please share some details about the nature or symptom of the
"instability". One problem that I have been seeing on my end is that
when I use the DMA ring intensively (by intensively I mean, calling
the copy function every frame), combined with some 3D rendering that
causes a lot of cs_ioctl calls, that I can provoke a corruption of the
olist field in radeon_sa_bo structure, consequently causing an oops in
radeon_sa_bo_try_free(). I have also found that I can suppress the
problem if I add some padding fields at the beginnig of the
radeon_sa_bo structure (essentially moving the olist field down).
So I speculate that the use of DMA somehow results in corrupting that
structure, but I have not yet done enough experiments to prove or
disprove that theory (so I have not spoke up yet). Also my kernel is
full of my own internal hacks, and I have not yet taken the time to
reproduce the problem with the "stock" kernel. However, after seeing
your patch series, I am wondering if the instability you are referring
to may be of the same or similar nature.
Hi Ilija,
well that's very interesting and no it's quite unlikely that this is
cause by the DMA ring because the radeon_sa_bo structure should be
allocated on system memory and the GPU can usually only access it if you
map it through GART.
Is that easily reproducible for you? Is there already an open bugreport?
Thanks,
Christian.
thanks,
Ilija
On Thu, 11 Jul 2013, alexdeuc...@gmail.com wrote:
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-.copy = &r600_copy_dma,
-.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+.copy = &r600_copy_blit,
+.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-.copy = &r600_copy_dma,
-.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+.copy = &r600_copy_blit,
+.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
-.copy = &r600_copy_dma,
-.copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+.copy = &r600_copy_blit,
+.copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5
___
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: use radeon device for request firmware
Am 11.07.2013 21:53, schrieb j.gli...@gmail.com:
From: Jerome Glisse
Avoid creating temporary platform device that will lead to issue
when several radeon gpu are in same computer. Instead directly use
the radeon device for requesting firmware.
Signed-off-by: Jerome Glisse
Thanks, also had that on my todo list since I wrote the UVD code.
Patchset is: Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/cik.c| 25 +++--
drivers/gpu/drm/radeon/ni.c | 21 +
drivers/gpu/drm/radeon/r100.c | 11 +--
drivers/gpu/drm/radeon/r600.c | 19 ---
drivers/gpu/drm/radeon/radeon_uvd.c | 13 +
drivers/gpu/drm/radeon/si.c | 23 ++-
6 files changed, 24 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index db507a4..b893165 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -22,7 +22,6 @@
* Authors: Alex Deucher
*/
#include
-#include
#include
#include
#include "drmP.h"
@@ -742,7 +741,6 @@ static int ci_mc_load_microcode(struct radeon_device *rdev)
*/
static int cik_init_microcode(struct radeon_device *rdev)
{
- struct platform_device *pdev;
const char *chip_name;
size_t pfp_req_size, me_req_size, ce_req_size,
mec_req_size, rlc_req_size, mc_req_size,
@@ -752,13 +750,6 @@ static int cik_init_microcode(struct radeon_device *rdev)
DRM_DEBUG("\n");
- pdev = platform_device_register_simple("radeon_cp", 0, NULL, 0);
- err = IS_ERR(pdev);
- if (err) {
- printk(KERN_ERR "radeon_cp: Failed to register firmware\n");
- return -EINVAL;
- }
-
switch (rdev->family) {
case CHIP_BONAIRE:
chip_name = "BONAIRE";
@@ -794,7 +785,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
DRM_INFO("Loading %s Microcode\n", chip_name);
snprintf(fw_name, sizeof(fw_name), "radeon/%s_pfp.bin", chip_name);
- err = request_firmware(&rdev->pfp_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->pfp_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->pfp_fw->size != pfp_req_size) {
@@ -806,7 +797,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_me.bin", chip_name);
- err = request_firmware(&rdev->me_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->me_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->me_fw->size != me_req_size) {
@@ -817,7 +808,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_ce.bin", chip_name);
- err = request_firmware(&rdev->ce_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->ce_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->ce_fw->size != ce_req_size) {
@@ -828,7 +819,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_mec.bin", chip_name);
- err = request_firmware(&rdev->mec_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->mec_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->mec_fw->size != mec_req_size) {
@@ -839,7 +830,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_rlc.bin", chip_name);
- err = request_firmware(&rdev->rlc_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->rlc_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->rlc_fw->size != rlc_req_size) {
@@ -850,7 +841,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
snprintf(fw_name, sizeof(fw_name), "radeon/%s_sdma.bin", chip_name);
- err = request_firmware(&rdev->sdma_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->sdma_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->sdma_fw->size != sdma_req_size) {
@@ -863,7 +854,7 @@ static int cik_init_microcode(struct radeon_device *rdev)
/* No MC ucode on APUs */
if (!(rdev->flags & RADEON_IS_IGP)) {
snprintf(fw_name, sizeof(fw_name), "radeon/%s_mc.bin",
chip_name);
- err = request_firmware(&rdev->mc_fw, fw_name, &pdev->dev);
+ err = request_firmware(&rdev->mc_fw, fw_name, rdev->dev);
if (err)
goto out;
if (rdev->mc_fw->size != mc_req_size) {
@@ -875,8 +866,6 @@ static int cik_init_microcode(struct radeon_device *rdev)
}
out:
- platform_device_unregister(pdev);
-
if (err) {
if (err != -EINVAL)
[PATCH 0/2] Anonymous Inode Allocations
Hi This implements anon_inodes_new() to create anonymous inodes. Patch #1 describes the changes to anon_inodes.c and why DRM could make great use of this. Patch #2 converts DRM core to use anon_inodes_new() instead of delayed dev_mapping initialization (but kept simple, TTM can be converted later). The idea is to get an anonymous backing inode for DRM devices without waiting for the first char-dev inode. We use it to unmap userspace mappings via unmap_mapping_range() if we have to evict buffers if GTT runs short or if the FW framebuffers are destroyed. We need the inode only once the first user-space mapping was created, but the delayed initialization causes an ugly code base and keeps inodes of char-devs around just to preserve the address_space. We actually only need the address_space, but mm core requires an corresponding file* and FS core requires mapping->host to be set (although I am not sure whether we can hit those paths with char-devs). So I went with the whole anonymous inode approach. If anyone has an idea how to use an embedded "struct address_space" inside of "drm_device" and set "dev_mapping->host" to the shared anon_inode_inode, I'd be happy to implement it. However, I didn't succeed and I am actually not sure that separate "struct address_space" are actually supported. For instance, DRM core uses code like: container_of(dev_mapping, struct inode, i_data) So I didn't spent much time on that approach. Cheers David David Herrmann (2): anon_inodes: allow external inode allocations DRM: use anon_inode instead of delayed inode init drivers/gpu/drm/drm_drv.c | 1 - drivers/gpu/drm/drm_fops.c | 24 +++ drivers/gpu/drm/drm_stub.c | 12 +++- drivers/gpu/drm/i915/i915_gem.c| 4 ++-- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 7 --- drivers/gpu/drm/qxl/qxl_object.c | 2 +- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 +- fs/anon_inodes.c | 36 +++--- include/drm/drmP.h | 2 +- include/linux/anon_inodes.h| 1 + 14 files changed, 57 insertions(+), 42 deletions(-) -- 1.8.3.2
[PATCH 1/2] anon_inodes: allow external inode allocations
DRM core shares a single address_space across all inodes that belong to
the same DRM device. This allows efficient unmapping of user-space
mappings during buffer destruction. However, there is no easy way to get a
shared address_space for DRM devices during initialization. Therefore, we
currently delay this step until the first ->open() and save the given
inode for future use.
This causes ugly delayed initialization throughout the DRM core. TTM
devices end up without a dev_mapping pointer and we have to carefully
respect any underlying filesystem implementation so we don't corrupt the
inode->i_mapping and inode->i_data fields.
We can avoid this if we were allowed to allocate an anonymous inode for
each DRM device. We only have to set file->f_mapping during ->open()
and no longer need to adjust inode mappings. As fs/anon_inodes.c already
provides a minimal internal FS mount, we extend it to also provide
anonymous inodes for use in drivers like DRM.
Signed-off-by: David Herrmann
---
fs/anon_inodes.c| 36 +---
include/linux/anon_inodes.h | 1 +
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 47a65df..7d8a80a 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -25,6 +25,7 @@
static struct vfsmount *anon_inode_mnt __read_mostly;
static struct inode *anon_inode_inode;
static const struct file_operations anon_inode_fops;
+static struct dentry *anon_inode_root;
/*
* anon_inodefs_dname() is called from d_path().
@@ -87,19 +88,18 @@ static struct inode *anon_inode_mkinode(struct super_block
*s)
static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
int flags, const char *dev_name, void *data)
{
- struct dentry *root;
- root = mount_pseudo(fs_type, "anon_inode:", NULL,
+ anon_inode_root = mount_pseudo(fs_type, "anon_inode:", NULL,
&anon_inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
- if (!IS_ERR(root)) {
- struct super_block *s = root->d_sb;
+ if (!IS_ERR(anon_inode_root)) {
+ struct super_block *s = anon_inode_root->d_sb;
anon_inode_inode = anon_inode_mkinode(s);
if (IS_ERR(anon_inode_inode)) {
- dput(root);
+ dput(anon_inode_root);
deactivate_locked_super(s);
- root = ERR_CAST(anon_inode_inode);
+ anon_inode_root = ERR_CAST(anon_inode_inode);
}
}
- return root;
+ return anon_inode_root;
}
static struct file_system_type anon_inode_fs_type = {
@@ -219,6 +219,28 @@ err_put_unused_fd:
}
EXPORT_SYMBOL_GPL(anon_inode_getfd);
+/**
+ * anon_inode_new - create private anonymous inode
+ *
+ * Creates a new inode on the anonymous inode FS for driver's use. The inode
has
+ * it's own address_space compared to the shared anon_inode_inode. It can be
+ * used in situations where user-space mappings have to be shared across
+ * different files but no backing inode is available.
+ *
+ * Call iput(inode) to release the inode.
+ *
+ * RETURNS:
+ * New inode on success, error pointer on failure.
+ */
+struct inode *anon_inode_new(void)
+{
+ if (IS_ERR(anon_inode_root))
+ return ERR_CAST(anon_inode_root);
+
+ return anon_inode_mkinode(anon_inode_root->d_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
static int __init anon_inode_init(void)
{
int error;
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
int anon_inode_getfd(const char *name, const struct file_operations *fops,
void *priv, int flags);
+struct inode *anon_inode_new(void);
#endif /* _LINUX_ANON_INODES_H */
--
1.8.3.2
[PATCH 2/2] DRM: use anon_inode instead of delayed inode init
Instead of delaying inode initialization until first ->open(), we can use
an anonymous inode. This avoids modifying FS internal inode fields and
provides us a private address_space right during initialization.
Delayed TTM dev_mapping initialization is currently left untouched to keep
this simple. But we could now safely provide the address_space during
ttm_bo_device_init() instead of delaying until first buffer ->mmap().
Note that this also fixes several bugs:
- We currently call iput(container_of(..dev_mapping..)) before
drm_lastclose(), but we reset dev_mapping to zero at the end of
drm_lastclose(). This fails if dev_mapping points to an address_space
other than the current inode and the char-dev got already removed.
- We also drop dev_mapping during any drm_lastclose() call. So if
user-space still has VMAs to our buffers, we will be unable to unmap
them if the next ->firstopen() is on another inode. dev_mapping will
then point to a new address_space and we leak mappings that we no
longer control.
- We ignore inode->i_mapping completely. It is unlikely that a FS uses it
to overwrite inode->i_data for char-devs, but it definitely doesn't
look very nice to ignore it silently.
Regarding legacy drivers: We no longer reset the address_space during
drm_lastclose() to avoid re-allocating inodes all the time. However,
legacy UMS drivers are weird and it is not clear to me whether some of the
old drivers might depend on this (for what reason?), but I remember Daniel
told me that i810 might.
Tested with nouveau on x86_64.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 1 -
drivers/gpu/drm/drm_fops.c | 24 +++-
drivers/gpu/drm/drm_stub.c | 12 +++-
drivers/gpu/drm/i915/i915_gem.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 7 ---
drivers/gpu/drm/qxl/qxl_object.c | 2 +-
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 +-
include/drm/drmP.h | 2 +-
12 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 99fcd7c..9797613 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
!drm_core_check_feature(dev, DRIVER_MODESET))
drm_dma_takedown(dev);
- dev->dev_mapping = NULL;
mutex_unlock(&dev->struct_mutex);
DRM_DEBUG("lastclose completed\n");
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 3a24385..6752f59 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
struct drm_minor *minor;
int retcode = 0;
int need_setup = 0;
- struct address_space *old_mapping;
- struct address_space *old_imapping;
minor = idr_find(&drm_minors_idr, minor_id);
if (!minor)
@@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)
if (!dev->open_count++)
need_setup = 1;
- mutex_lock(&dev->struct_mutex);
- old_imapping = inode->i_mapping;
- old_mapping = dev->dev_mapping;
- if (old_mapping == NULL)
- dev->dev_mapping = &inode->i_data;
- /* ihold ensures nobody can remove inode with our i_data */
- ihold(container_of(dev->dev_mapping, struct inode, i_data));
- inode->i_mapping = dev->dev_mapping;
- filp->f_mapping = dev->dev_mapping;
- mutex_unlock(&dev->struct_mutex);
+
+ /* set address_space for shared mappings */
+ filp->f_mapping = dev->anon_inode->i_mapping;
retcode = drm_open_helper(inode, filp, dev);
if (retcode)
@@ -160,12 +151,6 @@ int drm_open(struct inode *inode, struct file *filp)
return 0;
err_undo:
- mutex_lock(&dev->struct_mutex);
- filp->f_mapping = old_imapping;
- inode->i_mapping = old_imapping;
- iput(container_of(dev->dev_mapping, struct inode, i_data));
- dev->dev_mapping = old_mapping;
- mutex_unlock(&dev->struct_mutex);
dev->open_count--;
return retcode;
}
@@ -543,9 +528,6 @@ int drm_release(struct inode *inode, struct file *filp)
}
}
- BUG_ON(dev->dev_mapping == NULL);
- iput(container_of(dev->dev_mapping, struct inode, i_data));
-
/* drop the reference held my the file priv */
drm_master_put(&file_priv->master);
file_priv->is_master = 0;
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 327ca19..45804f1 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -31,6 +31,7 @@
* DEALINGS IN THE SOFTWARE.
*/
+
[PATCH] drm: remove FASYNC support
Hi Daniel,
Thank you for the patch.
On Wednesday 10 July 2013 17:25:04 Daniel Vetter wrote:
> So I've stumbled over drm_fasync and wondered what it does. Digging
> that up is quite a story.
>
> First I've had to read up on what this does and ended up being rather
> bewildered why peopled loved signals so much back in the days that
> they've created SIGIO just for that ...
>
> Then I wondered how this ever works, and what that strange "No-op."
> comment right above it should mean. After all calling the core fasync
> helper is pretty obviously not a noop. After reading through the
> kernels FASYNC implementation I've noticed that signals are only sent
> out to the processes attached with FASYNC by calling kill_fasync.
>
> No merged drm driver has ever done that.
>
> After more digging I've found out that the only driver that ever used
> this is the so called GAMMA driver. I've frankly never heard of such a
> gpu brand ever before. Now FASYNC seems to not have been the only bad
> thing with that driver, since Dave Airlie removed it from the drm
> driver with prejudice:
>
> commit 1430163b4bbf7b00367ea1066c1c5fe85dbeefed
> Author: Dave Airlie
> Date: Sun Aug 29 12:04:35 2004 +
>
> Drop GAMMA DRM from a great height ...
>
> Long story short, the drm fasync support seems to be doing absolutely
> nothing. And the only user of it was never merged into the upstream
> kernel. And we don't need any fops->fasync callback since the fcntl
> implementation in the kernel already implements the noop case
> correctly.
>
> So stop this particular cargo-cult and rip it all out.
>
> v2: Kill drm_fasync assignments in rcar (newly added) and imx drivers
> (somehow I've missed that one in staging). Also drop the reference in
> the drm DocBook. ARM compile-fail reported by Rob Clark.
>
> v3: Move the removal of dev->buf_asnyc assignment in drm_setup to this
> patch here.
>
> v4: Actually git add ... tsk.
>
> Cc: Dave Airlie
> Cc: Laurent Pinchart
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
Acked-by: Laurent Pinchart
> ---
> Documentation/DocBook/drm.tmpl | 1 -
> drivers/gpu/drm/ast/ast_drv.c| 1 -
> drivers/gpu/drm/cirrus/cirrus_drv.c | 1 -
> drivers/gpu/drm/drm_fops.c | 14 --
> drivers/gpu/drm/gma500/psb_drv.c | 1 -
> drivers/gpu/drm/i810/i810_dma.c | 1 -
> drivers/gpu/drm/i810/i810_drv.c | 1 -
> drivers/gpu/drm/i915/i915_drv.c | 1 -
> drivers/gpu/drm/mga/mga_drv.c| 1 -
> drivers/gpu/drm/mgag200/mgag200_drv.c| 1 -
> drivers/gpu/drm/nouveau/nouveau_drm.c| 1 -
> drivers/gpu/drm/omapdrm/omap_drv.c | 1 -
> drivers/gpu/drm/qxl/qxl_drv.c| 1 -
> drivers/gpu/drm/r128/r128_drv.c | 1 -
> drivers/gpu/drm/radeon/radeon_drv.c | 2 --
> drivers/gpu/drm/rcar-du/rcar_du_drv.c| 1 -
> drivers/gpu/drm/savage/savage_drv.c | 1 -
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 -
> drivers/gpu/drm/sis/sis_drv.c| 1 -
> drivers/gpu/drm/tdfx/tdfx_drv.c | 1 -
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 -
> drivers/gpu/drm/udl/udl_drv.c| 1 -
> drivers/gpu/drm/via/via_drv.c| 1 -
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
> drivers/gpu/host1x/drm/drm.c | 1 -
> drivers/staging/imx-drm/imx-drm-core.c | 1 -
> include/drm/drmP.h | 3 ---
> 27 files changed, 43 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..79dd70e 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2498,7 +2498,6 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
> .poll = drm_poll,
> .read = drm_read,
> - .fasync = drm_fasync,
> .llseek = no_llseek,
>
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index df0d0a0..16050ed 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -190,7 +190,6 @@ static const struct file_operations ast_fops = {
> .unlocked_ioctl = drm_ioctl,
> .mmap = ast_mmap,
> .poll = drm_poll,
> - .fasync = drm_fasync,
> #ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> #endif
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
> b/drivers/gpu/drm/cirrus/cirrus_drv.c index 8ecb601..85748f6 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
> @@ -85,7 +85,6 @@ static const struct file_operations cirrus_driver_fops = {
> #ifdef CONFIG_COMPAT
> .compat_ioctl = drm_compat_ioctl,
> #endif
> - .fasync = drm_fasync,
> };
> static struct drm_driver driver = {
> .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_USE_MTRR,
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 14e0bb6..d1b4771 100644
> --- a/drivers/gpu/drm/dr
Questions about TTM buffer object maping
Hello, I'm trying to understand how TTM buffer object mapping works on Linux, to make this behave properly on FreeBSD. Here's what I think I understand: When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's a page fault, the page is looked up and inserted in the VMA using vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is called, which drops a reference. When the last reference is dropped, the buffer object is destroyed. What's still not clear to me is how munmap() works here. After talking about this on IRC with some people, I think that unmap_mapping_range() (called by ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from userland. Is that true? When a buffer object is moved, what happens to the mapping? In particular, I see in ttm_bo_move_accel_cleanup() that the ttm structure can be transferred to ghost_obj, which is destroyed shortly after. This ends up in ttm_put_pages() which uses __free_page(), for each page of the buffer object. At this stage, is the ghost object already munmap()'d? Or does __free_page() unmap a page implicitly (ie. remove it from VMA)? Sorry if my questions are stupid, I'm rather new to memory management. -- Jean-S?bastien P?dron
[Bug 66558] RS690: 3D artifacts when playing SuperTuxKart
https://bugs.freedesktop.org/show_bug.cgi?id=66558 Bj?rn Beutel changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/9beefb45/attachment.html>
[Bug 65723] Xonotic glsl 1.30 broken due to lack of derivatives support in radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=65723 --- Comment #7 from Rafael Castillo --- tested and working, many thanks for your hard work -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d1bdd6f9/attachment.html>
Questions about TTM buffer object maping
On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote: > On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron > wrote: > > Hello, > > > > I'm trying to understand how TTM buffer object mapping works on Linux, to > > make this behave properly on FreeBSD. > > > > Here's what I think I understand: > > > > When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's a > > page fault, the page is looked up and inserted in the VMA using > > vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is > > called, which drops a reference. When the last reference is dropped, the > > buffer object is destroyed. > > > > What's still not clear to me is how munmap() works here. After talking about > > this on IRC with some people, I think that unmap_mapping_range() (called by > > ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from > > userland. Is that true? > > Yes that's true. Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma. So not equivalent to a munmap from userspace. It simply allows us to intercept the next access in the page fault handler and move the buffer back into place. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/2] anon_inodes: allow external inode allocations
On Thu, Jul 11, 2013 at 01:45:29AM +0200, David Herrmann wrote:
> DRM core shares a single address_space across all inodes that belong to
> the same DRM device. This allows efficient unmapping of user-space
> mappings during buffer destruction. However, there is no easy way to get a
> shared address_space for DRM devices during initialization. Therefore, we
> currently delay this step until the first ->open() and save the given
> inode for future use.
Quick correction for the drm use-case: We don't need the address space at
buffer destruction, since each vma holds a reference to the backing gem
object. So buffer destruction can only happen once there's guaranteed to
be no mmapping around any more.
But we make extensive use of the address_space to shoot down ptes with
unmap_mapping_range before we evict a buffer from the mmio gart. In the
page fault handler we can then move the buffer object back to a place
userspace can get at it and set up new ptes.
> This causes ugly delayed initialization throughout the DRM core. TTM
> devices end up without a dev_mapping pointer and we have to carefully
> respect any underlying filesystem implementation so we don't corrupt the
> inode->i_mapping and inode->i_data fields.
>
> We can avoid this if we were allowed to allocate an anonymous inode for
> each DRM device. We only have to set file->f_mapping during ->open()
> and no longer need to adjust inode mappings. As fs/anon_inodes.c already
> provides a minimal internal FS mount, we extend it to also provide
> anonymous inodes for use in drivers like DRM.
>
> Signed-off-by: David Herrmann
I'm not an fs guy so no comment on the patch itself, but having an
inode/address space available at driver load time will allow us to get rid
of tons of ulgy
if (dev_mapping)
unmap_mapping_rang(dev_mapping, ...);
code sprinkled all over drm core and drivers. So
Wanted-by: Daniel Vetter
> ---
> fs/anon_inodes.c| 36 +---
> include/linux/anon_inodes.h | 1 +
> 2 files changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
> index 47a65df..7d8a80a 100644
> --- a/fs/anon_inodes.c
> +++ b/fs/anon_inodes.c
> @@ -25,6 +25,7 @@
> static struct vfsmount *anon_inode_mnt __read_mostly;
> static struct inode *anon_inode_inode;
> static const struct file_operations anon_inode_fops;
> +static struct dentry *anon_inode_root;
>
> /*
> * anon_inodefs_dname() is called from d_path().
> @@ -87,19 +88,18 @@ static struct inode *anon_inode_mkinode(struct
> super_block *s)
> static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
> int flags, const char *dev_name, void *data)
> {
> - struct dentry *root;
> - root = mount_pseudo(fs_type, "anon_inode:", NULL,
> + anon_inode_root = mount_pseudo(fs_type, "anon_inode:", NULL,
> &anon_inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
> - if (!IS_ERR(root)) {
> - struct super_block *s = root->d_sb;
> + if (!IS_ERR(anon_inode_root)) {
> + struct super_block *s = anon_inode_root->d_sb;
> anon_inode_inode = anon_inode_mkinode(s);
> if (IS_ERR(anon_inode_inode)) {
> - dput(root);
> + dput(anon_inode_root);
> deactivate_locked_super(s);
> - root = ERR_CAST(anon_inode_inode);
> + anon_inode_root = ERR_CAST(anon_inode_inode);
> }
> }
> - return root;
> + return anon_inode_root;
> }
>
> static struct file_system_type anon_inode_fs_type = {
> @@ -219,6 +219,28 @@ err_put_unused_fd:
> }
> EXPORT_SYMBOL_GPL(anon_inode_getfd);
>
> +/**
> + * anon_inode_new - create private anonymous inode
> + *
> + * Creates a new inode on the anonymous inode FS for driver's use. The inode
> has
> + * it's own address_space compared to the shared anon_inode_inode. It can be
> + * used in situations where user-space mappings have to be shared across
> + * different files but no backing inode is available.
> + *
> + * Call iput(inode) to release the inode.
> + *
> + * RETURNS:
> + * New inode on success, error pointer on failure.
> + */
> +struct inode *anon_inode_new(void)
> +{
> + if (IS_ERR(anon_inode_root))
> + return ERR_CAST(anon_inode_root);
> +
> + return anon_inode_mkinode(anon_inode_root->d_sb);
> +}
> +EXPORT_SYMBOL_GPL(anon_inode_new);
> +
> static int __init anon_inode_init(void)
> {
> int error;
> diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
> index 8013a45..ddbd67f 100644
> --- a/include/linux/anon_inodes.h
> +++ b/include/linux/anon_inodes.h
> @@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
> void *priv, int flags);
> int anon_inode_getfd(const char *name, const struct file_operations *fops,
>void *p
[PATCH 2/2] DRM: use anon_inode instead of delayed inode init
On Thu, Jul 11, 2013 at 01:45:30AM +0200, David Herrmann wrote:
> Instead of delaying inode initialization until first ->open(), we can use
> an anonymous inode. This avoids modifying FS internal inode fields and
> provides us a private address_space right during initialization.
>
> Delayed TTM dev_mapping initialization is currently left untouched to keep
> this simple. But we could now safely provide the address_space during
> ttm_bo_device_init() instead of delaying until first buffer ->mmap().
>
> Note that this also fixes several bugs:
> - We currently call iput(container_of(..dev_mapping..)) before
>drm_lastclose(), but we reset dev_mapping to zero at the end of
>drm_lastclose(). This fails if dev_mapping points to an address_space
>other than the current inode and the char-dev got already removed.
> - We also drop dev_mapping during any drm_lastclose() call. So if
>user-space still has VMAs to our buffers, we will be unable to unmap
>them if the next ->firstopen() is on another inode. dev_mapping will
>then point to a new address_space and we leak mappings that we no
>longer control.
It's certainly ugly, but I don't think we have a real problem here. vma
grabs a reference to the open file at mmap time and we grab a reference to
the underlying gem object. So it shouldn't be possible to observe a
non-NULL dev_mapping while the inode refcount has already reached 0
anywhere we actually care. At least in drm/i915 since we never call
unmap_mapping_range if we know that there's no ptes around pointing at
this specific object (which we accurately keep track of in our fault
handler).
TTM might be different, and it's certainly good to rid us of this code.
> - We ignore inode->i_mapping completely. It is unlikely that a FS uses it
>to overwrite inode->i_data for char-devs, but it definitely doesn't
>look very nice to ignore it silently.
Tbh I have no idea what the rules are here ... But since core vfs code
uses the filp->f_mapping at mmap time not frobbing inode->i_mapping looks
like the sane to do.
> Regarding legacy drivers: We no longer reset the address_space during
> drm_lastclose() to avoid re-allocating inodes all the time. However,
> legacy UMS drivers are weird and it is not clear to me whether some of the
> old drivers might depend on this (for what reason?), but I remember Daniel
> told me that i810 might.
i915 in gem+ums mode might. i810 is a different level of horror show
entirely, but since it doesn't do gem we can ignore it here.
>
> Tested with nouveau on x86_64.
>
> Signed-off-by: David Herrmann
Reviewed-by: Daniel Vetter
I guess it makes sense to merge that after your drm vma offset manager
changes with the little pte shootdown helper since that'll reduce the
diff?
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 1 -
> drivers/gpu/drm/drm_fops.c | 24 +++-
> drivers/gpu/drm/drm_stub.c | 12 +++-
> drivers/gpu/drm/i915/i915_gem.c| 4 ++--
> drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_gem.c | 7 ---
> drivers/gpu/drm/qxl/qxl_object.c | 2 +-
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> drivers/gpu/drm/radeon/radeon_object.c | 2 +-
> drivers/gpu/drm/radeon/radeon_ttm.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 +-
> include/drm/drmP.h | 2 +-
> 12 files changed, 27 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 99fcd7c..9797613 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -232,7 +232,6 @@ int drm_lastclose(struct drm_device * dev)
> !drm_core_check_feature(dev, DRIVER_MODESET))
> drm_dma_takedown(dev);
>
> - dev->dev_mapping = NULL;
> mutex_unlock(&dev->struct_mutex);
>
> DRM_DEBUG("lastclose completed\n");
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 3a24385..6752f59 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -122,8 +122,6 @@ int drm_open(struct inode *inode, struct file *filp)
> struct drm_minor *minor;
> int retcode = 0;
> int need_setup = 0;
> - struct address_space *old_mapping;
> - struct address_space *old_imapping;
>
> minor = idr_find(&drm_minors_idr, minor_id);
> if (!minor)
> @@ -137,16 +135,9 @@ int drm_open(struct inode *inode, struct file *filp)
>
> if (!dev->open_count++)
> need_setup = 1;
> - mutex_lock(&dev->struct_mutex);
> - old_imapping = inode->i_mapping;
> - old_mapping = dev->dev_mapping;
> - if (old_mapping == NULL)
> - dev->dev_mapping = &inode->i_data;
> - /* ihold ensures nobody can remove inode with our i_data */
> - ihold(container_of(dev->dev_mapping, struct inode, i_data));
> - inode->i_mapping = dev->dev_mapping;
> - filp->f_map
Bug in warning message from MTRR rework in uvesafb
On Thu, Jul 11, 2013 at 3:36 AM, Andy Lutomirski wrote:
> On Wed, Jul 10, 2013 at 10:07 AM, Torsten Kaiser
> wrote:
>> Commit 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75, "uvesafb: Clean up
>> MTRR code" contains the following change:
>>
>> @@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
>> }
>> }
>>
>> +if (mtrr != 3 && mtrr != 1)
>> +pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is
>> unsupported", mtrr);
>> +
>> return 0;
>> }
>> #endif /* !MODULE */
>>
>> Shouldn't this be && mtrr != 0?
>
> Indeed, and Sylvain Hitier (cc'd) sent a patch (off-list) that must
> have gotten lost somewhere.
>
Yeah I should get an email reply thing for off-list stuff, as its even
more likely I'll lose it.
Dave.
Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
Dear Linux folks, using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged and built with `make deb-pkg`, it failed the last boot. [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). The strange thing is that it worked the last time I tried with the same Linux kernel image as I posted to the list [1]. I just booted an old 3.2.46 distribution Linux in between. (And it looked like the modesetting did not work when doing so. But I did not look further into it.) $ uname -a Linux myhostname 3.10.0+ #105 SMP Sat Jul 6 13:33:47 CEST 2013 i686 GNU/Linux $ lspci -s 01.0 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] $ md5sum /lib/firmware/3.10.0+/radeon/SUMO_uvd.bin 51d9e0e2247c313c5bfc8fa7bb5b213d /lib/firmware/3.10.0+/radeon/SUMO_uvd.bin $ cut -d " " -f 6- /var/log/kern.log [?] [0.152534] calling trace_init_flags_sys_exit+0x0/0xd @ 1 [0.152540] initcall trace_init_flags_sys_exit+0x0/0xd returned 0 after 0 usecs [0.152545] calling trace_init_flags_sys_enter+0x0/0xd @ 1 [0.152550] initcall trace_init_flags_sys_enter+0x0/0xd returned 0 after 0 usecs [0.152555] calling init_hw_perf_events+0x0/0x47e @ 1 [0.152557] Performance Events: AMD PMU driver. [0.152565] ... version:0 [0.152567] ... bit width: 48 [0.152569] ... generic registers: 4 [0.152572] ... value mask: [0.152575] ... max period: 7fff [0.152577] ... fixed-purpose events: 0 [0.152580] ... event mask: 000f [0.152597] initcall init_hw_perf_events+0x0/0x47e returned 0 after 0 usecs [0.152603] calling register_trigger_all_cpu_backtrace+0x0/0xf @ 1 [0.152609] initcall register_trigger_all_cpu_backtrace+0x0/0xf returned 0 after 0 usecs [0.152615] calling spawn_ksoftirqd+0x0/0x1d @ 1 [0.152657] initcall spawn_ksoftirqd+0x0/0x1d returned 0 after 0 usecs [0.152662] calling init_workqueues+0x0/0x289 @ 1 [0.152800] initcall init_workqueues+0x0/0x289 returned 0 after 0 usecs [0.152805] calling check_cpu_stall_init+0x0/0x12 @ 1 [0.152810] initcall check_cpu_stall_init+0x0/0x12 returned 0 after 0 usecs [0.152814] calling migration_init+0x0/0x55 @ 1 [0.152820] initcall migration_init+0x0/0x55 returned 0 after 0 usecs [0.152826] calling cpu_stop_init+0x0/0x57 @ 1 [0.152863] initcall cpu_stop_init+0x0/0x57 returned 0 after 0 usecs [0.152868] calling rcu_register_oom_notifier+0x0/0xd @ 1 [0.152874] initcall rcu_register_oom_notifier+0x0/0xd returned 0 after 0 usecs [0.152879] calling rcu_scheduler_really_started+0x0/0xd @ 1 [0.152883] initcall rcu_scheduler_really_started+0x0/0xd returned 0 after 0 usecs [0.152888] calling rcu_spawn_gp_kthread+0x0/0x6b @ 1 [0.152936] initcall rcu_spawn_gp_kthread+0x0/0x6b returned 0 after 0 usecs [0.152941] calling relay_init+0x0/0xd @ 1 [0.152946] initcall relay_init+0x0/0xd returned 0 after 0 usecs [0.152950] calling tracer_alloc_buffers+0x0/0x18b @ 1 [0.153030] initcall tracer_alloc_buffers+0x0/0x18b returned 0 after 0 usecs [0.153034] calling init_events+0x0/0x57 @ 1 [0.153041] initcall init_events+0x0/0x57 returned 0 after 0 usecs [0.153046] calling init_trace_printk+0x0/0xa @ 1 [0.153051] initcall init_trace_printk+0x0/0xa returned 0 after 0 usecs [0.153055] calling event_trace_memsetup+0x0/0x4a @ 1 [0.153067] initcall event_trace_memsetup+0x0/0x4a returned 0 after 0 usecs [0.153158] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter. [0.153361] CPU 1 irqstacks, hard=f40ae000 soft=f40b [0.153365] smpboot: Booting Node 0, Processors #1 OK [0.163398] Initializing CPU#1 [0.166591] Brought up 2 CPUs [0.166596] smpboot: Total of 2 processors activated (6399.62 BogoMIPS) [0.168897] devtmpfs: initialized [0.169277] calling ipc_ns_init+0x0/0xd @ 1 [0.169284] initcall ipc_ns_init+0x0/0xd returned 0 after 0 usecs [0.169289] calling init_mmap_min_addr+0x0/0xd @ 1 [0.169294] initcall init_mmap_min_addr+0x0/0xd returned 0 after 0 usecs [0.169302] calling init_cpufreq_transition_notifier_list+0x0/0x14 @ 1 [0.169315] initcall init_cpufreq_transition_notifier_list+0x0/0x14 returned 0 after 0 usecs [0.169320] calling net_ns_init+0x0/0xca @ 1 [
[PATCH] drm: don't call ->firstopen for KMS drivers
Hi Daniel,
On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces the complexity of the drm core -> driver interface a
> notch.
>
> v2: Don't forget to update DocBook.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl | 2 ++
> drivers/gpu/drm/drm_fops.c | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..0e8a5a3 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
> The firstopen method is called by the DRM
> core when an application opens a device that has no other opened file
> handle.
> + Not that this callback is only called for legacy ums drm drivers, not
> + for drm drivers that implement modesetting in the kernel.
> Similarly the lastclose method is called when
> the last application holding a file handle opened on the device closes
> it. Both methods are mostly used for UMS (User Mode Setting) drivers to
What about
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7d1278e..afa8d40 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct drm_file
*);
The firstopen method is called by the DRM core
- when an application opens a device that has no other opened file handle.
- Similarly the lastclose method is called when
- the last application holding a file handle opened on the device closes
- it. Both methods are mostly used for UMS (User Mode Setting) drivers to
- acquire and release device resources which should be done in the
- load and unload
- methods for KMS drivers.
+ for legacy UMS (User Mode Setting) drivers only when an application
+ opens a device that has no other opened file handle. UMS drivers can
+ implement it to acquire device resources. KMS drivers can't use the
+ method and must acquire resources in the load
+ method instead.
-Note that the lastclose method is also called
- at module unload time or, for hot-pluggable devices, when the device is
- unplugged. The firstopen and
+ Similarly the lastclose method is called when
+ the last application holding a file handle opened on the device closes
+ it, for both UMS and KMS drivers. Additionally, the method is also
+ called at module unload time or, for hot-pluggable devices, when the
+ device is unplugged. The firstopen and
lastclose calls can thus be unbalanced.
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 57e3014..fcde7d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
> int i;
> int ret;
>
> - if (dev->driver->firstopen) {
> + if (dev->driver->firstopen &&
> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
> ret = dev->driver->firstopen(dev);
> if (ret != 0)
> return ret;
--
Regards,
Laurent Pinchart
[PATCH] drm/prime: remove cargo-cult locking from map_sg helper
Hi Daniel,
Thanks for the patch.
On Wednesday 10 July 2013 16:48:45 Daniel Vetter wrote:
> I've checked both implementations (radeon/nouveau) and they both grab
> the page array from ttm simply by dereferencing it and then wrapping
> it up with drm_prime_pages_to_sg in the callback and map it with
> dma_map_sg (in the helper).
>
> Only the grabbing of the underlying page array is anything we need to
> be concerned about, and either those pages are pinned independently,
> or we're screwed no matter what.
>
> And indeed, nouveau/radeon pin the backing storage in their
> attach/detach functions.
>
> Since I've created this patch cma prime support for dma_buf was added.
> drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
> the sg table with dma_get_sgtable. It doesn't touch any gem object
> state otherwise. So the cma helpers also look safe.
>
> The only thing we might claim it does is prevent concurrent mapping of
> dma_buf attachments. But a) that's not allowed and b) the current code
> is racy already since it checks whether the sg mapping exists _before_
> grabbing the lock.
>
> So the dev->struct_mutex locking here does absolutely nothing useful,
> but only distracts. Remove it.
>
> This should also help Maarten's work to eventually pin the backing
> storage more dynamically by preventing locking inversions around
> dev->struct_mutex.
>
> v2: Add analysis for recently added cma helper prime code.
>
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_prime.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 85e450e..64a99b3 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -167,8 +167,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach, if (WARN_ON(prime_attach->dir != DMA_NONE))
> return ERR_PTR(-EBUSY);
>
> - mutex_lock(&obj->dev->struct_mutex);
> -
> sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
>
> if (!IS_ERR(sgt)) {
> @@ -182,7 +180,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach, }
> }
>
> - mutex_unlock(&obj->dev->struct_mutex);
> return sgt;
> }
--
Regards,
Laurent Pinchart
[Bug 66805] [radeonsi] half life 2 base games are segfaulting
https://bugs.freedesktop.org/show_bug.cgi?id=66805 --- Comment #1 from Michel D?nzer --- Can you provide the output from running with the environment variable RADEON_DUMP_SHADERS=1 ? Beware that it might be large if the game compiles many shaders before the failure. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/4881a8a5/attachment.html>
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 Christian K?nig changed: What|Removed |Added Attachment #81770|0 |1 is obsolete|| Attachment #82190|0 |1 is obsolete|| Attachment #82194|0 |1 is obsolete|| Attachment #82196|0 |1 is obsolete|| Attachment #82198|0 |1 is obsolete|| Attachment #82226|0 |1 is obsolete|| Attachment #82304|0 |1 is obsolete|| --- Comment #20 from Christian K?nig --- Created attachment 82325 --> https://bugs.freedesktop.org/attachment.cgi?id=82325&action=edit Possible fix. I was able to reproduce the problem, and this patch (only a slightly modified version of the old one) seems to fix it for me. Please retest and provide new dmesg logs (as far as that is possible). Also please try it a couple of times, cause at least on my test system suspend/resume on 3.10 seems to be a bit unstable (even without the radeon driver). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f4ee69c8/attachment.html>
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 --- Comment #21 from Austin Lund --- (In reply to comment #20) > Created attachment 82325 [details] [review] > Possible fix. > > I was able to reproduce the problem, and this patch (only a slightly > modified version of the old one) seems to fix it for me. > > Please retest and provide new dmesg logs (as far as that is possible). > > Also please try it a couple of times, cause at least on my test system > suspend/resume on 3.10 seems to be a bit unstable (even without the radeon > driver). I got this compile warning: /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function ?radeon_uvd_fini?: /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning: ?return? with a value, in function returning void [enabled by default] return 0; ^ Haven't had a chance to test just yet. Will report back as soon as possible. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/ed0c8033/attachment.html>
[Bug 66805] [radeonsi] half life 2 base games are segfaulting
https://bugs.freedesktop.org/show_bug.cgi?id=66805 --- Comment #2 from Laurent carlier --- Created attachment 82327 --> https://bugs.freedesktop.org/attachment.cgi?id=82327&action=edit shader dump from portal with RADEON_DUMP_SHADERS=1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/5a7a6ce4/attachment-0001.html>
[PATCH 1/2] drm/gem: simplify object initialization
drm_gem_object_init() and drm_gem_private_object_init() do exactly the
same (except for shmem alloc) so make the first use the latter to reduce
code duplication.
Also drop the return code from drm_gem_private_object_init(). It seems
unlikely that we will extend it any time soon so no reason to keep it
around. This simplifies code paths in drivers, too.
Last but not least, fix gma500 to call drm_gem_object_release() before
freeing objects that were allocated via drm_gem_private_object_init().
That isn't actually necessary for now, but might be in the future.
Cc: Patrik Jakobsson
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_gem.c | 20
drivers/gpu/drm/gma500/framebuffer.c | 6 ++
drivers/gpu/drm/gma500/gem.c | 7 ---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
include/drm/drmP.h | 4 ++--
7 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 603f256..1ad9e7e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
- BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+ struct file *filp;
- obj->dev = dev;
- obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
- if (IS_ERR(obj->filp))
- return PTR_ERR(obj->filp);
+ filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
+ if (IS_ERR(filp))
+ return PTR_ERR(filp);
- kref_init(&obj->refcount);
- atomic_set(&obj->handle_count, 0);
- obj->size = size;
+ drm_gem_private_object_init(dev, obj, size);
+ obj->filp = filp;
return 0;
}
@@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
* no GEM provided backing store. Instead the caller is responsible for
* backing the object and handling it.
*/
-int drm_gem_private_object_init(struct drm_device *dev,
- struct drm_gem_object *obj, size_t size)
+void drm_gem_private_object_init(struct drm_device *dev,
+struct drm_gem_object *obj, size_t size)
{
BUG_ON((size & (PAGE_SIZE - 1)) != 0);
@@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
kref_init(&obj->refcount);
atomic_set(&obj->handle_count, 0);
obj->size = size;
-
- return 0;
}
EXPORT_SYMBOL(drm_gem_private_object_init);
diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 8b1b6d9..362dd2a 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
*dev, int aligned_size)
/* Begin by trying to use stolen memory backing */
backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
if (backing) {
- if (drm_gem_private_object_init(dev,
- &backing->gem, aligned_size) == 0)
- return backing;
- psb_gtt_free_range(dev, backing);
+ drm_gem_private_object_init(dev, &backing->gem, aligned_size);
+ return backing;
}
return NULL;
}
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index eefd6cc..fe1d332 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
struct drm_device *dev,
struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
if (gtt == NULL)
return -ENOMEM;
- if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
- goto free_gtt;
+
+ drm_gem_private_object_init(dev, >t->gem, size);
if (drm_gem_handle_create(file, >t->gem, handle) == 0)
return 0;
-free_gtt:
+
+ drm_gem_object_release(>t->gem);
psb_gtt_free_range(dev, gtt);
return -ENOMEM;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..f2e185c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
goto fail_detach;
}
- ret = drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
- if (ret) {
- i915_gem_object_free(obj);
- goto fail_detach;
- }
-
+ drm_gem_private_object_init(dev, &obj->base, dma_buf->size);
i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops);
obj->base.import_attach = att
[PATCH 2/2] drm/pci: remove useles #if 1
These don't make any sense, really..
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index 80c0b2b..a7b46ff 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -52,10 +52,8 @@
drm_dma_handle_t *drm_pci_alloc(struct drm_device * dev, size_t size, size_t
align)
{
drm_dma_handle_t *dmah;
-#if 1
unsigned long addr;
size_t sz;
-#endif
/* pci_alloc_consistent only guarantees alignment to the smallest
* PAGE_SIZE order which is greater than or equal to the requested size.
@@ -97,10 +95,8 @@ EXPORT_SYMBOL(drm_pci_alloc);
*/
void __drm_pci_free(struct drm_device * dev, drm_dma_handle_t * dmah)
{
-#if 1
unsigned long addr;
size_t sz;
-#endif
if (dmah->vaddr) {
/* XXX - Is virt_to_page() legal for consistent mem? */
--
1.8.3.2
[Bug 66731] texture issues in xonotic with llvm+sb and offset mapping
https://bugs.freedesktop.org/show_bug.cgi?id=66731 --- Comment #2 from Stefano Teso --- Thanks for the quick response. I just wanted to note that the glitch is still there with llvm 3.4 trunk. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/38e55943/attachment.html>
[PATCH] drm: don't call ->firstopen for KMS drivers
On Thu, Jul 11, 2013 at 9:54 AM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Wednesday 10 July 2013 20:17:44 Daniel Vetter wrote:
>> It has way too much potential for driver writers to do stupid things
>> like delayed hw setup because the load sequence is somehow racy (e.g.
>> the imx driver in staging). So don't call it for modesetting drivers,
>> which reduces the complexity of the drm core -> driver interface a
>> notch.
>>
>> v2: Don't forget to update DocBook.
>>
>> Cc: Laurent Pinchart
>> Signed-off-by: Daniel Vetter
>> ---
>> Documentation/DocBook/drm.tmpl | 2 ++
>> drivers/gpu/drm/drm_fops.c | 3 ++-
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
>> index 4d54ac8..0e8a5a3 100644
>> --- a/Documentation/DocBook/drm.tmpl
>> +++ b/Documentation/DocBook/drm.tmpl
>> @@ -2423,6 +2423,8 @@ void (*postclose) (struct drm_device *, struct
>> drm_file *);
>> The firstopen method is called by the DRM
>> core when an application opens a device that has no other opened file
>> handle.
>> + Not that this callback is only called for legacy ums drm drivers, not
>> + for drm drivers that implement modesetting in the kernel.
>> Similarly the lastclose method is called when
>> the last application holding a file handle opened on the device closes
>> it. Both methods are mostly used for UMS (User Mode Setting) drivers to
>
> What about
So if you think we should go overboard I guess it'd be useful to
explain what KMS drivers should and shouldn't do in lastclose:
- Delayed gpu switching with vga switcheroo.
- Restoring of the fbcon, as long as the core is still a bit deficient
in getting rid of mouse cursors and stupid sprite setups when X dies
untimely and leaves dirt behind. Eventually we should be able to get
rid of this though and rely on the magic sysrq to get out of graphics
mode and restore fbcon fully.
- Nothing else, ever, especially resource cleanups.
Can you maybe add a sentence or two to your proposed update for about
this? UMS drivers tend to do a lot of nefarious stuff in lastclose, so
stressing the difference would be good.
Otherwise I like your doc update much more than mine ;-)
-Daniel
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7d1278e..afa8d40 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
>
>
> The firstopen method is called by the DRM
> core
> - when an application opens a device that has no other opened file
> handle.
> - Similarly the lastclose method is called when
> - the last application holding a file handle opened on the device closes
> - it. Both methods are mostly used for UMS (User Mode Setting) drivers
> to
> - acquire and release device resources which should be done in the
> - load and unload
> - methods for KMS drivers.
> + for legacy UMS (User Mode Setting) drivers only when an application
> + opens a device that has no other opened file handle. UMS drivers can
> + implement it to acquire device resources. KMS drivers can't use the
> + method and must acquire resources in the load
> + method instead.
>
>
> -Note that the lastclose method is also
> called
> - at module unload time or, for hot-pluggable devices, when the device
> is
> - unplugged. The firstopen and
> + Similarly the lastclose method is called when
> + the last application holding a file handle opened on the device closes
> + it, for both UMS and KMS drivers. Additionally, the method is also
> + called at module unload time or, for hot-pluggable devices, when the
> + device is unplugged. The firstopen and
> lastclose calls can thus be unbalanced.
>
>
>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 57e3014..fcde7d4 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
>> int i;
>> int ret;
>>
>> - if (dev->driver->firstopen) {
>> + if (dev->driver->firstopen &&
>> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
>> ret = dev->driver->firstopen(dev);
>> if (ret != 0)
>> return ret;
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote: > drm_gem_object_init() and drm_gem_private_object_init() do exactly the > same (except for shmem alloc) so make the first use the latter to reduce > code duplication. > > Also drop the return code from drm_gem_private_object_init(). It seems > unlikely that we will extend it any time soon so no reason to keep it > around. This simplifies code paths in drivers, too. > > Last but not least, fix gma500 to call drm_gem_object_release() before > freeing objects that were allocated via drm_gem_private_object_init(). > That isn't actually necessary for now, but might be in the future. > > Cc: Patrik Jakobsson > Signed-off-by: David Herrmann You should also CC any driver maintainers that the patch touches. They should be acking it at the very least. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 11:56:32AM +0200, David Herrmann wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
Generally commmit messages that have too many "also do foo" paragraphs
tack on scream for a patch split up ;-) But the diff here is little enough
that it's imo still ok. So for both patches in this series:
Reviewed-by: Daniel Vetter
>
> Cc: Patrik Jakobsson
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 20
> drivers/gpu/drm/gma500/framebuffer.c | 6 ++
> drivers/gpu/drm/gma500/gem.c | 7 ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
> include/drm/drmP.h | 4 ++--
> 7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
> int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
> {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>
> - kref_init(&obj->refcount);
> - atomic_set(&obj->handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>
> return 0;
> }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
> * no GEM provided backing store. Instead the caller is responsible for
> * backing the object and handling it.
> */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> + struct drm_gem_object *obj, size_t size)
> {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> obj->size = size;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> - if (drm_gem_private_object_init(dev,
> - &backing->gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, &backing->gem, aligned_size);
> + return backing;
> }
> return NULL;
> }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >t->gem, size);
> if (drm_gem_handle_create(file, >t->gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>t->gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_obj
[PATCH v2 02/20] drm/gem: convert to new unified vma manager
Hi
On Sun, Jul 7, 2013 at 7:17 PM, David Herrmann wrote:
> Use the new vma manager instead of the old hashtable. Also convert all
> drivers to use the new convenience helpers. This drops all the
> (map_list.hash.key << PAGE_SHIFT) non-sense.
>
> Locking and access-management is exactly the same as before with an
> additional lock inside of the vma-manager, which strictly wouldn't be
> needed for gem.
>
> v2:
> - rebase on drm-next
> - init nodes via drm_vma_node_reset() in drm_gem.c
I missed the tegra driver and any staging driver. I will fix that in
v3 and reduce the series to a minimum.
Regards
David
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 90
> ++
> drivers/gpu/drm/drm_gem_cma_helper.c | 9 +--
> drivers/gpu/drm/exynos/exynos_drm_gem.c| 7 ++-
> drivers/gpu/drm/gma500/gem.c | 8 +--
> drivers/gpu/drm/i915/i915_gem.c| 9 +--
> drivers/gpu/drm/omapdrm/omap_gem.c | 11 ++--
> drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 49 +---
> drivers/gpu/drm/udl/udl_gem.c | 6 +-
> include/drm/drmP.h | 7 +--
> include/drm/drm_vma_manager.h | 1 -
> include/uapi/drm/drm.h | 2 +-
> 11 files changed, 49 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..b5db89b 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> /** @file drm_gem.c
> *
> @@ -102,14 +103,9 @@ drm_gem_init(struct drm_device *dev)
> }
>
> dev->mm_private = mm;
> -
> - if (drm_ht_create(&mm->offset_hash, 12)) {
> - kfree(mm);
> - return -ENOMEM;
> - }
> -
> - drm_mm_init(&mm->offset_manager, DRM_FILE_PAGE_OFFSET_START,
> - DRM_FILE_PAGE_OFFSET_SIZE);
> + drm_vma_offset_manager_init(&mm->vma_manager,
> + DRM_FILE_PAGE_OFFSET_START,
> + DRM_FILE_PAGE_OFFSET_SIZE);
>
> return 0;
> }
> @@ -119,8 +115,7 @@ drm_gem_destroy(struct drm_device *dev)
> {
> struct drm_gem_mm *mm = dev->mm_private;
>
> - drm_mm_takedown(&mm->offset_manager);
> - drm_ht_remove(&mm->offset_hash);
> + drm_vma_offset_manager_destroy(&mm->vma_manager);
> kfree(mm);
> dev->mm_private = NULL;
> }
> @@ -141,6 +136,7 @@ int drm_gem_object_init(struct drm_device *dev,
>
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> + drm_vma_node_reset(&obj->vma_node);
> obj->size = size;
>
> return 0;
> @@ -162,6 +158,7 @@ int drm_gem_private_object_init(struct drm_device *dev,
>
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> + drm_vma_node_reset(&obj->vma_node);
> obj->size = size;
>
> return 0;
> @@ -306,12 +303,8 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
> {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> - struct drm_map_list *list = &obj->map_list;
>
> - drm_ht_remove_item(&mm->offset_hash, &list->hash);
> - drm_mm_put_block(list->file_offset_node);
> - kfree(list->map);
> - list->map = NULL;
> + drm_vma_offset_remove(&mm->vma_manager, &obj->vma_node);
> }
> EXPORT_SYMBOL(drm_gem_free_mmap_offset);
>
> @@ -331,54 +324,9 @@ drm_gem_create_mmap_offset(struct drm_gem_object *obj)
> {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
> - struct drm_map_list *list;
> - struct drm_local_map *map;
> - int ret;
> -
> - /* Set the object up for mmap'ing */
> - list = &obj->map_list;
> - list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
> - if (!list->map)
> - return -ENOMEM;
> -
> - map = list->map;
> - map->type = _DRM_GEM;
> - map->size = obj->size;
> - map->handle = obj;
> -
> - /* Get a DRM GEM mmap offset allocated... */
> - list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
> - obj->size / PAGE_SIZE, 0, false);
> -
> - if (!list->file_offset_node) {
> - DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
> - ret = -ENOSPC;
> - goto out_free_list;
> - }
>
> - list->file_offset_node = drm_mm_get_block(list->file_offset_node,
> - obj->size / PAGE_SIZE, 0);
> - if (!list->file_offset_node) {
> - ret = -ENOMEM;
> - goto out_free_list;
> - }
> -
> - list->hash.key = list->file_offset_node->start;
> - ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
> - if (ret) {
> -
[PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 11:56 AM, David Herrmann
wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
>
> Cc: Patrik Jakobsson
> Signed-off-by: David Herrmann
> ---
> drivers/gpu/drm/drm_gem.c | 20
> drivers/gpu/drm/gma500/framebuffer.c | 6 ++
> drivers/gpu/drm/gma500/gem.c | 7 ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
> include/drm/drmP.h | 4 ++--
> 7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
> int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
> {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>
> - kref_init(&obj->refcount);
> - atomic_set(&obj->handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>
> return 0;
> }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
> * no GEM provided backing store. Instead the caller is responsible for
> * backing the object and handling it.
> */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +struct drm_gem_object *obj, size_t size)
> {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> obj->size = size;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> - if (drm_gem_private_object_init(dev,
> - &backing->gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, &backing->gem, aligned_size);
> + return backing;
> }
> return NULL;
> }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >t->gem, size);
> if (drm_gem_handle_create(file, >t->gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>t->gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
> goto fail_detach;
> }
>
> - ret = drm_gem_private_object_init(dev, &obj->base, dm
[PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)
Hi On Thu, Jul 11, 2013 at 1:12 PM, Martin Peres wrote: > On 07/07/2013 19:17, David Herrmann wrote: >> >> Hi >> >> This is v2 of the unified VMA offset manager series. The first draft is >> available at LWN [1]. This series replaces the VMA offset managers in GEM >> and >> TTM with a unified implementation. >> >> The first 4 patches contain the new VMA offset manager and are the only >> patches >> that I propose for mainline inclusion. >> Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar >> patches in i915-next and I will rebase them once it is merged. Ignore >> them if you're not interested. >> Patches 9-19 implement mmap access control. Comments are welcome! They are >> intended for mainline inclusion, too, but probably require some more >> review >> rounds. I'd really appreciate if driver authors could comment on the >> implementation. >> Patch 20 shows the main motivation behind this whole series: render nodes. >> It is >> marked RFC and I will resend once the VMA manager is merged upstream. Feel >> free >> to test it. >> >> One more note regarding DRM-Master: Render-clients are independent of >> DRM-Master >> (see the DocBook documentation). It really doesn't make sense to >> create/bind a >> DRM-Master object to render-clients. However, a lot of core DRM code >> depends on >> ->master != NULL. Drivers need to take care not to call into those core >> modules >> if they implement DRIVER_RENDER. >> I plan on removing multiple-master-support in the next series. So there >> will be >> only one global master and each open-file is bound to it. This will make >> it very >> easy to phase out "drm_master". The planned "modeset" nodes provide a nice >> replacement. If anyone knows a **currently used** use-case for >> multiple-masters, >> please tell me. I couldn't find one that _actually works_. >> (SetMaster+DropMaster >> will obviously stay functional even with drm_master removed). >> >> >> (series available at: https://github.com/dvdhrm/linux/tree/rnodes) >> >> Comments welcome! >> Cheers >> David > > Hi David, > > Thanks for this patchset. I am away from my computers for testing but I was > wondering if you based your vma rework on Dave's implementation. If so, > you may have the same bug that I had with it. > > I cannot remember the details of the bug, but I could trigger it by > rebooting > kde around 13 times on radeon. I didn't have this problem with Nouveau. It is based on Dave's code, but I rewrote all of it and fixed several bugs. For instance, there was a TTM ref-count leak for BOs in TTM core and a TTM locking issue. I didn't encounter any bugs so far, but I didn't try to restart the xserver 13 times. I will do some more stress-tests, but it is quite likely you hit one of those two bugs with radeon. > I am not competent to judge this work but I will try to test it and check > with my security tests that I wrote that the problem is indeed solved > on nouveau and radeon. The changes are actually quite simple. I intentionally kept TTM locking as it was before, even though I think we could reduce it now. Anyway, I will resend v3 (which now includes tegra and staging) this weekend. Hopefully we can get it into linux-next soon. Thanks! David > Looking forward to seeing your proposition for the userspace :) > > Cheers, > Martin
[Bug 66450] JUNIPER UVD accelerated playback of MPEG 1/2 streams does not work
https://bugs.freedesktop.org/show_bug.cgi?id=66450 --- Comment #7 from Christian K?nig --- Created attachment 82331 --> https://bugs.freedesktop.org/attachment.cgi?id=82331&action=edit Possible fix v2 Update patch, should work better this time. But please note that shader based decoding is far away from beeing perfect either. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/f8e790a2/attachment.html>
[PATCH 1/2] drm/gem: simplify object initialization
On Thu, Jul 11, 2013 at 5:56 AM, David Herrmann
wrote:
> drm_gem_object_init() and drm_gem_private_object_init() do exactly the
> same (except for shmem alloc) so make the first use the latter to reduce
> code duplication.
>
> Also drop the return code from drm_gem_private_object_init(). It seems
> unlikely that we will extend it any time soon so no reason to keep it
> around. This simplifies code paths in drivers, too.
>
> Last but not least, fix gma500 to call drm_gem_object_release() before
> freeing objects that were allocated via drm_gem_private_object_init().
> That isn't actually necessary for now, but might be in the future.
>
> Cc: Patrik Jakobsson
> Signed-off-by: David Herrmann
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/drm_gem.c | 20
> drivers/gpu/drm/gma500/framebuffer.c | 6 ++
> drivers/gpu/drm/gma500/gem.c | 7 ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +---
> drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++-
> include/drm/drmP.h | 4 ++--
> 7 files changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 603f256..1ad9e7e 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev)
> int drm_gem_object_init(struct drm_device *dev,
> struct drm_gem_object *obj, size_t size)
> {
> - BUG_ON((size & (PAGE_SIZE - 1)) != 0);
> + struct file *filp;
>
> - obj->dev = dev;
> - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> - if (IS_ERR(obj->filp))
> - return PTR_ERR(obj->filp);
> + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
> + if (IS_ERR(filp))
> + return PTR_ERR(filp);
>
> - kref_init(&obj->refcount);
> - atomic_set(&obj->handle_count, 0);
> - obj->size = size;
> + drm_gem_private_object_init(dev, obj, size);
> + obj->filp = filp;
>
> return 0;
> }
> @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init);
> * no GEM provided backing store. Instead the caller is responsible for
> * backing the object and handling it.
> */
> -int drm_gem_private_object_init(struct drm_device *dev,
> - struct drm_gem_object *obj, size_t size)
> +void drm_gem_private_object_init(struct drm_device *dev,
> +struct drm_gem_object *obj, size_t size)
> {
> BUG_ON((size & (PAGE_SIZE - 1)) != 0);
>
> @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev,
> kref_init(&obj->refcount);
> atomic_set(&obj->handle_count, 0);
> obj->size = size;
> -
> - return 0;
> }
> EXPORT_SYMBOL(drm_gem_private_object_init);
>
> diff --git a/drivers/gpu/drm/gma500/framebuffer.c
> b/drivers/gpu/drm/gma500/framebuffer.c
> index 8b1b6d9..362dd2a 100644
> --- a/drivers/gpu/drm/gma500/framebuffer.c
> +++ b/drivers/gpu/drm/gma500/framebuffer.c
> @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device
> *dev, int aligned_size)
> /* Begin by trying to use stolen memory backing */
> backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1);
> if (backing) {
> - if (drm_gem_private_object_init(dev,
> - &backing->gem, aligned_size) == 0)
> - return backing;
> - psb_gtt_free_range(dev, backing);
> + drm_gem_private_object_init(dev, &backing->gem, aligned_size);
> + return backing;
> }
> return NULL;
> }
> diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
> index eefd6cc..fe1d332 100644
> --- a/drivers/gpu/drm/gma500/gem.c
> +++ b/drivers/gpu/drm/gma500/gem.c
> @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file,
> struct drm_device *dev,
> struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1);
> if (gtt == NULL)
> return -ENOMEM;
> - if (drm_gem_private_object_init(dev, >t->gem, size) != 0)
> - goto free_gtt;
> +
> + drm_gem_private_object_init(dev, >t->gem, size);
> if (drm_gem_handle_create(file, >t->gem, handle) == 0)
> return 0;
> -free_gtt:
> +
> + drm_gem_object_release(>t->gem);
> psb_gtt_free_range(dev, gtt);
> return -ENOMEM;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index dc53a52..f2e185c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
> goto fail_detach;
> }
>
> - ret = drm_gem_private_object_in
[PULL] drm-intel-fixes
Cc lists this time around ... -Daniel On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter wrote: > Hi Dave, > > One feature latecomer, I've forgotten to merge the patch to reeanble the > Haswell power well feature now that the audio interaction is fixed up. > Since that was the only unfixed issue with it I've figured I could throw > it in a bit late, and it's trivial to revert in case I'm wrong. > > Otherwise all bug/regression fixes: > - Fix status page reinit after gpu hangs, spotted by more paranoid igt > checks. > - Fix object list walking fumble regression in the shrinker (only the > counting part, the actual shrinking code was correct so no Oops > potential), from Xiong Zhang. > - Fix DP 1.2 bw limits (Imre). > - Restore legacy forcewake on ivb, too many broken biosen out there. We > dump a warn though that recent userspace might fall over with that > config (Guenter Roeck). > - Patch up the gen2 cs tlb w/a. > - Improve the fence coherency w/a now that we have a better understanding > what's going on. The removed wbinvd+ipi should make -rt folks happy. Big > thanks to Jon Bloomfield for figuring this out, patches from Chris. > - Fix write-read race when switching ring (Chris). Spotted with code > inspection, but now we also have an igt for it. > > There's an ugly regression we're still working on introduced between > 3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since > that one fixes another regression :( I've asked Steven to include my > -fixes branch into linux-next to prevent such fallout in the future, > hopefully. > > Otherwise pretty calm thus far. > > Cheers, Daniel > > The following changes since commit 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e: > > drm/i915: Don't try to tear down the stolen drm_mm if it's not there > (2013-07-02 11:47:19 +0200) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm-intel > tags/drm-intel-fixes-2013-07-11 > > for you to fetch changes up to 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: > > Revert "drm/i915: Workaround incoherence between fences and LLC across > multiple CPUs" (2013-07-10 15:31:12 +0200) > > > Chris Wilson (3): > drm/i915: Fix write-read race with multiple rings > drm/i915: Fix incoherence with fence updates on Sandybridge+ > Revert "drm/i915: Workaround incoherence between fences and LLC across > multiple CPUs" > > Daniel Vetter (2): > drm/i915: reinit status page registers after gpu reset > drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a > > Guenter Roeck (1): > Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" > > Imre Deak (1): > drm/i915: fix lane bandwidth capping for DP 1.2 sinks > > Paulo Zanoni (1): > drm/i915: switch disable_power_well default value to 1 > > Xiong Zhang (1): > drm/i915: Correct obj->mm_list link to > dev_priv->dev_priv->mm.inactive_list > > drivers/gpu/drm/i915/i915_drv.c | 4 +- > drivers/gpu/drm/i915/i915_gem.c | 83 > + > drivers/gpu/drm/i915/intel_dp.c | 5 ++ > drivers/gpu/drm/i915/intel_pm.c | 31 +++- > drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +-- > 5 files changed, 93 insertions(+), 68 deletions(-) > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Radeon HD 6310 (AMD Wrestler): [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
On Thu, Jul 11, 2013 at 3:41 AM, Paul Menzel wrote: > Dear Linux folks, > > > using a Linux 3.10 with the drm-next-3.11 tree from Alex Deuscher merged > and built with `make deb-pkg`, it failed the last boot. > > [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). > > The strange thing is that it worked the last time I tried with the same > Linux kernel image as I posted to the list [1]. I just booted an old > 3.2.46 distribution Linux in between. (And it looked like the > modesetting did not work when doing so. But I did not look further into > it.) Make sure you have the updated rlc and uvd ucode installed and that the correct ucode is being used in your initrd, etc. Alex
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 --- Comment #22 from Christian K?nig --- (In reply to comment #21) > I got this compile warning: > > /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c: In function > ?radeon_uvd_fini?: > /home/lund/src/linux/drivers/gpu/drm/radeon/radeon_uvd.c:170:3: warning: > ?return? with a value, in function returning void [enabled by default] >return 0; >^ Just a stupid typo, going to fix that before I send it out to the list. > Haven't had a chance to test just yet. Will report back as soon as possible. That would be greate, cause it's actually a quite serious bug. I'm currently also locking into the other stability issues with 3.10, but can't (yet) say if it's radeons fault or not. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/d24b3874/attachment.html>
Questions about TTM buffer object maping
On Thu, Jul 11, 2013 at 2:24 AM, Daniel Vetter wrote: > On Wed, Jul 10, 2013 at 09:00:33PM -0400, Jerome Glisse wrote: >> On Wed, Jul 10, 2013 at 8:27 PM, Jean-S?bastien P?dron >> wrote: >> > Hello, >> > >> > I'm trying to understand how TTM buffer object mapping works on Linux, to >> > make this behave properly on FreeBSD. >> > >> > Here's what I think I understand: >> > >> > When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's >> > a >> > page fault, the page is looked up and inserted in the VMA using >> > vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is >> > called, which drops a reference. When the last reference is dropped, the >> > buffer object is destroyed. >> > >> > What's still not clear to me is how munmap() works here. After talking >> > about >> > this on IRC with some people, I think that unmap_mapping_range() (called by >> > ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from >> > userland. Is that true? >> >> Yes that's true. > > Afaik unmap_mapping_range only kills the ptes and doesn't remove the vma. > So not equivalent to a munmap from userspace. It simply allows us to > intercept the next access in the page fault handler and move the buffer > back into place. > -Daniel Yes, i was talking from a page point of view, ie page no longer have mapping and can be free. Cheers, Jerome
[PATCH 00/39] clean out drm cruft and hide it better for kms drivers
On Wed, Jul 10, 2013 at 8:11 AM, Daniel Vetter wrote: > Hi all, > > I've figured that it's again time for a bit of (late) drm spring cleanup. This > series here consists of a pile of "rip old stuff out" patches interleaved with > "disable old cruft for kms drivers and hide it better". > > Comments, flames and review highly welcome. I'd be especially happy if the arm > guys could check whether I haven't badly broken their drivers - > compile-testing > arm is a pita, so I haven't yet done that. > > There's a few driver-wide patches included, but the more invasive ones (i.e. > changing more than the drm driver vtable) are split out per-driver for easier > merging. If no one screams my plan is to rebase this pile on top of -rc1, give > it some more testing (check arm, ugh) and then send a pull request to Dave. > That should reduce interference with ongoing driver work as much as possible I > hope. > > My drm cruft todo list still has a pile of ideas, but I've figured I need to > stop now for 3.12. For those interested further cleanups could include: > > - setversion/set_busid: All drm core version 1.1 is legacy cruft, kms drivers > should never run in this mode. We could clean up the setversion ioclt (and > move the drm core version handling into a legacy function) and set up the > bus > id unconditionally at driver load time. > > - There's a few more legacy ioctls/subsystems that could be blocked out for > kms > drivers (but the required git history digging tends to be tedious). Also I > think we could more aggressively move legacy cruft setup/teardown code > out-of-line from the main code by extracting it into drm_legacy_ functions > (like this series here already does for the context and dma stuff). > > - I think creating a drm_internal.h header for functions not exported to > drivers > would be useful. That way we could move all the legacy functions out of > drmP.h > (which are a lot of them), which should make it much clearer what the real > drm > driver interface actually is. > > - drm_os_linux.h should just die in fire. > > - There's a pile of needless indirection around our agp handling, we duplicate > the agp core's CONFIG_AGP=n no-oping function handling in large parts, among > other stuff. > > - The drm coherent dma alloc helpers could get ripped out, at least for kms > drivers. For ums drivers there's some funny cases where this mapping is > exchanged with userspace for e.g. register access. In a least one case > (i810.ko) userspace even sets up that mapping, which allows it to crash the > kernel at will (since those maps aren't refcounted). Maybe we need to shovel > those interfaces into a drm_legacy.ko module to keep them around but make > sure > that no new driver even thinks about using them. > > - There's also the matter of the vblank support code, imo that should be split > int a ums and a kms part. That'd would allow us to use struct drm_crtc * in > interfaces and proper locking (by grabbing crtc->mutex to exclude races with > dpms/modesets). > > If anyone wants to dig around in those areas please poke me. > For the series: Reviewed-by: Alex Deucher > Cheers, Daniel > > Daniel Vetter (39): > drm: remove drm_modctx ioctl and use drm_noop instead > drm: kill dev->context_wait > drm: remove dev->last_switch > drm: kill dev->interrupt_flag and dev->dma_flag > drm: kill dev->ctx_start and dev->lck_start > drm/radoen: kill radeon_dma_ioctl_kms > drm: kill dev->buf_readers and dev->buf_writers > drm: remove redundant clears from drm_setup > drm/omap: kill firstopen callback > drm/radeon: kill firstopen callback for kms driver > drm/imx: kill firstopen callback > drm/vmwgfx: remove ->firstopen callback > drm: don't call ->firstopen for KMS drivers > drm: kill dev->driver->set_version > drm/radeon: remove DRIVER_HAS_DMA/SG/PCI_DMA from the kms driver > drm: fold in drm_sg_alloc into the ioctl > drm: hide legacy sg cleanup better from common code > drm: disallow legacy sg ioctls for modesetting drivers > drm: mark dma setup/teardown as legacy systems > drm/nouveau: drop DRIVER_PCI_DMA and DRIVER_SG > drm: disallow legacy dma ioctls for modesetting drivers > drm: move drm_getsarea into drm_bufs.c > drm/bufs: s/drm_order/order_base_2/ > drm/r128: s/drm_order/order_base_2/ > drm/radeon: s/drm_order/order_base_2/ > drm: remove drm_order > drm: mark context support as a legacy subsystem > drm/vmwgfx: remove redundant clearing of driver->dma_quiescent > drm: remove FASYNC support > drm: rip out DRIVER_FB_DMA and related code > drm: rip out a few unused DRIVER flags > drm: remove a bunch of unused #defines from drmP.h > drm: rip out drm_core_has_MTRR checks > drm: remove the dma_ioctl special-case > drm/memory: don't export agp helpers > drm: hollow-out GET_CLIENT ioctl > drm: no-op out GET_STATS ioctl > drm: fix locking in gem debugfs/procfs file > drm: remove procfs code, tak
[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=44772 Harald Judt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Harald Judt --- Reopened because it happens with 3.10 now even with pm_async set to 0. It happens with older kernel releases too when pm_async is set to 0, but is much harder to reproduce. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/b0f4db0b/attachment.html>
[Bug 66425] "failed testing IB on ring 5" when suspending to disk
https://bugs.freedesktop.org/show_bug.cgi?id=66425 --- Comment #23 from Harald Judt --- Thanks, I confirm that the patch fixes the problem! I've tested this at least 5 times with both the vanilla and the tuxonice hibernation, and both now work pretty stable with 3.10. (As a side note: The BFQ IO scheduler patch makes my system hang when suspending, but that is a different issue and really not a concern for this bug report.) Now I'm still plagued by bug #44772, which is similar in that it only happens when resuming from hibernation, not when suspending, and it seems to occur much more often with 3.10 with pm_async=0 than before. As far as my machine is concerned, I consider this solved and 3.10 has become usable for me. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/80d094f2/attachment.html>
[Bug 44772] Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=44772 Harald Judt changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #12 from Harald Judt --- Just for reference: Since I've never got a response here, I've opened a bug report at kernel bugzilla in the hope of someone helping me collect more debug data: https://bugzilla.kernel.org/show_bug.cgi?id=57381 Since everything's documented there, I'll finally close this bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130711/07345f01/attachment.html>
[PATCH 1/3] drm/radeon: Disable dma rings for bo moves on r6xx
From: Alex Deucher
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_asic.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 0970774..ea5c52b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1026,8 +1026,8 @@ static struct radeon_asic r600_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1119,8 +1119,8 @@ static struct radeon_asic rv6xx_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
@@ -1229,8 +1229,8 @@ static struct radeon_asic rs780_asic = {
.blit_ring_index = RADEON_RING_TYPE_GFX_INDEX,
.dma = &r600_copy_dma,
.dma_ring_index = R600_RING_TYPE_DMA_INDEX,
- .copy = &r600_copy_dma,
- .copy_ring_index = R600_RING_TYPE_DMA_INDEX,
+ .copy = &r600_copy_blit,
+ .copy_ring_index = RADEON_RING_TYPE_GFX_INDEX,
},
.surface = {
.set_reg = r600_set_surface_reg,
--
1.7.7.5
[PATCH 2/3] drm/radeon: implement bo copy callback using CP DMA (v2)
From: Alex Deucher
Lighter weight than using the 3D engine.
v2: fix ring count
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c| 81 ++
drivers/gpu/drm/radeon/r600d.h |1 +
drivers/gpu/drm/radeon/radeon_asic.h |3 +
3 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 2d3655f..f7d494f 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3145,6 +3145,87 @@ int r600_copy_blit(struct radeon_device *rdev,
}
/**
+ * r600_copy_cpdma - copy pages using the CP DMA engine
+ *
+ * @rdev: radeon_device pointer
+ * @src_offset: src GPU address
+ * @dst_offset: dst GPU address
+ * @num_gpu_pages: number of GPU pages to xfer
+ * @fence: radeon fence object
+ *
+ * Copy GPU paging using the CP DMA engine (r6xx+).
+ * Used by the radeon ttm implementation to move pages if
+ * registered as the asic copy callback.
+ */
+int r600_copy_cpdma(struct radeon_device *rdev,
+ uint64_t src_offset, uint64_t dst_offset,
+ unsigned num_gpu_pages,
+ struct radeon_fence **fence)
+{
+ struct radeon_semaphore *sem = NULL;
+ int ring_index = rdev->asic->copy.blit_ring_index;
+ struct radeon_ring *ring = &rdev->ring[ring_index];
+ u32 size_in_bytes, cur_size_in_bytes, tmp;
+ int i, num_loops;
+ int r = 0;
+
+ r = radeon_semaphore_create(rdev, &sem);
+ if (r) {
+ DRM_ERROR("radeon: moving bo (%d).\n", r);
+ return r;
+ }
+
+ size_in_bytes = (num_gpu_pages << RADEON_GPU_PAGE_SHIFT);
+ num_loops = DIV_ROUND_UP(size_in_bytes, 0x1f);
+ r = radeon_ring_lock(rdev, ring, num_loops * 6 + 21);
+ if (r) {
+ DRM_ERROR("radeon: moving bo (%d).\n", r);
+ radeon_semaphore_free(rdev, &sem, NULL);
+ return r;
+ }
+
+ if (radeon_fence_need_sync(*fence, ring->idx)) {
+ radeon_semaphore_sync_rings(rdev, sem, (*fence)->ring,
+ ring->idx);
+ radeon_fence_note_sync(*fence, ring->idx);
+ } else {
+ radeon_semaphore_free(rdev, &sem, NULL);
+ }
+
+ for (i = 0; i < num_loops; i++) {
+ cur_size_in_bytes = size_in_bytes;
+ if (cur_size_in_bytes > 0x1f)
+ cur_size_in_bytes = 0x1f;
+ size_in_bytes -= cur_size_in_bytes;
+ tmp = upper_32_bits(src_offset) & 0xff;
+ if (size_in_bytes == 0)
+ tmp |= PACKET3_CP_DMA_CP_SYNC;
+ radeon_ring_write(ring, PACKET3(PACKET3_CP_DMA, 4));
+ radeon_ring_write(ring, src_offset & 0x);
+ radeon_ring_write(ring, tmp);
+ radeon_ring_write(ring, dst_offset & 0x);
+ radeon_ring_write(ring, upper_32_bits(dst_offset) & 0xff);
+ radeon_ring_write(ring, cur_size_in_bytes);
+ src_offset += cur_size_in_bytes;
+ dst_offset += cur_size_in_bytes;
+ }
+ radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
+ radeon_ring_write(ring, (WAIT_UNTIL - PACKET3_SET_CONFIG_REG_OFFSET) >>
2);
+ radeon_ring_write(ring, WAIT_CP_DMA_IDLE_bit);
+
+ r = radeon_fence_emit(rdev, fence, ring->idx);
+ if (r) {
+ radeon_ring_unlock_undo(rdev, ring);
+ return r;
+ }
+
+ radeon_ring_unlock_commit(rdev, ring);
+ radeon_semaphore_free(rdev, &sem, *fence);
+
+ return r;
+}
+
+/**
* r600_copy_dma - copy pages using the DMA engine
*
* @rdev: radeon_device pointer
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index f1b3084..8e3fe81 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -602,6 +602,7 @@
#defineL2_BUSY (1 << 0)
#defineWAIT_UNTIL 0x8040
+#define WAIT_CP_DMA_IDLE_bit(1 << 8)
#define WAIT_2D_IDLE_bit(1 << 14)
#define WAIT_3D_IDLE_bit(1 << 15)
#define WAIT_2D_IDLECLEAN_bit (1 << 16)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 45d0693..b04b578 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -340,6 +340,9 @@ int r600_uvd_ring_test(struct radeon_device *rdev, struct
radeon_ring *ring);
int r600_copy_blit(struct radeon_device *rdev,
uint64_t src_offset, uint64_t dst_offset,
unsigned num_gpu_pages, struct radeon_fence **fence);
+int r600_copy_cpdma(struct radeon_device *rdev,
+
