Re: [PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf->priv
Hi Inki,
On Thu, Aug 08, 2013 at 01:56:28PM +0900, Inki Dae wrote:
> Hi, Daniel. You can repost your patch set including the below my patch. And
> my patch numbering is wrong. Sorry about that.
Thanks for the patch, I'll submit it toghether with the other ones soon.
-Daniel
>
> [PATCH 1/4] -> [PATCH 4/4]
>
>
> Thanks,
> Inki Dae
>
> > -Original Message-
> > From: Inki Dae [mailto:inki@samsung.com]
> > Sent: Thursday, August 08, 2013 1:40 PM
> > To: dan...@ffwll.ch
> > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; Inki
> > Dae; Kyungmin Park
> > Subject: [PATCH 1/4] drm/exynos: explicit store base gem object in
> > dma_buf->priv
> >
> > Signed-off-by: Inki Dae
> > Signed-off-by: Kyungmin Park
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
> > 1 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> > b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> > index 3cd56e1..fd76449 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> > @@ -22,6 +22,11 @@ struct exynos_drm_dmabuf_attachment {
> > bool is_mapped;
> > };
> >
> > +static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
> > +{
> > + return to_exynos_gem_obj(buf->priv);
> > +}
> > +
> > static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
> > struct device *dev,
> > struct dma_buf_attachment *attach)
> > @@ -63,7 +68,7 @@ static struct sg_table *
> > enum dma_data_direction dir)
> > {
> > struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
> > - struct exynos_drm_gem_obj *gem_obj = attach->dmabuf->priv;
> > + struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
> > struct drm_device *dev = gem_obj->base.dev;
> > struct exynos_drm_gem_buf *buf;
> > struct scatterlist *rd, *wr;
> > @@ -180,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
> > drm_device *drm_dev,
> > {
> > struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
> >
> > - return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops,
> > + return dma_buf_export(obj, &exynos_dmabuf_ops,
> > exynos_gem_obj->base.size, flags);
> > }
> >
> > @@ -198,8 +203,7 @@ struct drm_gem_object
> > *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
> > if (dma_buf->ops == &exynos_dmabuf_ops) {
> > struct drm_gem_object *obj;
> >
> > - exynos_gem_obj = dma_buf->priv;
> > - obj = &exynos_gem_obj->base;
> > + obj = dma_buf->priv;
> >
> > /* is it from our device? */
> > if (obj->dev == drm_dev) {
> > --
> > 1.7.5.4
>
--
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
[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon
https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #3 from Jani Nikula --- Sebastien, to confirm, you need "drm/i915: do not disable backlight on vgaswitcheroo switch off" to be able to switch from IGD to DIS? So having that is an improvement? And without that, the workarounds won't help? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] First cut of prime patches for drm-next
Hi Dave, Inki supplied a patch to convert exynos, so I think these prep patches are ready to go in. I want a common drm_gem_dmabuf_release function across all drivers since th oops fix around the teardown of the obj->export_dma_buf pointer needs to have changed code in there, and duplicating tricky locking stuff accross all drivers isn't great. Please consider merging into drm-next. Cheers, Daniel Daniel Vetter (4): drm: use common drm_gem_dmabuf_release in i915/exynos drivers drm/i915: unpin backing storage in dmabuf_unmap drm/i915: explicit store base gem object in dma_buf->priv drm/prime: remove cargo-cult locking from map_sg helper Inki Dae (1): drm/exynos: explicit store base gem object in dma_buf->priv drivers/gpu/drm/drm_prime.c| 6 ++--- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 35 - drivers/gpu/drm/i915/i915_gem_dmabuf.c | 36 +++--- include/drm/drmP.h | 1 + 4 files changed, 30 insertions(+), 48 deletions(-) -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: use common drm_gem_dmabuf_release in i915/exynos drivers
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae
Cc: Intel Graphics Development
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c| 3 ++-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 23 +--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 +
include/drm/drmP.h | 1 +
4 files changed, 5 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 85e450e..a35f206 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -192,7 +192,7 @@ static void drm_gem_unmap_dma_buf(struct dma_buf_attachment
*attach,
/* nothing to be done here */
}
-static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
+void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
{
struct drm_gem_object *obj = dma_buf->priv;
@@ -202,6 +202,7 @@ static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
drm_gem_object_unreference_unlocked(obj);
}
}
+EXPORT_SYMBOL(drm_gem_dmabuf_release);
static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index a0f997e..3cd56e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -127,27 +127,6 @@ static void exynos_gem_unmap_dma_buf(struct
dma_buf_attachment *attach,
/* Nothing to do. */
}
-static void exynos_dmabuf_release(struct dma_buf *dmabuf)
-{
- struct exynos_drm_gem_obj *exynos_gem_obj = dmabuf->priv;
-
- /*
-* exynos_dmabuf_release() call means that file object's
-* f_count is 0 and it calls drm_gem_object_handle_unreference()
-* to drop the references that these values had been increased
-* at drm_prime_handle_to_fd()
-*/
- if (exynos_gem_obj->base.export_dma_buf == dmabuf) {
- exynos_gem_obj->base.export_dma_buf = NULL;
-
- /*
-* drop this gem object refcount to release allocated buffer
-* and resources.
-*/
- drm_gem_object_unreference_unlocked(&exynos_gem_obj->base);
- }
-}
-
static void *exynos_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
unsigned long page_num)
{
@@ -193,7 +172,7 @@ static struct dma_buf_ops exynos_dmabuf_ops = {
.kunmap = exynos_gem_dmabuf_kunmap,
.kunmap_atomic = exynos_gem_dmabuf_kunmap_atomic,
.mmap = exynos_gem_dmabuf_mmap,
- .release= exynos_dmabuf_release,
+ .release= drm_gem_dmabuf_release,
};
struct dma_buf *exynos_dmabuf_prime_export(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index f2e185c..63ee1a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -90,17 +90,6 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment
*attachment,
kfree(sg);
}
-static void i915_gem_dmabuf_release(struct dma_buf *dma_buf)
-{
- struct drm_i915_gem_object *obj = dma_buf->priv;
-
- if (obj->base.export_dma_buf == dma_buf) {
- /* drop the reference on the export fd holds */
- obj->base.export_dma_buf = NULL;
- drm_gem_object_unreference_unlocked(&obj->base);
- }
-}
-
static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
struct drm_i915_gem_object *obj = dma_buf->priv;
@@ -211,7 +200,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, size_t start, size
static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
- .release = i915_gem_dmabuf_release,
+ .release = drm_gem_dmabuf_release,
.kmap = i915_gem_dmabuf_kmap,
.kmap_atomic = i915_gem_dmabuf_kmap_atomic,
.kunmap = i915_gem_dmabuf_kunmap,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fba5473..69bf832 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1540,6 +1540,7 @@ extern struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
struct dma_buf *dma_buf);
extern int drm_gem_prime_fd_to_handle(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd, uint32_t *handle);
+extern void drm_gem_dmabuf_release(struct dma_buf *dma_buf);
extern int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
--
1.8.3.2
[PATCH 2/5] drm/i915: unpin backing storage in dmabuf_unmap
This fixes a WARN in i915_gem_free_object when the
obj->pages_pin_count isn't 0.
v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though we call unmap with our own dev->struct_mutex held that won't
result in an immediate deadlock since we never go through the dma_buf
interfaces for our own, reimported buffers. But it's still easy to
blow up and anger lockdep, but that's already the case with our ->map
implementation. Fixing this for real will involve per dma-buf ww mutex
locking by the callers. And lots of fun. So go with the duct-tape
approach for now.
Cc: Chris Wilson
Reported-by: Maarten Lankhorst
Cc: Maarten Lankhorst
Tested-by: Armin K. (v1)
Acked-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 63ee1a9..f7e1682 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -85,9 +85,17 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment
*attachment,
struct sg_table *sg,
enum dma_data_direction dir)
{
+ struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
+
+ mutex_lock(&obj->base.dev->struct_mutex);
+
dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
sg_free_table(sg);
kfree(sg);
+
+ i915_gem_object_unpin_pages(obj);
+
+ mutex_unlock(&obj->base.dev->struct_mutex);
}
static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/i915: explicit store base gem object in dma_buf->priv
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index f7e1682..e918b05 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -27,10 +27,15 @@
#include "i915_drv.h"
#include
+static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
+{
+ return to_intel_bo(buf->priv);
+}
+
static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment
*attachment,
enum dma_data_direction dir)
{
- struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
struct sg_table *st;
struct scatterlist *src, *dst;
int ret, i;
@@ -85,7 +90,7 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment
*attachment,
struct sg_table *sg,
enum dma_data_direction dir)
{
- struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
mutex_lock(&obj->base.dev->struct_mutex);
@@ -100,7 +105,7 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attachment,
static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
- struct drm_i915_gem_object *obj = dma_buf->priv;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
struct sg_page_iter sg_iter;
struct page **pages;
@@ -148,7 +153,7 @@ error:
static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
{
- struct drm_i915_gem_object *obj = dma_buf->priv;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
int ret;
@@ -191,7 +196,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start,
size_t length, enum dma_data_direction direction)
{
- struct drm_i915_gem_object *obj = dma_buf->priv;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
int ret;
bool write = (direction == DMA_BIDIRECTIONAL || direction ==
DMA_TO_DEVICE);
@@ -222,9 +227,7 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gem_obj, int flags)
{
- struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
-
- return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, flags);
+ return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags);
}
static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
@@ -261,7 +264,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
/* is this one of own objects? */
if (dma_buf->ops == &i915_dmabuf_ops) {
- obj = dma_buf->priv;
+ obj = dma_buf_to_obj(dma_buf);
/* is it from our device? */
if (obj->base.dev == dev) {
/*
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/exynos: explicit store base gem object in dma_buf->priv
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -22,6 +22,11 @@ struct exynos_drm_dmabuf_attachment {
bool is_mapped;
};
+static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
+{
+ return to_exynos_gem_obj(buf->priv);
+}
+
static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
struct device *dev,
struct dma_buf_attachment *attach)
@@ -63,7 +68,7 @@ static struct sg_table *
enum dma_data_direction dir)
{
struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
- struct exynos_drm_gem_obj *gem_obj = attach->dmabuf->priv;
+ struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
struct drm_device *dev = gem_obj->base.dev;
struct exynos_drm_gem_buf *buf;
struct scatterlist *rd, *wr;
@@ -180,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
drm_device *drm_dev,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
- return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops,
+ return dma_buf_export(obj, &exynos_dmabuf_ops,
exynos_gem_obj->base.size, flags);
}
@@ -198,8 +203,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
if (dma_buf->ops == &exynos_dmabuf_ops) {
struct drm_gem_object *obj;
- exynos_gem_obj = dma_buf->priv;
- obj = &exynos_gem_obj->base;
+ obj = dma_buf->priv;
/* is it from our device? */
if (obj->dev == drm_dev) {
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/prime: remove cargo-cult locking from map_sg helper
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
Acked-by: Laurent Pinchart
Acked-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
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 a35f206..f115962 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;
}
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67888] New: R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace
https://bugs.freedesktop.org/show_bug.cgi?id=67888 Priority: medium Bug ID: 67888 Assignee: dri-devel@lists.freedesktop.org Summary: R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace Severity: major Classification: Unclassified OS: Linux (All) Reporter: fossphr...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: DRI CVS Component: DRM/Radeon Product: DRI Created attachment 83811 --> https://bugs.freedesktop.org/attachment.cgi?id=83811&action=edit dmesg contents after GPU hangup occurred I had used apitrace to trace Trine 2 OpenGL calls. When I tried to profile the trace, display corruption and GPU hangup occurred. -- 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 67800] Computer freezes after idle for several hours (trinity)
https://bugs.freedesktop.org/show_bug.cgi?id=67800 --- Comment #5 from Kertesz Laszlo --- (In reply to comment #4) > This may be a duplicate of bug 65958. Does setting the env var RADEON_VA=0 > in your /etc/environment fix the issue? (In reply to comment #4) > This may be a duplicate of bug 65958. Does setting the env var RADEON_VA=0 > in your /etc/environment fix the issue? Unfortunately it doesnt solve it. I still get freezes after a few hours of idle. -- 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
[PULL] drm-intel-fixes
Hi Dave, A few bugfixes for serious stuff and regressions. Highlight is the reinstated hack to keep the i915 backlight on when running on an optimus machine, this prevents black screens especially with some radeon muxed platforms. And the patch to quiet dmesg on Linus' old mac mini ;-) Cheers, Daniel The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f: Linux 3.11-rc4 (2013-08-04 13:46:46 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-08-08 for you to fetch changes up to 3f577573cd5482a32f85bd131e52f7cb4b9ac518: drm/i915: do not disable backlight on vgaswitcheroo switch off (2013-08-07 11:57:09 +0200) Aaron Lu (1): drm/i915: avoid brightness overflow when doing scale Daniel Vetter (1): drm/i915: fix gen4 digital port hotplug definitions Jani Nikula (1): drm/i915: do not disable backlight on vgaswitcheroo switch off Paulo Zanoni (1): drm/i915: update last_vblank when disabling the power well Ville Syrjälä (1): drm/i915: Don't call encoder's get_config unless encoder is active drivers/gpu/drm/i915/i915_reg.h | 12 +--- drivers/gpu/drm/i915/intel_display.c | 4 +++- drivers/gpu/drm/i915/intel_panel.c | 18 -- drivers/gpu/drm/i915/intel_pm.c | 18 ++ 4 files changed, 46 insertions(+), 6 deletions(-) -- 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 v3] drm: use ida to allocate connector ids
On Wed, Aug 07, 2013 at 10:34:48PM -0400, Ilia Mirkin wrote:
> This makes it so that reloading a module does not cause all the
> connector ids to change, which are user-visible and sometimes used
> for configuration.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> v2 -> v3:
> - rename ida struct name to... ida. (i'm ready to accept my "creative name
>of the year" award.)
Seems fine to me. We already have the foo_idr and whatever.
> - fix object id leak when allocation fails.
> - use ida_simple_get, since it's OK to allocate memory inside kms lock
Looks fine to me.
Reviewed-by: Ville Syrjälä
>
> drivers/gpu/drm/drm_crtc.c | 62
> --
> drivers/gpu/drm/drm_drv.c | 2 ++
> include/drm/drm_crtc.h | 2 ++
> 3 files changed, 48 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fc83bb9..a691764 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -186,29 +186,29 @@ static const struct drm_prop_enum_list
> drm_dirty_info_enum_list[] = {
> struct drm_conn_prop_enum_list {
> int type;
> const char *name;
> - int count;
> + struct ida ida;
> };
>
> /*
> * Connector and encoder types.
> */
> static struct drm_conn_prop_enum_list drm_connector_enum_list[] =
> -{{ DRM_MODE_CONNECTOR_Unknown, "Unknown", 0 },
> - { DRM_MODE_CONNECTOR_VGA, "VGA", 0 },
> - { DRM_MODE_CONNECTOR_DVII, "DVI-I", 0 },
> - { DRM_MODE_CONNECTOR_DVID, "DVI-D", 0 },
> - { DRM_MODE_CONNECTOR_DVIA, "DVI-A", 0 },
> - { DRM_MODE_CONNECTOR_Composite, "Composite", 0 },
> - { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO", 0 },
> - { DRM_MODE_CONNECTOR_LVDS, "LVDS", 0 },
> - { DRM_MODE_CONNECTOR_Component, "Component", 0 },
> - { DRM_MODE_CONNECTOR_9PinDIN, "DIN", 0 },
> - { DRM_MODE_CONNECTOR_DisplayPort, "DP", 0 },
> - { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A", 0 },
> - { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B", 0 },
> - { DRM_MODE_CONNECTOR_TV, "TV", 0 },
> - { DRM_MODE_CONNECTOR_eDP, "eDP", 0 },
> - { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual", 0},
> +{{ DRM_MODE_CONNECTOR_Unknown, "Unknown" },
> + { DRM_MODE_CONNECTOR_VGA, "VGA" },
> + { DRM_MODE_CONNECTOR_DVII, "DVI-I" },
> + { DRM_MODE_CONNECTOR_DVID, "DVI-D" },
> + { DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
> + { DRM_MODE_CONNECTOR_Composite, "Composite" },
> + { DRM_MODE_CONNECTOR_SVIDEO, "SVIDEO" },
> + { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
> + { DRM_MODE_CONNECTOR_Component, "Component" },
> + { DRM_MODE_CONNECTOR_9PinDIN, "DIN" },
> + { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
> + { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
> + { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
> + { DRM_MODE_CONNECTOR_TV, "TV" },
> + { DRM_MODE_CONNECTOR_eDP, "eDP" },
> + { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
> };
>
> static const struct drm_prop_enum_list drm_encoder_enum_list[] =
> @@ -220,6 +220,22 @@ static const struct drm_prop_enum_list
> drm_encoder_enum_list[] =
> { DRM_MODE_ENCODER_VIRTUAL, "Virtual" },
> };
>
> +void drm_connector_ida_init(void)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
> + ida_init(&drm_connector_enum_list[i].ida);
> +}
> +
> +void drm_connector_ida_destroy(void)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(drm_connector_enum_list); i++)
> + ida_destroy(&drm_connector_enum_list[i].ida);
> +}
> +
> const char *drm_get_encoder_name(const struct drm_encoder *encoder)
> {
> static char buf[32];
> @@ -711,6 +727,8 @@ int drm_connector_init(struct drm_device *dev,
> int connector_type)
> {
> int ret;
> + struct ida *connector_ida =
> + &drm_connector_enum_list[connector_type].ida;
>
> drm_modeset_lock_all(dev);
>
> @@ -723,7 +741,12 @@ int drm_connector_init(struct drm_device *dev,
> connector->funcs = funcs;
> connector->connector_type = connector_type;
> connector->connector_type_id =
> - ++drm_connector_enum_list[connector_type].count; /* TODO */
> + ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
> + if (connector->connector_type_id < 0) {
> + ret = connector->connector_type_id;
> + drm_mode_object_put(dev, &connector->base);
> + goto out;
> + }
> INIT_LIST_HEAD(&connector->probed_modes);
> INIT_LIST_HEAD(&connector->modes);
> connector->edid_blob_ptr = NULL;
> @@ -764,6 +787,9 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> list_for_each_entry_safe(mode, t, &connector->modes, head)
> drm_mode_remove(connector, mode);
>
> + ida_remove(&drm_connector_enum_list[connector->connector_type].ida,
> +connector->connector_type_id);
> +
> drm_mode_object_put(dev, &connector->base);
> list_del(&
[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon
https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #4 from Sebastien Fievet --- (In reply to Jani Nikula from comment #3) I reverted the patch and double checked. The workaround is enough for me. What I do is : 1. echo OFF > /sys/kernel/debug/vgaswitcheroo/switch at init time with a rc script. Hence I always start on the IGD with the DIS OFF : cat /sys/kernel/debug/vgaswitcheroo/switch 0:DIS: :Off::02:00.0 1:DIS-Audio: :Off::02:00.1 2:IGD:+:Pwr::00:02.0 2. to switch from IGD to DIS I do : for cmd in "ON MIGD DDIS"; do echo $cmd > /sys/kernel/debug/vgaswitcheroo/switch done The screen flickers a bit during the OFF -> ON -> MIGD transition cat /sys/kernel/debug/vgaswitcheroo/switch 0:DIS: :Pwr::02:00.0 1:DIS-Audio: :Pwr::02:00.1 2:IGD:+:Pwr::00:02.0 3.I logout/login to X. To switch back to IGD I do : for cmd in "ON DIGD"; do echo $cmd > /sys/kernel/debug/vgaswitcheroo/switch done The screen doesn't flicker. => I can cycle through IGD and DIS at will. When testing your patch I was starting with both IGD and DIS ON. So initial conditions were different :-(. Then : 1. echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch worked, while without your patch it didn't. 2. logout/login to X echo DIGD > /sys/kernel/debug/vgaswitcheroo/switch worked. 3. logout/login to X echo DDIS > /sys/kernel/debug/vgaswitcheroo/switch screwed up the display. So I think I have been abused by the favourable initial conditions I used when testing your patch. Let me know if you need anything else. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60532] Suspend with dedicated graphics card switched off breaking with kernel version 3.8.0-25+
https://bugzilla.kernel.org/show_bug.cgi?id=60532 Jani Nikula changed: What|Removed |Added Component|Video(DRI - Intel) |Video(DRI - non Intel) Assignee|intel-gfx-bugs@lists.freede |drivers_video-dri@kernel-bu |sktop.org |gs.osdl.org --- Comment #7 from Jani Nikula --- (In reply to Aaron Lu from comment #6) > From the dmesg of comment #3, the system resumed back but graphics card > seems to have problems, re-assign to graphics. Dmesg filled with: [ 1590.550012] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 1590.550030] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBD6 (len 62, WS 0, PS 0) @ 0xCBF2 Radeon issue? Re-assign to non-Intel. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60720] New: System freeze randomly with latest kernel 3.10 (also 3.11-rc4)
https://bugzilla.kernel.org/show_bug.cgi?id=60720 Bug ID: 60720 Summary: System freeze randomly with latest kernel 3.10 (also 3.11-rc4) Product: Drivers Version: 2.5 Kernel Version: 3.10 to 3.11-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: jarry...@gmail.com Regression: No This problem exist since 3.10. linux 3.9 was very fine. I used to think this issue only happen when playing videos, but now, I find it makes no different, system freeze and not response at all (even the magic sysrq) after about one hour. I tested, when using chromium open a page and leave it there, system still freeze. And if screen goes black, it happens, too. I can't get any logs. linux 3.11-rc4, mesa git 20130805, xf86-video-ati 7.2.0, Acer v3 551G AMD A8 4500m + 7670M + 8G ddr3 mem I don't know if this related to radeon module, so i report it here again. see: https://bugs.freedesktop.org/show_bug.cgi?id=66738 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [pull] radeon drm-fixes-3.11
> -Original Message- > From: Rafał Miłecki [mailto:zaj...@gmail.com] > Sent: Thursday, August 08, 2013 12:37 AM > To: Alex Deucher > Cc: dri-devel@lists.freedesktop.org; airl...@gmail.com; Deucher, Alexander > Subject: Re: [pull] radeon drm-fixes-3.11 > > 2013/8/8 Alex Deucher : > > Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs > > with dpm on more rv6xx asics, and fixes suspend and resume with UVD. > > That > fix audio dto calculation on DCE3+ > looks promising, I had no idea you're working on that. Thanks for > releasing that! > > Maybe you could post your patches for review on dri-devel@? If you > don't want Dave to take them, maybe just post them with [RFC]? Sorry, I thought I had sent that one out, but maybe just internally. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67876] linux v4.11-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot
https://bugs.freedesktop.org/show_bug.cgi?id=67876 --- Comment #3 from Alex Deucher --- I'm not sure why you aren't getting the smc error message, you should be. To fix teh UVD error messages, you also need an updated rlc ucode. -- 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 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #84 from Alex Deucher --- Does disabling clockgating avoid the hangs? diff --git a/drivers/gpu/drm/radeon/rv6xx_dpm.c b/drivers/gpu/drm/radeon/rv6xx_dpm.c index bdd888b..85f2ab8 100644 --- a/drivers/gpu/drm/radeon/rv6xx_dpm.c +++ b/drivers/gpu/drm/radeon/rv6xx_dpm.c @@ -1985,7 +1985,7 @@ int rv6xx_dpm_init(struct radeon_device *rdev) pi->voltage_control = radeon_atom_is_voltage_gpio(rdev, SET_VOLTAGE_TYPE_ASIC_VDDC, 0); - pi->gfx_clock_gating = true; + pi->gfx_clock_gating = false; pi->sclk_ss = radeon_atombios_get_asic_ss_info(rdev, &ss, ASIC_INTERNAL_ENGINE_SS, 0); Make sure you do a cold shutdown after changing that. -- 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 60720] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)
https://bugzilla.kernel.org/show_bug.cgi?id=60720 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher --- You don't need to report it twice. Just stick with the original bug. All the developers are aware of all of both of the bugzillas. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66738] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=66738 Alex Deucher changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Product|xorg|Mesa Component|Driver/Radeon |Drivers/Gallium/r600 --- Comment #11 from Alex Deucher --- Are you running the same userspace stack with both kernel 3.9 and kernel 3.10/3.11? If so, it sounds like this is UVD related. -- 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 67901] New: Black screen or freeze on radeon driver on AMD 6470M / Intel HD 3000
https://bugs.freedesktop.org/show_bug.cgi?id=67901 Priority: medium Bug ID: 67901 Assignee: dri-devel@lists.freedesktop.org Summary: Black screen or freeze on radeon driver on AMD 6470M / Intel HD 3000 Severity: normal Classification: Unclassified OS: All Reporter: xpressra...@gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/DRI/R600 Product: Mesa I have hybrid graphics card setup (AMD 6470M / Intel HD 3000 sandy bridge). I followed http://www.phoronix.com/scan.php?page=news_item&px=MTQyNDE and installed 3.11 kernel on ubuntu 13.10 daily. I also installed mesa 9.2 using xorg-edgers ppa. When I tried to boot using radeon.dpm=1, it had shown a message about missing driver (CAICOS), therefore I replaced all drivers in /lib/firmware/radeon with the one downloaded from http://people.freedesktop.org/~agd5f/radeon_ucode/. I ran "update-initramfs -u", after which the message had gone. This time when I tried to boot using radeon.dpm=1 and it froze. I even tried to turn ON AMD graphics card using vgaswitcheroo (https://help.ubuntu.com/community/HybridGraphics). When I logout, and tried to login it sometimes showed black screen or sometimes froze. I had seen the development page (I don't remember where), and the hybrid graphics card switching was not fully fixed. Is this still the problem? Thanks !! $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Seymour [Radeon HD 6400M/7400M Series] (rev ff) -- 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 67888] R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace
https://bugs.freedesktop.org/show_bug.cgi?id=67888 --- Comment #1 from Alex Deucher --- Do you get the same hang with dpm disabled? -- 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 00/25] drm cruft removal
Hi all, So a bunch of patches went in already, and a few of the ones here small fixups (DocBook, compile fail for funny .configs and 1 unused variable). And slight rebasing on top of David's drm_dev cleanup refactoring. The big change is that the get_client ioclt isn't a complete noop now but fakes enough of the old thing so that libva will keep on working - libva uses the get_client ioctl to figure out whether it's authenticated or not. Of course I've dutifully taken that libva code and pressed it into an igt testcase to make sure we don't break anything. r-b tags and acks for individual patches I've added, but there's the overall review from Alex and testing from David on the series: Tested-by: David Herrmann Reviewed-by: Alex Deucher Comments and review highly welcome and please consider merging for drm-next. Note that the patch "drm/imx: kill firstopen callback" is already merged into the staging tree, but it's probably simplest if we merge it again through drm-next. Thanks, Daniel Daniel Vetter (25): 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: 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: disallow legacy dma ioctls for modesetting drivers 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/docs: rip out removed driver flags documentation 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 2 drm: move dev data clearing from drm_setup to lastclose Documentation/DocBook/drm.tmpl | 57 +++-- drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/ast/ast_drv.c| 3 +- drivers/gpu/drm/cirrus/cirrus_drv.c | 3 +- drivers/gpu/drm/drm_bufs.c | 201 + drivers/gpu/drm/drm_context.c| 73 +-- drivers/gpu/drm/drm_dma.c| 17 ++- drivers/gpu/drm/drm_drv.c| 51 drivers/gpu/drm/drm_fops.c | 71 +-- drivers/gpu/drm/drm_info.c | 4 + drivers/gpu/drm/drm_ioctl.c | 59 - drivers/gpu/drm/drm_memory.c | 2 - drivers/gpu/drm/drm_pci.c| 14 +-- drivers/gpu/drm/drm_proc.c | 209 --- drivers/gpu/drm/drm_scatter.c| 16 ++- drivers/gpu/drm/drm_stub.c | 42 ++- drivers/gpu/drm/drm_vm.c | 3 +- drivers/gpu/drm/gma500/psb_drv.c | 3 +- drivers/gpu/drm/i810/i810_dma.c | 1 - drivers/gpu/drm/i810/i810_drv.c | 3 +- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/mga/mga_drv.c| 3 +- drivers/gpu/drm/mgag200/mgag200_drv.c| 3 +- drivers/gpu/drm/nouveau/nouveau_drm.c| 1 - drivers/gpu/drm/omapdrm/omap_drv.c | 8 -- drivers/gpu/drm/qxl/qxl_drv.c| 1 - drivers/gpu/drm/r128/r128_drv.c | 3 +- drivers/gpu/drm/radeon/radeon_drv.c | 8 +- drivers/gpu/drm/radeon/radeon_kms.c | 13 -- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 1 - drivers/gpu/drm/savage/savage_drv.c | 3 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 1 - drivers/gpu/drm/sis/sis_drv.c| 3 +- drivers/gpu/drm/tdfx/tdfx_drv.c | 2 - drivers/gpu/drm/tilcdc/tilcdc_drv.c | 1 - drivers/gpu/drm/udl/udl_drv.c| 1 - drivers/gpu/drm/via/via_drv.c| 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 20 --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - drivers/gpu/host1x/drm/drm.c | 1 - drivers/staging/imx-drm/imx-drm-core.c | 21 +--- include/drm/drmP.h | 52 ++-- 42 files changed, 253 insertions(+), 734 deletions(-) delete mode 100644 drivers/gpu/drm/drm_proc.c -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/25] drm/omap: kill firstopen callback
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2f9e22e..47e64f9 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -524,12 +524,6 @@ static int dev_open(struct drm_device *dev, struct
drm_file *file)
return 0;
}
-static int dev_firstopen(struct drm_device *dev)
-{
- DBG("firstopen: dev=%p", dev);
- return 0;
-}
-
/**
* lastclose - clean up after all DRM clients have exited
* @dev: DRM device
@@ -609,7 +603,6 @@ static struct drm_driver omap_drm_driver = {
.load = dev_load,
.unload = dev_unload,
.open = dev_open,
- .firstopen = dev_firstopen,
.lastclose = dev_lastclose,
.preclose = dev_preclose,
.postclose = dev_postclose,
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/25] drm/radeon: kill firstopen callback for kms driver
Again, it does nothing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_kms.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa7a7e1..3585f22 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -81,7 +81,6 @@
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
-int radeon_driver_firstopen_kms(struct drm_device *dev);
void radeon_driver_lastclose_kms(struct drm_device *dev);
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
void radeon_driver_postclose_kms(struct drm_device *dev,
@@ -390,7 +389,6 @@ static struct drm_driver kms_driver = {
DRIVER_PRIME,
.dev_priv_size = 0,
.load = radeon_driver_load_kms,
- .firstopen = radeon_driver_firstopen_kms,
.open = radeon_driver_open_kms,
.preclose = radeon_driver_preclose_kms,
.postclose = radeon_driver_postclose_kms,
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 866c2b7..b46a561 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -449,19 +449,6 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
* Outdated mess for old drm with Xorg being in charge (void function now).
*/
/**
- * radeon_driver_firstopen_kms - drm callback for first open
- *
- * @dev: drm dev pointer
- *
- * Nothing to be done for KMS (all asics).
- * Returns 0 on success.
- */
-int radeon_driver_firstopen_kms(struct drm_device *dev)
-{
- return 0;
-}
-
-/**
* radeon_driver_firstopen_kms - drm callback for last close
*
* @dev: drm dev pointer
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/25] drm/imx: kill firstopen callback
This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.
This patch here just moves the setup at the very end of the driver
load callback, with the locking adjusted accordingly.
v2: Also move the corresponding put from ->lastclose to ->unload.
Cc: Sascha Hauer
Cc: Greg Kroah-Hartman
Signed-off-by: Daniel Vetter
---
Note that this is already in the staging tree but due to the follow-up cleanup
it's probably best to merge it again through drm-next.
-Daniel
drivers/staging/imx-drm/imx-drm-core.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/imx-drm/imx-drm-core.c
b/drivers/staging/imx-drm/imx-drm-core.c
index a890049..2c58533 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -69,28 +69,20 @@ struct imx_drm_connector {
struct module *owner;
};
-static int imx_drm_driver_firstopen(struct drm_device *drm)
-{
- if (!imx_drm_device_get())
- return -EINVAL;
-
- return 0;
-}
-
static void imx_drm_driver_lastclose(struct drm_device *drm)
{
struct imx_drm_device *imxdrm = drm->dev_private;
if (imxdrm->fbhelper)
drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
-
- imx_drm_device_put();
}
static int imx_drm_driver_unload(struct drm_device *drm)
{
struct imx_drm_device *imxdrm = drm->dev_private;
+ imx_drm_device_put();
+
drm_mode_config_cleanup(imxdrm->drm);
drm_kms_helper_poll_fini(imxdrm->drm);
@@ -226,8 +218,6 @@ struct drm_device *imx_drm_device_get(void)
struct imx_drm_connector *con;
struct imx_drm_crtc *crtc;
- mutex_lock(&imxdrm->mutex);
-
list_for_each_entry(enc, &imxdrm->encoder_list, list) {
if (!try_module_get(enc->owner)) {
dev_err(imxdrm->dev, "could not get module %s\n",
@@ -254,8 +244,6 @@ struct drm_device *imx_drm_device_get(void)
imxdrm->references++;
- mutex_unlock(&imxdrm->mutex);
-
return imxdrm->drm;
unwind_crtc:
@@ -447,6 +435,9 @@ static int imx_drm_driver_load(struct drm_device *drm,
unsigned long flags)
*/
imxdrm->drm->vblank_disable_allowed = 1;
+ if (!imx_drm_device_get())
+ ret = -EINVAL;
+
ret = 0;
err_init:
@@ -791,7 +782,6 @@ static struct drm_driver imx_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM,
.load = imx_drm_driver_load,
.unload = imx_drm_driver_unload,
- .firstopen = imx_drm_driver_firstopen,
.lastclose = imx_drm_driver_lastclose,
.gem_free_object= drm_gem_cma_free_object,
.gem_vm_ops = &drm_gem_cma_vm_ops,
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/25] drm/vmwgfx: remove ->firstopen callback
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In short besides the semantically important vga switcheroo stuff they
all try very hard to keep fbcon working in case X dies.
But none of them try to not do this at driver unload time safe for
vmwgfx, and digging through logs I couldn't find any reason for why
vmwgfx is special.
Since ->firstopen has lots of potential for abuse with kms drivers
(like delaying driver setup to pamper over races in the load sequence)
it's imo very much worth it to remove this logic so that we can
stop using the ->firstopen callback for kms drivers.
Also module unloading is rather a debug feature and developers should
know how to restore the display to a sane configuration.
Cc: Jakob Bornecrantz
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 18 --
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 -
2 files changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 5086150..cebd847 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -795,29 +795,12 @@ static long vmw_unlocked_ioctl(struct file *filp,
unsigned int cmd,
return drm_ioctl(filp, cmd, arg);
}
-static int vmw_firstopen(struct drm_device *dev)
-{
- struct vmw_private *dev_priv = vmw_priv(dev);
- dev_priv->is_opened = true;
-
- return 0;
-}
-
static void vmw_lastclose(struct drm_device *dev)
{
- struct vmw_private *dev_priv = vmw_priv(dev);
struct drm_crtc *crtc;
struct drm_mode_set set;
int ret;
- /**
-* Do nothing on the lastclose call from drm_unload.
-*/
-
- if (!dev_priv->is_opened)
- return;
-
- dev_priv->is_opened = false;
set.x = 0;
set.y = 0;
set.fb = NULL;
@@ -1132,7 +1115,6 @@ static struct drm_driver driver = {
DRIVER_MODESET,
.load = vmw_driver_load,
.unload = vmw_driver_unload,
- .firstopen = vmw_firstopen,
.lastclose = vmw_lastclose,
.irq_preinstall = vmw_irq_preinstall,
.irq_postinstall = vmw_irq_postinstall,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 13aeda7..150ec64 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -324,7 +324,6 @@ struct vmw_private {
*/
bool stealth;
- bool is_opened;
bool enable_fb;
/**
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/25] drm: don't call ->firstopen for KMS drivers
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.
v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.
Cc: Laurent Pinchart
Acked-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 27 ---
drivers/gpu/drm/drm_fops.c | 3 ++-
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 87e22ec..c62d2d4 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2428,18 +2428,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.
@@ -2468,7 +2468,12 @@ void (*postclose) (struct drm_device *, struct drm_file
*);
The lastclose method should restore CRTC and
plane properties to default value, so that a subsequent open of the
- device will not inherit state from the previous user.
+ device will not inherit state from the previous user. It can also be
+ used to execute delayed power switching state changes, e.g. in
+ conjunction with the vga-switcheroo infrastructure. Beyond that KMS
+ drivers should not do any further cleanup. Only legacy UMS drivers might
+ need to clean up device state so that the vga console or an independent
+ fbdev driver could take over.
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 72acae9..10bf4f6 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;
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/25] drm: kill dev->driver->set_version
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ffd7a7b..0acf080 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -352,9 +352,6 @@ int drm_setversion(struct drm_device *dev, void *data,
struct drm_file *file_pri
retcode = -EINVAL;
goto done;
}
-
- if (dev->driver->set_version)
- dev->driver->set_version(dev, sv);
}
done:
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fba5473..7495fb2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -885,8 +885,6 @@ struct drm_driver {
void (*irq_preinstall) (struct drm_device *dev);
int (*irq_postinstall) (struct drm_device *dev);
void (*irq_uninstall) (struct drm_device *dev);
- void (*set_version) (struct drm_device *dev,
-struct drm_set_version *sv);
/* Master routines */
int (*master_create)(struct drm_device *dev, struct drm_master *master);
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/25] drm: hide legacy sg cleanup better from common code
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 6 +-
drivers/gpu/drm/drm_scatter.c | 10 +-
include/drm/drmP.h| 2 +-
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 799..743b24d 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -197,11 +197,7 @@ int drm_lastclose(struct drm_device * dev)
drm_agp_clear(dev);
- if (drm_core_check_feature(dev, DRIVER_SG) && dev->sg &&
- !drm_core_check_feature(dev, DRIVER_MODESET)) {
- drm_sg_cleanup(dev->sg);
- dev->sg = NULL;
- }
+ drm_legacy_sg_cleanup(dev);
/* Clear vma list (only built for debugging) */
list_for_each_entry_safe(vma, vma_temp, &dev->vmalist, head) {
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
index a4a076f..dd8a648 100644
--- a/drivers/gpu/drm/drm_scatter.c
+++ b/drivers/gpu/drm/drm_scatter.c
@@ -46,7 +46,7 @@ static inline void *drm_vmalloc_dma(unsigned long size)
#endif
}
-void drm_sg_cleanup(struct drm_sg_mem * entry)
+static void drm_sg_cleanup(struct drm_sg_mem * entry)
{
struct page *page;
int i;
@@ -64,6 +64,14 @@ void drm_sg_cleanup(struct drm_sg_mem * entry)
kfree(entry);
}
+void drm_legacy_sg_cleanup(struct drm_device *dev)
+{
+ if (drm_core_check_feature(dev, DRIVER_SG) && dev->sg &&
+ !drm_core_check_feature(dev, DRIVER_MODESET)) {
+ drm_sg_cleanup(dev->sg);
+ dev->sg = NULL;
+ }
+}
#ifdef _LP64
# define ScatterHandle(x) (unsigned int)((x >> 32) + (x & ((1L << 32) - 1)))
#else
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 7495fb2..bc38f99 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1567,7 +1567,7 @@ extern int drm_vma_info(struct seq_file *m, void *data);
#endif
/* Scatter Gather Support (drm_scatter.h) */
-extern void drm_sg_cleanup(struct drm_sg_mem * entry);
+extern void drm_legacy_sg_cleanup(struct drm_device *dev);
extern int drm_sg_alloc(struct drm_device *dev, void *data,
struct drm_file *file_priv);
extern int drm_sg_free(struct drm_device *dev, void *data,
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/25] drm: disallow legacy sg ioctls for modesetting drivers
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.
So we can safely disallow these pair of ioctls for modesetting
drivers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_scatter.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_scatter.c b/drivers/gpu/drm/drm_scatter.c
index dd8a648..1c78406 100644
--- a/drivers/gpu/drm/drm_scatter.c
+++ b/drivers/gpu/drm/drm_scatter.c
@@ -87,6 +87,9 @@ int drm_sg_alloc(struct drm_device *dev, void *data,
DRM_DEBUG("\n");
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
@@ -197,6 +200,9 @@ int drm_sg_free(struct drm_device *dev, void *data,
struct drm_scatter_gather *request = data;
struct drm_sg_mem *entry;
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
if (!drm_core_check_feature(dev, DRIVER_SG))
return -EINVAL;
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/25] drm: disallow legacy dma ioctls for modesetting drivers
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature flag set, so strictly speaking the modesetting check is redundant. But adding it has the upside that it makes it very clear that the dma support is legacy stuff. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_bufs.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index bef4abf..25f 100644 --- a/drivers/gpu/drm/drm_bufs.c +++ b/drivers/gpu/drm/drm_bufs.c @@ -1305,6 +1305,9 @@ int drm_addbufs(struct drm_device *dev, void *data, struct drm_buf_desc *request = data; int ret; + if (drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA)) return -EINVAL; @@ -1348,6 +1351,9 @@ int drm_infobufs(struct drm_device *dev, void *data, int i; int count; + if (drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA)) return -EINVAL; @@ -1427,6 +1433,9 @@ int drm_markbufs(struct drm_device *dev, void *data, int order; struct drm_buf_entry *entry; + if (drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA)) return -EINVAL; @@ -1472,6 +1481,9 @@ int drm_freebufs(struct drm_device *dev, void *data, int idx; struct drm_buf *buf; + if (drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA)) return -EINVAL; @@ -1524,6 +1536,9 @@ int drm_mapbufs(struct drm_device *dev, void *data, struct drm_buf_map *request = data; int i; + if (drm_core_check_feature(dev, DRIVER_MODESET)) + return -EINVAL; + if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA)) return -EINVAL; -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/25] drm: mark dma setup/teardown as legacy systems
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dma.c | 17 +++--
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_fops.c | 12 +++-
include/drm/drmP.h | 4 ++--
4 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_dma.c b/drivers/gpu/drm/drm_dma.c
index 495b5fd..8a140a9 100644
--- a/drivers/gpu/drm/drm_dma.c
+++ b/drivers/gpu/drm/drm_dma.c
@@ -44,10 +44,18 @@
*
* Allocate and initialize a drm_device_dma structure.
*/
-int drm_dma_setup(struct drm_device *dev)
+int drm_legacy_dma_setup(struct drm_device *dev)
{
int i;
+ if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA) ||
+ drm_core_check_feature(dev, DRIVER_MODESET)) {
+ return 0;
+ }
+
+ dev->buf_use = 0;
+ atomic_set(&dev->buf_alloc, 0);
+
dev->dma = kzalloc(sizeof(*dev->dma), GFP_KERNEL);
if (!dev->dma)
return -ENOMEM;
@@ -66,11 +74,16 @@ int drm_dma_setup(struct drm_device *dev)
* Free all pages associated with DMA buffers, the buffers and pages lists, and
* finally the drm_device::dma structure itself.
*/
-void drm_dma_takedown(struct drm_device *dev)
+void drm_legacy_dma_takedown(struct drm_device *dev)
{
struct drm_device_dma *dma = dev->dma;
int i, j;
+ if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA) ||
+ drm_core_check_feature(dev, DRIVER_MODESET)) {
+ return;
+ }
+
if (!dma)
return;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 743b24d..5b949a7 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -205,9 +205,7 @@ int drm_lastclose(struct drm_device * dev)
kfree(vma);
}
- if (drm_core_check_feature(dev, DRIVER_HAVE_DMA) &&
- !drm_core_check_feature(dev, DRIVER_MODESET))
- drm_dma_takedown(dev);
+ drm_legacy_dma_takedown(dev);
dev->dev_mapping = NULL;
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 10bf4f6..702e2a8 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -61,15 +61,9 @@ static int drm_setup(struct drm_device * dev)
atomic_set(&dev->ioctl_count, 0);
atomic_set(&dev->vma_count, 0);
- if (drm_core_check_feature(dev, DRIVER_HAVE_DMA) &&
- !drm_core_check_feature(dev, DRIVER_MODESET)) {
- dev->buf_use = 0;
- atomic_set(&dev->buf_alloc, 0);
-
- i = drm_dma_setup(dev);
- if (i < 0)
- return i;
- }
+ i = drm_legacy_dma_setup(dev);
+ if (i < 0)
+ return i;
for (i = 0; i < ARRAY_SIZE(dev->counts); i++)
atomic_set(&dev->counts[i], 0);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index bc38f99..de19e97 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1394,8 +1394,8 @@ extern int drm_mapbufs(struct drm_device *dev, void *data,
struct drm_file *file_priv);
/* DMA support (drm_dma.h) */
-extern int drm_dma_setup(struct drm_device *dev);
-extern void drm_dma_takedown(struct drm_device *dev);
+extern int drm_legacy_dma_setup(struct drm_device *dev);
+extern void drm_legacy_dma_takedown(struct drm_device *dev);
extern void drm_free_buffer(struct drm_device *dev, struct drm_buf * buf);
extern void drm_core_reclaim_buffers(struct drm_device *dev,
struct drm_file *filp);
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/25] drm/vmwgfx: remove redundant clearing of driver->dma_quiescent
It's kzalloced ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index cebd847..9c27d42 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1125,7 +1125,6 @@ static struct drm_driver driver = {
.disable_vblank = vmw_disable_vblank,
.ioctls = vmw_ioctls,
.num_ioctls = DRM_ARRAY_SIZE(vmw_ioctls),
- .dma_quiescent = NULL, /*vmw_dma_quiescent, */
.master_create = vmw_master_create,
.master_destroy = vmw_master_destroy,
.master_set = vmw_master_set,
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/25] drm: mark context support as a legacy subsystem
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).
Also add the drm_legacy prefix for functions which are called from
common code. To further reduce the impact on common code also extract
all the ctx release handling into a function (instead of only
releasing individual handles) and make ctxbitmap_cleanup return void -
it can never fail.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_context.c | 73 ++-
drivers/gpu/drm/drm_fops.c| 21 +
drivers/gpu/drm/drm_stub.c| 10 ++
include/drm/drmP.h| 7 +++--
4 files changed, 72 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 224ff96..b4fb86d 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -42,10 +42,6 @@
#include
-/**/
-/** \name Context bitmap support */
-/*@{*/
-
/**
* Free a handle from the context bitmap.
*
@@ -56,13 +52,48 @@
* in drm_device::ctx_idr, while holding the drm_device::struct_mutex
* lock.
*/
-void drm_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
+static void drm_ctxbitmap_free(struct drm_device * dev, int ctx_handle)
{
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
mutex_lock(&dev->struct_mutex);
idr_remove(&dev->ctx_idr, ctx_handle);
mutex_unlock(&dev->struct_mutex);
}
+/**/
+/** \name Context bitmap support */
+/*@{*/
+
+void drm_legacy_ctxbitmap_release(struct drm_device *dev,
+ struct drm_file *file_priv)
+{
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ mutex_lock(&dev->ctxlist_mutex);
+ if (!list_empty(&dev->ctxlist)) {
+ struct drm_ctx_list *pos, *n;
+
+ list_for_each_entry_safe(pos, n, &dev->ctxlist, head) {
+ if (pos->tag == file_priv &&
+ pos->handle != DRM_KERNEL_CONTEXT) {
+ if (dev->driver->context_dtor)
+ dev->driver->context_dtor(dev,
+ pos->handle);
+
+ drm_ctxbitmap_free(dev, pos->handle);
+
+ list_del(&pos->head);
+ kfree(pos);
+ --dev->ctx_count;
+ }
+ }
+ }
+ mutex_unlock(&dev->ctxlist_mutex);
+}
+
/**
* Context bitmap allocation.
*
@@ -90,10 +121,12 @@ static int drm_ctxbitmap_next(struct drm_device * dev)
*
* Initialise the drm_device::ctx_idr
*/
-int drm_ctxbitmap_init(struct drm_device * dev)
+void drm_legacy_ctxbitmap_init(struct drm_device * dev)
{
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
idr_init(&dev->ctx_idr);
- return 0;
}
/**
@@ -104,7 +137,7 @@ int drm_ctxbitmap_init(struct drm_device * dev)
* Free all idr members using drm_ctx_sarea_free helper function
* while holding the drm_device::struct_mutex lock.
*/
-void drm_ctxbitmap_cleanup(struct drm_device * dev)
+void drm_legacy_ctxbitmap_cleanup(struct drm_device * dev)
{
mutex_lock(&dev->struct_mutex);
idr_destroy(&dev->ctx_idr);
@@ -136,6 +169,9 @@ int drm_getsareactx(struct drm_device *dev, void *data,
struct drm_local_map *map;
struct drm_map_list *_entry;
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
mutex_lock(&dev->struct_mutex);
map = idr_find(&dev->ctx_idr, request->ctx_id);
@@ -180,6 +216,9 @@ int drm_setsareactx(struct drm_device *dev, void *data,
struct drm_local_map *map = NULL;
struct drm_map_list *r_list = NULL;
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
mutex_lock(&dev->struct_mutex);
list_for_each_entry(r_list, &dev->maplist, head) {
if (r_list->map
@@ -280,6 +319,9 @@ int drm_resctx(struct drm_device *dev, void *data,
struct drm_ctx ctx;
int i;
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
if (res->count >= DRM_RESERVED_CONTEXTS) {
memset(&ctx, 0, sizeof(ctx));
for (i = 0; i < DRM_RESERVED_CONTEXTS; i++) {
@@ -310,6 +352,9 @@ int drm_addctx(struct drm_device *dev, void *data,
struct drm_ctx_list *ctx_entry;
struct drm_ctx *ctx = data;
+ if (drm_core_check_feature(dev, DRIVER_MODES
[PATCH 13/25] drm: remove FASYNC support
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
Acked-by: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
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 c62d2d4..d51d157 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2509,7 +2509,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 a144fb0..60f1ce3 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 d35d99c..dd9c908 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 dd47fef..5679971 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -74,8 +74,6 @@ static int drm_setup(struct drm_device * dev)
dev->last_context = 0;
dev->if_version = 0;
- dev->buf_async = NULL;
-
DRM_DEBUG("\n");
/*
@@ -373,18 +371,6 @@ out_put_pid:
return ret;
[PATCH 14/25] drm: rip out DRIVER_FB_DMA and related code
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 161 +
include/drm/drmP.h | 1 -
2 files changed, 2 insertions(+), 160 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 25f..5f73f0a 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1130,161 +1130,6 @@ static int drm_addbufs_sg(struct drm_device * dev,
struct drm_buf_desc * request
return 0;
}
-static int drm_addbufs_fb(struct drm_device * dev, struct drm_buf_desc *
request)
-{
- struct drm_device_dma *dma = dev->dma;
- struct drm_buf_entry *entry;
- struct drm_buf *buf;
- unsigned long offset;
- unsigned long agp_offset;
- int count;
- int order;
- int size;
- int alignment;
- int page_order;
- int total;
- int byte_count;
- int i;
- struct drm_buf **temp_buflist;
-
- if (!drm_core_check_feature(dev, DRIVER_FB_DMA))
- return -EINVAL;
-
- if (!dma)
- return -EINVAL;
-
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- count = request->count;
- order = order_base_2(request->size);
- size = 1 << order;
-
- alignment = (request->flags & _DRM_PAGE_ALIGN)
- ? PAGE_ALIGN(size) : size;
- page_order = order - PAGE_SHIFT > 0 ? order - PAGE_SHIFT : 0;
- total = PAGE_SIZE << page_order;
-
- byte_count = 0;
- agp_offset = request->agp_start;
-
- DRM_DEBUG("count: %d\n", count);
- DRM_DEBUG("order: %d\n", order);
- DRM_DEBUG("size: %d\n", size);
- DRM_DEBUG("agp_offset: %lu\n", agp_offset);
- DRM_DEBUG("alignment: %d\n", alignment);
- DRM_DEBUG("page_order: %d\n", page_order);
- DRM_DEBUG("total: %d\n", total);
-
- if (order < DRM_MIN_ORDER || order > DRM_MAX_ORDER)
- return -EINVAL;
-
- spin_lock(&dev->count_lock);
- if (dev->buf_use) {
- spin_unlock(&dev->count_lock);
- return -EBUSY;
- }
- atomic_inc(&dev->buf_alloc);
- spin_unlock(&dev->count_lock);
-
- mutex_lock(&dev->struct_mutex);
- entry = &dma->bufs[order];
- if (entry->buf_count) {
- mutex_unlock(&dev->struct_mutex);
- atomic_dec(&dev->buf_alloc);
- return -ENOMEM; /* May only call once for each order */
- }
-
- if (count < 0 || count > 4096) {
- mutex_unlock(&dev->struct_mutex);
- atomic_dec(&dev->buf_alloc);
- return -EINVAL;
- }
-
- entry->buflist = kzalloc(count * sizeof(*entry->buflist),
- GFP_KERNEL);
- if (!entry->buflist) {
- mutex_unlock(&dev->struct_mutex);
- atomic_dec(&dev->buf_alloc);
- return -ENOMEM;
- }
-
- entry->buf_size = size;
- entry->page_order = page_order;
-
- offset = 0;
-
- while (entry->buf_count < count) {
- buf = &entry->buflist[entry->buf_count];
- buf->idx = dma->buf_count + entry->buf_count;
- buf->total = alignment;
- buf->order = order;
- buf->used = 0;
-
- buf->offset = (dma->byte_count + offset);
- buf->bus_address = agp_offset + offset;
- buf->address = (void *)(agp_offset + offset);
- buf->next = NULL;
- buf->waiting = 0;
- buf->pending = 0;
- buf->file_priv = NULL;
-
- buf->dev_priv_size = dev->driver->dev_priv_size;
- buf->dev_private = kzalloc(buf->dev_priv_size, GFP_KERNEL);
- if (!buf->dev_private) {
- /* Set count correctly so we free the proper amount. */
- entry->buf_count = count;
- drm_cleanup_buf_error(dev, entry);
- mutex_unlock(&dev->struct_mutex);
- atomic_dec(&dev->buf_alloc);
- return -ENOMEM;
- }
-
- DRM_DEBUG("buffer %d @ %p\n", entry->buf_count, buf->address);
-
- offset += alignment;
- entry->buf_count++;
- byte_count += PAGE_SIZE << page_order;
- }
-
- DRM_DEBUG("byte_count: %d\n", byte_count);
-
- temp_buflist = krealloc(dma->buflist,
- (dma->buf_count + entry->buf_count) *
- sizeof(*dma->buflist), GFP_KERNEL);
- if (!temp_buflist) {
- /* Free the entry because it isn't valid */
- drm_cleanup_buf_error(dev, entry);
- mutex_unlock(&dev->struct_mutex);
- atomic_dec(&dev->buf_alloc);
- return -ENOMEM;
- }
- dma->buflist
[PATCH 16/25] drm: remove a bunch of unused #defines from drmP.h
Signed-off-by: Daniel Vetter --- include/drm/drmP.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index f526a7a9..914055e 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -165,13 +165,7 @@ int drm_err(const char *func, const char *format, ...); #define DRM_MAGIC_HASH_ORDER 4 /**< Size of key hash table. Must be power of 2. */ #define DRM_KERNEL_CONTEXT0 /**< Change drm_resctx if changed */ #define DRM_RESERVED_CONTEXTS 1 /**< Change drm_resctx if changed */ -#define DRM_LOOPING_LIMIT 500 -#define DRM_TIME_SLICE (HZ/20) /**< Time slice for GLXContexts */ -#define DRM_LOCK_SLICE 1 /**< Time slice for lock, in jiffies */ -#define DRM_FLAG_DEBUG 0x01 - -#define DRM_MAX_CTXBITMAP (PAGE_SIZE * 8) #define DRM_MAP_HASH_OFFSET 0x1000 /*@}*/ @@ -260,9 +254,6 @@ int drm_err(const char *func, const char *format, ...); #define DRM_ARRAY_SIZE(x) ARRAY_SIZE(x) -#define DRM_LEFTCOUNT(x) (((x)->rp + (x)->count - (x)->wp) % ((x)->count + 1)) -#define DRM_BUFCOUNT(x) ((x)->count - DRM_LEFTCOUNT(x)) - #define DRM_IF_VERSION(maj, min) (maj << 16 | min) /** -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/25] drm: rip out a few unused DRIVER flags
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
include/drm/drmP.h | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 99b5293..1383e75 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -627,7 +627,7 @@ static const struct file_operations psb_gem_fops = {
static struct drm_driver driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | \
- DRIVER_IRQ_VBL | DRIVER_MODESET | DRIVER_GEM ,
+ DRIVER_MODESET | DRIVER_GEM ,
.load = psb_driver_load,
.unload = psb_driver_unload,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 81de427..f526a7a9 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -147,9 +147,6 @@ int drm_err(const char *func, const char *format, ...);
#define DRIVER_HAVE_DMA0x20
#define DRIVER_HAVE_IRQ0x40
#define DRIVER_IRQ_SHARED 0x80
-#define DRIVER_IRQ_VBL 0x100
-#define DRIVER_DMA_QUEUE 0x200
-#define DRIVER_IRQ_VBL20x800
#define DRIVER_GEM 0x1000
#define DRIVER_MODESET 0x2000
#define DRIVER_PRIME 0x4000
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/25] drm: rip out drm_core_has_MTRR checks
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected drivers. David helped a lot in that. Quoting our mail
discussion:
On Wed, Jul 10, 2013 at 5:41 PM, David Herrmann wrote:
> On Wed, Jul 10, 2013 at 5:22 PM, Daniel Vetter wrote:
>> On Wed, Jul 10, 2013 at 3:51 PM, David Herrmann
>> wrote:
-#if __OS_HAS_MTRR
-static inline int drm_core_has_MTRR(struct drm_device *dev)
-{
- return drm_core_check_feature(dev, DRIVER_USE_MTRR);
-}
-#else
-#define drm_core_has_MTRR(dev) (0)
-#endif
-
>>>
>>> That was the last user of DRIVER_USE_MTRR (apart from drivers setting
>>> it in .driver_features). Any reason to keep it around?
>>
>> Yeah, I guess we could rip things out. Which will also force me to
>> properly audit drivers for the eventual behaviour change this could
>> entail (in case there's an x86 driver which did not ask for an mtrr,
>> but iirc there isn't).
>
> david@david-mb ~/dev/kernel/linux $ for i in drivers/gpu/drm/* ; do if
> test -d "$i" ; then if ! grep -q USE_MTRR -r $i ; then echo $i ; fi ;
> fi ; done
> drivers/gpu/drm/exynos
> drivers/gpu/drm/gma500
> drivers/gpu/drm/i2c
> drivers/gpu/drm/nouveau
> drivers/gpu/drm/omapdrm
> drivers/gpu/drm/qxl
> drivers/gpu/drm/rcar-du
> drivers/gpu/drm/shmobile
> drivers/gpu/drm/tilcdc
> drivers/gpu/drm/ttm
> drivers/gpu/drm/udl
> drivers/gpu/drm/vmwgfx
> david@david-mb ~/dev/kernel/linux $
>
> So for x86 gma500,nouveau,qxl,udl,vmwgfx don't set DRIVER_USE_MTRR.
> But I cannot tell whether they break if we call arch_phys_wc_add/del,
> anyway. At least nouveau seemed to work here, but it doesn't use AGP
> or drm_bufs, I guess.
Cool, thanks a lot for stitching together the list of drivers to look
at. So for real KMS drivers it's the drives responsibility to add an
mtrr if it needs one. nouvea, radeon, mgag200, i915 and vmwgfx do that
already. Somehow the savage driver also ends up doing that, I have no
idea why.
Note that gma500 as a pure KMS driver doesn't need MTRR setup since
the platforms that it supports all support PAT. So no MTRRs needed to
get wc iomappings.
The mtrr support in the drm core is all for legacy mappings of garts,
framebuffers and registers. All legacy drivers set the USE_MTRR flag,
so we're good there.
All in all I think we can really just ditch this
/endquote
v2: Also kill DRIVER_USE_MTRR as suggested by David Herrmann
v3: Rebase on top of David Herrmann's agp setup/cleanup changes.
Cc: David Herrmann
Cc: Andy Lutomirski
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 13 +
drivers/gpu/drm/drm_pci.c | 14 ++
drivers/gpu/drm/drm_vm.c | 3 +--
drivers/gpu/drm/i810/i810_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/mga/mga_drv.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
drivers/gpu/drm/r128/r128_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 4 ++--
drivers/gpu/drm/savage/savage_drv.c | 2 +-
drivers/gpu/drm/sis/sis_drv.c | 2 +-
drivers/gpu/drm/tdfx/tdfx_drv.c | 1 -
drivers/gpu/drm/via/via_drv.c | 2 +-
include/drm/drmP.h| 11 ---
16 files changed, 24 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 60f1ce3..32e270d 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -197,7 +197,7 @@ static const struct file_operations ast_fops = {
};
static struct drm_driver driver = {
- .driver_features = DRIVER_USE_MTRR | DRIVER_MODESET | DRIVER_GEM,
+ .driver_features = DRIVER_MODESET | DRIVER_GEM,
.dev_priv_size = 0,
.load = ast_driver_load,
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index dd9c908..138364d 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -87,7 +87,7 @@ static const struct file_operations cirrus_driver_fops = {
#endif
};
static struct drm_driver driver = {
- .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_USE_MTRR,
+ .driver_features = DRIVER_MODESET | DRIVER_GEM,
.load = cirrus_driver_load,
.unload = cirrus_driver_unload,
.fops = &cirrus_driver_fops,
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 5f73f0a..f63133b 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -207,12 +207,10 @@ static int drm_addmap_core(struct drm_device * dev,
resource_size_t offset,
return 0;
}
- if (drm
[PATCH 18/25] drm/docs: rip out removed driver flags documentation
I've forgotten this and shuffling all the little pieces into the respective patches is rather cumbersome ... Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 29 - 1 file changed, 29 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index d51d157..4609cea 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -156,13 +156,6 @@ -DRIVER_USE_MTRR - - Driver uses MTRR interface for mapping memory, the DRM core will - manage MTRR resources. Deprecated. - - - DRIVER_PCI_DMA Driver is capable of PCI DMA, mapping of PCI DMA buffers to @@ -195,28 +188,6 @@ -DRIVER_IRQ_VBL -Unused. Deprecated. - - -DRIVER_DMA_QUEUE - - Should be set if the driver queues DMA requests and completes them - asynchronously. Deprecated. - - - -DRIVER_FB_DMA - - Driver supports DMA to/from the framebuffer, mapping of frambuffer - DMA buffers to userspace will be supported. Deprecated. - - - -DRIVER_IRQ_VBL2 -Unused. Deprecated. - - DRIVER_GEM Driver use the GEM memory manager. -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/25] drm: remove the dma_ioctl special-case
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitly check for that in the new ioctl implementation.
v2: Drop the unused variable I've accidentally left in the code,
spotted by David Herrmann.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 12
drivers/gpu/drm/drm_drv.c | 6 +-
include/drm/drmP.h | 2 ++
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index f63133b..471e051d 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1455,6 +1455,18 @@ int drm_mapbufs(struct drm_device *dev, void *data,
return retcode;
}
+int drm_dma_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if (dev->driver->dma_ioctl)
+ return dev->driver->dma_ioctl(dev, data, file_priv);
+ else
+ return -EINVAL;
+}
+
struct drm_local_map *drm_getsarea(struct drm_device *dev)
{
struct drm_map_list *entry;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 5b949a7..83078cd 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -106,8 +106,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_INFO_BUFS, drm_infobufs, DRM_AUTH),
DRM_IOCTL_DEF(DRM_IOCTL_MAP_BUFS, drm_mapbufs, DRM_AUTH),
DRM_IOCTL_DEF(DRM_IOCTL_FREE_BUFS, drm_freebufs, DRM_AUTH),
- /* The DRM_IOCTL_DMA ioctl should be defined by the driver. */
- DRM_IOCTL_DEF(DRM_IOCTL_DMA, NULL, DRM_AUTH),
+ DRM_IOCTL_DEF(DRM_IOCTL_DMA, drm_dma_ioctl, DRM_AUTH),
DRM_IOCTL_DEF(DRM_IOCTL_CONTROL, drm_control,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
@@ -395,9 +394,6 @@ long drm_ioctl(struct file *filp,
/* Do not trust userspace, use our own definition */
func = ioctl->func;
- /* is there a local override? */
- if ((nr == DRM_IOCTL_NR(DRM_IOCTL_DMA)) && dev->driver->dma_ioctl)
- func = dev->driver->dma_ioctl;
if (!func) {
DRM_DEBUG("no function\n");
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5b9462d..2a2a5b7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1366,6 +1366,8 @@ extern int drm_freebufs(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
extern int drm_mapbufs(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int drm_dma_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
/* DMA support (drm_dma.h) */
extern int drm_legacy_dma_setup(struct drm_device *dev);
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/25] drm/memory: don't export agp helpers
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that upper-case P sometimes ;-) But that's all stuff for future patch
bombs.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_memory.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c
index 126d50e..64e44fa 100644
--- a/drivers/gpu/drm/drm_memory.c
+++ b/drivers/gpu/drm/drm_memory.c
@@ -86,7 +86,6 @@ void drm_free_agp(DRM_AGP_MEM * handle, int pages)
{
agp_free_memory(handle);
}
-EXPORT_SYMBOL(drm_free_agp);
/** Wrapper around agp_bind_memory() */
int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start)
@@ -99,7 +98,6 @@ int drm_unbind_agp(DRM_AGP_MEM * handle)
{
return agp_unbind_memory(handle);
}
-EXPORT_SYMBOL(drm_unbind_agp);
#else /* __OS_HAS_AGP */
static inline void *agp_remap(unsigned long offset, unsigned long size,
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 21/25] drm: hollow-out GET_CLIENT ioctl
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tests/dristat.c and drm/tests/getclients.c. The later
is a testcase for the ioctl itself since up to
commit b018fcdaa5e8b4eabb8cffda687d4a3c4785
Author: Eric Anholt
Date: Thu Nov 22 18:46:54 2007 +1000
drm: Make DRM_IOCTL_GET_CLIENT return EINVAL when it can't find client #idx
there was actually no way at all for userspace to enumerate all
clients since the kernel just wouldn't tell it when to stop. Which
completely broke it's only user, dristat -c.
So obviously that ioctl wasn't much use for debugging. Hence I don't
see any point in keeping support for a tool which was pretty obviously
never really used, and while we have good replacements in the form of
equivalent debugfs files.
Still, to keep dristat -c from looping forever again stop it early by
returning an unconditional -EINVAL. Also add a comment in the code
about why.
v2: Slightly less hollowed-out implementation. libva uses GET_CLIENTS
to figure out whether the fd it has is already authenticated or not.
So we need to keep that part of things working. Simplest way is to
just return one entry to keep va_drm_is_authenticated in
libva/va/drm/va_drm_auth.c working.
This is exercised by igt/drm_get_client_auth which contains a
copypasta of the libva auth check code.
Cc: Gwenole Beauchesne
Cc: David Herrmann
Cc: Eric Anholt
Reviewed-by: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 0acf080..ac8ca5c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -217,29 +217,30 @@ int drm_getclient(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_client *client = data;
- struct drm_file *pt;
- int idx;
- int i;
-
- idx = client->idx;
- i = 0;
- mutex_lock(&dev->struct_mutex);
- list_for_each_entry(pt, &dev->filelist, lhead) {
- if (i++ >= idx) {
- client->auth = pt->authenticated;
- client->pid = pid_vnr(pt->pid);
- client->uid = from_kuid_munged(current_user_ns(),
pt->uid);
- client->magic = pt->magic;
- client->iocs = pt->ioctl_count;
- mutex_unlock(&dev->struct_mutex);
-
- return 0;
- }
+ /*
+* Hollowed-out getclient ioctl to keep some dead old drm tests/tools
+* not breaking completely. Userspace tools stop enumerating one they
+* get -EINVAL, hence this is the return value we need to hand back for
+* no clients tracked.
+*
+* Unfortunately some clients (*cough* libva *cough*) use this in a fun
+* attempt to figure out whether they're authenticated or not. Since
+* that's the only thing they care about, give it to the directly
+* instead of walking one giant list.
+*/
+ if (client->idx == 0) {
+ client->auth = file_priv->authenticated;
+ client->pid = pid_vnr(file_priv->pid);
+ client->uid = from_kuid_munged(current_user_ns(),
+ file_priv->uid);
+ client->magic = 0;
+ client->iocs = 0;
+
+ return 0;
+ } else {
+ return -EINVAL;
}
- mutex_unlock(&dev->struct_mutex);
-
- return -EINVAL;
}
/**
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 22/25] drm: no-op out GET_STATS ioctl
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use for this stat gathering complexity at all.
To be able to gradually drop things start with ripping out the
interfaces to it, here the ioctl.
To prevent dristat from eating its own stack garbage we can't use the
drm_noop ioctl though, since we need to clear the return data with a
memset.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ac8ca5c..cffc7c0 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -257,21 +257,10 @@ int drm_getstats(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_stats *stats = data;
- int i;
+ /* Clear stats to prevent userspace from eating its stack garbage. */
memset(stats, 0, sizeof(*stats));
- for (i = 0; i < dev->counters; i++) {
- if (dev->types[i] == _DRM_STAT_LOCK)
- stats->data[i].value =
- (file_priv->master->lock.hw_lock ?
file_priv->master->lock.hw_lock->lock : 0);
- else
- stats->data[i].value = atomic_read(&dev->counts[i]);
- stats->data[i].type = dev->types[i];
- }
-
- stats->count = dev->counters;
-
return 0;
}
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 23/25] drm: fix locking in gem debugfs/procfs file
The idr is protected with our spinlock, if we don't hold that nothing prevents the gem objects from disappearing from under us. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_info.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c index d4b20ce..9f8fc4c 100644 --- a/drivers/gpu/drm/drm_info.c +++ b/drivers/gpu/drm/drm_info.c @@ -218,7 +218,11 @@ int drm_gem_name_info(struct seq_file *m, void *data) struct drm_device *dev = node->minor->dev; seq_printf(m, " name size handles refcount\n"); + + spin_lock(&dev->object_name_lock); idr_for_each(&dev->object_name_idr, drm_gem_one_name_info, m); + spin_unlock(&dev->object_name_lock); + return 0; } -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 24/25] drm: remove procfs code, take 2
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging it turned out that the drmstat tool in libdrm is still using
those files (but only when certain options are set). So we've decided
to keep profcs.
But I when I've started to dig around again what exactly this tool
does I've noticed that it tries to read the "mem", "vm", and "vma"
files from procfs. Now as far my git history digging shows "mem" never
did anything useful (at least in the version that first showed up in
upstream history in 2004) and the file was remove in
commit 955b12def42e83287c1bdb1411d99451753c1391
Author: Ben Gamari
Date: Tue Feb 17 20:08:49 2009 -0500
drm: Convert proc files to seq_file and introduce debugfs
Which means that for over 4 years drmstat has been broken, and no one
cared. In my opinion that's proof enough that no one is actually using
drmstat, and so that we can savely nuke the procfs support from drm.
While at it fix up the error case cleanup for debugfs in drm_get_minor.
v2: Fix dates, libdrm stopped relying on procfs for drm node detection
in 2001.
v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
Fengguang Wu.
Cc: kbuild test robot
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_drv.c | 8 --
drivers/gpu/drm/drm_proc.c | 209 -
drivers/gpu/drm/drm_stub.c | 32 ++-
include/drm/drmP.h | 8 --
5 files changed, 9 insertions(+), 250 deletions(-)
delete mode 100644 drivers/gpu/drm/drm_proc.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index d943b94..55af865 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -7,7 +7,7 @@ ccflags-y := -Iinclude/drm
drm-y := drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \
drm_context.o drm_dma.o \
drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
- drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
+ drm_lock.o drm_memory.o drm_stub.o drm_vm.o \
drm_agpsupport.o drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 83078cd..a845f31 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -237,13 +237,6 @@ static int __init drm_core_init(void)
goto err_p2;
}
- drm_proc_root = proc_mkdir("dri", NULL);
- if (!drm_proc_root) {
- DRM_ERROR("Cannot create /proc/dri\n");
- ret = -1;
- goto err_p3;
- }
-
drm_debugfs_root = debugfs_create_dir("dri", NULL);
if (!drm_debugfs_root) {
DRM_ERROR("Cannot create /sys/kernel/debug/dri\n");
@@ -266,7 +259,6 @@ err_p1:
static void __exit drm_core_exit(void)
{
- remove_proc_entry("dri", NULL);
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
deleted file mode 100644
index d7f2324..000
--- a/drivers/gpu/drm/drm_proc.c
+++ /dev/null
@@ -1,209 +0,0 @@
-/**
- * \file drm_proc.c
- * /proc support for DRM
- *
- * \author Rickard E. (Rik) Faith
- * \author Gareth Hughes
- *
- * \par Acknowledgements:
- *Matthew J Sottek sent in a patch to fix
- *the problem with the proc files not outputting all their information.
- */
-
-/*
- * Created: Mon Jan 11 09:48:47 1999 by fa...@valinux.com
- *
- * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
- * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OT
[PATCH 25/25] drm: move dev data clearing from drm_setup to lastclose
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
conditionalize the code on !DRIVER_MODESET.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 27 +++
drivers/gpu/drm/drm_fops.c | 27 +++
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a845f31..3b8d044 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -171,6 +171,31 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
/**
+ * drm_legacy_dev_reinit
+ *
+ * Reinitializes a legacy/ums drm device in it's lastclose function.
+ */
+static void drm_legacy_dev_reinit(struct drm_device *dev)
+{
+ int i;
+
+ if (drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ atomic_set(&dev->ioctl_count, 0);
+ atomic_set(&dev->vma_count, 0);
+
+ for (i = 0; i < ARRAY_SIZE(dev->counts); i++)
+ atomic_set(&dev->counts[i], 0);
+
+ dev->sigdata.lock = NULL;
+
+ dev->context_flag = 0;
+ dev->last_context = 0;
+ dev->if_version = 0;
+}
+
+/**
* Take down the DRM device.
*
* \param dev DRM device structure.
@@ -209,6 +234,8 @@ int drm_lastclose(struct drm_device * dev)
dev->dev_mapping = NULL;
mutex_unlock(&dev->struct_mutex);
+ drm_legacy_dev_reinit(dev);
+
DRM_DEBUG("lastclose completed\n");
return 0;
}
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5679971..59f4592 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -48,7 +48,6 @@ static int drm_open_helper(struct inode *inode, struct file
*filp,
static int drm_setup(struct drm_device * dev)
{
- int i;
int ret;
if (dev->driver->firstopen &&
@@ -58,32 +57,12 @@ static int drm_setup(struct drm_device * dev)
return ret;
}
- atomic_set(&dev->ioctl_count, 0);
- atomic_set(&dev->vma_count, 0);
-
- i = drm_legacy_dma_setup(dev);
- if (i < 0)
- return i;
-
- for (i = 0; i < ARRAY_SIZE(dev->counts); i++)
- atomic_set(&dev->counts[i], 0);
-
- dev->sigdata.lock = NULL;
+ ret = drm_legacy_dma_setup(dev);
+ if (ret < 0)
+ return ret;
- dev->context_flag = 0;
- dev->last_context = 0;
- dev->if_version = 0;
DRM_DEBUG("\n");
-
- /*
-* The kernel's context could be created here, but is now created
-* in drm_dma_enqueue. This is more resource-efficient for
-* hardware that does not do DMA, but may mean that
-* drm_select_queue fails between the time the interrupt is
-* initialized and the time the queues are initialized.
-*/
-
return 0;
}
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/25] drm/omap: kill firstopen callback
On Thu, Aug 8, 2013 at 9:41 AM, Daniel Vetter wrote:
> KMS drivers really shouldn't need to do anything on firstopen, so kill
> empty callbacks.
>
> Signed-off-by: Daniel Vetter
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 2f9e22e..47e64f9 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -524,12 +524,6 @@ static int dev_open(struct drm_device *dev, struct
> drm_file *file)
> return 0;
> }
>
> -static int dev_firstopen(struct drm_device *dev)
> -{
> - DBG("firstopen: dev=%p", dev);
> - return 0;
> -}
> -
> /**
> * lastclose - clean up after all DRM clients have exited
> * @dev: DRM device
> @@ -609,7 +603,6 @@ static struct drm_driver omap_drm_driver = {
> .load = dev_load,
> .unload = dev_unload,
> .open = dev_open,
> - .firstopen = dev_firstopen,
> .lastclose = dev_lastclose,
> .preclose = dev_preclose,
> .postclose = dev_postclose,
> --
> 1.8.3.2
>
> ___
> 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 06/25] drm: kill dev->driver->set_version
On Thu, Aug 8, 2013 at 9:41 AM, Daniel Vetter wrote:
> Totally unused, so just rip it out. Anyway, we want drivers to be
> fully backwards compatible, allowing them to change behaviour is just
> a recipe for them to break badly.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 ---
> include/drm/drmP.h | 2 --
> 2 files changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index ffd7a7b..0acf080 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -352,9 +352,6 @@ int drm_setversion(struct drm_device *dev, void *data,
> struct drm_file *file_pri
> retcode = -EINVAL;
> goto done;
> }
> -
> - if (dev->driver->set_version)
> - dev->driver->set_version(dev, sv);
> }
>
> done:
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index fba5473..7495fb2 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -885,8 +885,6 @@ struct drm_driver {
> void (*irq_preinstall) (struct drm_device *dev);
> int (*irq_postinstall) (struct drm_device *dev);
> void (*irq_uninstall) (struct drm_device *dev);
> - void (*set_version) (struct drm_device *dev,
> -struct drm_set_version *sv);
>
> /* Master routines */
> int (*master_create)(struct drm_device *dev, struct drm_master
> *master);
> --
> 1.8.3.2
>
> ___
> 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: [Intel-gfx] 3.10.2 : new warning WARNING: at drivers/gpu/drm/i915/intel_display.c:1656 ironlake_crtc_disable+0x7ce/0x800 [i915]()
On 08/06/2013 08:03 PM, Daniel Vetter wrote: > On Tue, Aug 6, 2013 at 7:42 PM, Toralf Förster wrote: >> On 07/26/2013 07:58 PM, Daniel Vetter wrote: >>> On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf Förster wrote: Realized this today while booting a ThinkPad T420 with integrated intel graphic : >>> >>> Can you please retest with latest upstream git from Linus' tree? >> >> erm, that patch won't apply onto 3.10.5 : >> >> patch -p1 --dry-run < /home/tfoerste/devel/my/drm.patch >> patching file drivers/gpu/drm/i915/intel_display.c >> Hunk #1 FAILED at 8314. >> Hunk #2 FAILED at 9814. >> Hunk #3 succeeded at 5754 with fuzz 2 (offset -4112 lines). >> Hunk #4 succeeded at 9420 with fuzz 1 (offset -462 lines). >> 2 out of 4 hunks FAILED -- saving rejects to file >> drivers/gpu/drm/i915/intel_display.c.rej > > The code is completely reworked in 3.11 so this won't ever apply > as-is. But in any case stable rules dictate that a bug must be fixed > in the latest upstream code first. Henc can you please test the latest > 3.11-rc kernel? > > Thanks, Daniel > Tried it few times in a row - didn't observed that issue any more (3.11-rc4) -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/gem: add drm_gem_create_mmap_offset_size()
Hi
On Wed, Aug 7, 2013 at 7:41 PM, Rob Clark wrote:
> Variant of drm_gem_create_mmap_offset() which doesn't make the
> assumption that virtual size and physical size (obj->size) are the same.
> This is needed in omapdrm to deal with tiled buffers. And lets us get
> rid of a duplicated and slightly modified version of
> drm_gem_create_mmap_offset() in omapdrm.
>
> Signed-off-by: Rob Clark
Reviewed-by: David Herrmann
Regards
David
> ---
> drivers/gpu/drm/drm_gem.c | 28
> include/drm/drmP.h| 1 +
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 1f76572..84d59f7 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -303,24 +303,44 @@ drm_gem_free_mmap_offset(struct drm_gem_object *obj)
> EXPORT_SYMBOL(drm_gem_free_mmap_offset);
>
> /**
> - * drm_gem_create_mmap_offset - create a fake mmap offset for an object
> + * drm_gem_create_mmap_offset_size - create a fake mmap offset for an object
> * @obj: obj in question
> + * @size: the virtual size
> *
> * GEM memory mapping works by handing back to userspace a fake mmap offset
> * it can use in a subsequent mmap(2) call. The DRM core code then looks
> * up the object based on the offset and sets up the various memory mapping
> * structures.
> *
> - * This routine allocates and attaches a fake offset for @obj.
> + * This routine allocates and attaches a fake offset for @obj, in cases where
> + * the virtual size differs from the physical size (ie. obj->size).
> Otherwise
> + * just use drm_gem_create_mmap_offset().
> */
> int
> -drm_gem_create_mmap_offset(struct drm_gem_object *obj)
> +drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size)
> {
> struct drm_device *dev = obj->dev;
> struct drm_gem_mm *mm = dev->mm_private;
>
> return drm_vma_offset_add(&mm->vma_manager, &obj->vma_node,
> - obj->size / PAGE_SIZE);
> + size / PAGE_SIZE);
> +}
> +EXPORT_SYMBOL(drm_gem_create_mmap_offset_size);
> +
> +/**
> + * drm_gem_create_mmap_offset - create a fake mmap offset for an object
> + * @obj: obj in question
> + *
> + * GEM memory mapping works by handing back to userspace a fake mmap offset
> + * it can use in a subsequent mmap(2) call. The DRM core code then looks
> + * up the object based on the offset and sets up the various memory mapping
> + * structures.
> + *
> + * This routine allocates and attaches a fake offset for @obj.
> + */
> +int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
> +{
> + return drm_gem_create_mmap_offset_size(obj, obj->size);
> }
> EXPORT_SYMBOL(drm_gem_create_mmap_offset);
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 1cc765a..d00eb89 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1668,6 +1668,7 @@ drm_gem_object_handle_unreference_unlocked(struct
> drm_gem_object *obj)
>
> void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
> int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
> +int drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size);
>
> struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
> struct drm_file *filp,
> --
> 1.8.3.1
>
> ___
> 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 22/25] drm: no-op out GET_STATS ioctl
Daniel Vetter writes: > Again only used by a tests in libdrm and by dristat. Nowadays we have > much better tracing tools to get detailed insights into what a drm > driver is doing. And for a simple "does it work" kind of question that > these stats could answer we have plenty of dmesg debug log spew. > > So I don't see any use for this stat gathering complexity at all. > > To be able to gradually drop things start with ripping out the > interfaces to it, here the ioctl. > > To prevent dristat from eating its own stack garbage we can't use the > drm_noop ioctl though, since we need to clear the return data with a > memset. I'm happy to see these two die. Even back in the day we didn't use them. This has been quite a trip down memory lane. Patch 9 typo: s/functinal/functional/ Patch 25 typo: s/loose/lose/ Patches 2, 6-11, 19, 21, 22, 24, 25 are: Reviewed-by: Eric Anholt pgpIMBuKmgVkn.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.11-rc4] [HD2400] - radeon.dpm
On Thu, Aug 8, 2013 at 11:34 AM, miaou sami wrote: > Hi, > > thanks for the explanation. > Do you know if this is a hardware limitation, or if an updated version of > the driver will come some day? It's not a hardware limitation. The driver relies on what the OEM put in the power tables as that is what was validated with the OEM. You might check to see if your OEM offers an updated bios for your system. Alex > > Regards, > Sam > >> Date: Wed, 7 Aug 2013 18:06:05 -0400 >> Subject: Re: [3.11-rc4] [HD2400] - radeon.dpm >> From: alexdeuc...@gmail.com >> To: miaous...@hotmail.com >> CC: dri-devel@lists.freedesktop.org >> >> On Wed, Aug 7, 2013 at 5:53 PM, miaou sami wrote: >> > Hi, >> > >> > thanks for your reply. >> > Here is the dmesg. >> > >> > Let me know if you need further testing. >> >> As I suspected, on your system all the performance levels are the same: >> >> [ 8.961675] == power state 0 == >> [ 8.961677] ui class: none >> [ 8.961679] internal class: boot >> [ 8.961682] caps: video >> [ 8.961684] uvd vclk: 0 dclk: 0 >> [ 8.961686] power level 0 sclk: 45000 mclk: 5 vddc: 950 >> [ 8.961688] power level 1 sclk: 45000 mclk: 5 vddc: 950 >> [ 8.961690] power level 2 sclk: 45000 mclk: 5 vddc: 950 >> [ 8.961691] status: c r b >> [ 8.961695] == power state 1 == >> [ 8.961696] ui class: performance >> [ 8.961698] internal class: none >> [ 8.961700] caps: video >> [ 8.961703] uvd vclk: 0 dclk: 0 >> [ 8.961704] power level 0 sclk: 45000 mclk: 5 vddc: 950 >> [ 8.961706] power level 1 sclk: 45000 mclk: 5 vddc: 950 >> [ 8.961708] power level 2 sclk: 45000 mclk: 5 vddc: 950 >> [ 8.961709] status: >> >> So there is no dynamic switching supported on your system. >> >> Alex >> >> > >> > Regards >> > Sam >> > >> >> Date: Wed, 7 Aug 2013 09:13:20 -0400 >> >> Subject: Re: [3.11-rc4] [HD2400] - radeon.dpm >> >> From: alexdeuc...@gmail.com >> >> To: miaous...@hotmail.com >> >> CC: dri-devel@lists.freedesktop.org >> > >> >> >> >> On Tue, Aug 6, 2013 at 4:03 PM, * SAMÍ * wrote: >> >> > Hi, >> >> > >> >> > I was testing 3.11-rc4 with and without radeon.dpm=1 and I expected >> >> > some >> >> > results, either in performance or in power consumption, but I do not >> >> > notice >> >> > any change... >> >> > Should I worry? >> >> > Or do you want me to do any specific test? >> >> >> >> Please attach your dmesg output. Some early rv6xx cards had identical >> >> performance levels in all power states so they didn't actually support >> >> dynamic clock switching. >> >> >> >> Alex >> >> >> >> > >> >> > I have an ATI Mobility HD2400 (RV610). >> >> > >> >> > cat /sys/class/drm/card0/device/power_dpm_state >> >> > balanced >> >> > >> >> > dmesg: radeon: dpm initialized >> >> > >> >> > No specific error in dmesg... >> >> > >> >> > Regards >> >> > Sam >> >> > >> >> > ___ >> >> > 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: fix minor number range calculation
Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.
Signed-off-by: Kristian Høgsberg
(fixed up tabs and adjust commit-msg accordingly)
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index d663f7d..ca24ad0 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -113,12 +113,12 @@ static int drm_minor_get_id(struct drm_device *dev, int
type)
int base = 0, limit = 63;
if (type == DRM_MINOR_CONTROL) {
-base += 64;
-limit = base + 127;
-} else if (type == DRM_MINOR_RENDER) {
-base += 128;
-limit = base + 255;
-}
+ base += 64;
+ limit = base + 63;
+ } else if (type == DRM_MINOR_RENDER) {
+ base += 128;
+ limit = base + 63;
+ }
mutex_lock(&dev->struct_mutex);
ret = idr_alloc(&drm_minors_idr, NULL, base, limit, GFP_KERNEL);
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix minor number range calculation
Hi
On Thu, Aug 8, 2013 at 7:10 PM, David Herrmann wrote:
> Currently, both ranges overlap. Fix the limits so both ranges are mutually
> exclusive. Also use the occasion to convert whitespaces to tabs.
>
> Signed-off-by: Kristian Høgsberg
> (fixed up tabs and adjust commit-msg accordingly)
> Signed-off-by: David Herrmann
Umh, somehow this dropped the author line. It's supposed to be:
Author: Kristian Høgsberg
Regards
David
> ---
> drivers/gpu/drm/drm_stub.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index d663f7d..ca24ad0 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -113,12 +113,12 @@ static int drm_minor_get_id(struct drm_device *dev, int
> type)
> int base = 0, limit = 63;
>
> if (type == DRM_MINOR_CONTROL) {
> -base += 64;
> -limit = base + 127;
> -} else if (type == DRM_MINOR_RENDER) {
> -base += 128;
> -limit = base + 255;
> -}
> + base += 64;
> + limit = base + 63;
> + } else if (type == DRM_MINOR_RENDER) {
> + base += 128;
> + limit = base + 63;
> + }
>
> mutex_lock(&dev->struct_mutex);
> ret = idr_alloc(&drm_minors_idr, NULL, base, limit, GFP_KERNEL);
> --
> 1.8.3.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"
In next-20130808, building tegra_defconfig for ARM yields: > drivers/built-in.o: In function `drm_lastclose': > /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198: > undefined reference to `drm_agp_clear' That's because drm_agp_clear() is called unconditionally, yet is only conditionally built into drm_agpsupport.c (#if __OS_HAS_AGP). Should the call from drm_drv.c be conditional, or should there be a dummy static inline replacement in include/drm/drmP.h for when AGP support isn't available? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/agp: Fix build for non-AGP platforms
Hi
On Thu, Aug 8, 2013 at 12:20 PM, Mark Brown wrote:
> From: Mark Brown
>
> Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
> broke the build for platforms which do not have AGP since it moved the
> AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
> unconditionally in drm_drv.c. This causes build failures for embedded
> SoCs which use DRM but do not have AGP.
>
> Fix this by providing stub static inlines in the header.
>
> Signed-off-by: Mark Brown
A very similar patch which does it for all AGP functions is already
pending on dri-devel:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043077.html
Thanks
David
> ---
> include/drm/drmP.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index fba5473..e7f7da0 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1453,6 +1453,7 @@ extern int drm_modeset_ctl(struct drm_device *dev, void
> *data,
>struct drm_file *file_priv);
>
> /* AGP/GART support (drm_agpsupport.h) */
> +#if __OS_HAS_AGP
> extern struct drm_agp_head *drm_agp_init(struct drm_device *dev);
> extern void drm_agp_destroy(struct drm_agp_head *agp);
> extern void drm_agp_clear(struct drm_device *dev);
> @@ -1480,6 +1481,10 @@ extern int drm_agp_unbind_ioctl(struct drm_device
> *dev, void *data,
> extern int drm_agp_bind(struct drm_device *dev, struct drm_agp_binding
> *request);
> extern int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> +#else
> +static inline void drm_agp_destroy(struct drm_agp_head *agp) { }
> +static inline void drm_agp_clear(struct drm_device *dev) { }
> +#endif
>
> /* Stub support (drm_stub.h) */
> extern int drm_setmaster_ioctl(struct drm_device *dev, void *data,
> --
> 1.8.4.rc1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/agp linux-next build broken for non-AGP platform
Hi
On Thu, Aug 8, 2013 at 12:01 PM, Vincent Stehlé
wrote:
> Hi,
>
> Linux next-20130808 link breaks for me with ARM config multi_v7defconfig.
>
> It seems this is due to the following commit:
>
> 28ec711 drm/agp: move AGP cleanup paths to drm_agpsupport.c
>
> ...which calls drm_agp_clear() without "gating" it with __OS_HAS_AGP.
> As the code of drm_agpsupport.c is only "emited" when __OS_HAS_AGP,
> which is not the case for me, link breaks.
>
> As a "hint", see the patch below, which "repairs" the link for me. This is
> probably not functional; please DO NOT APPLY.
>
> Best regards,
>
> V.
>
Yepp, I missed that, sorry. There is already a patch pending on dri-devel:
http://lists.freedesktop.org/archives/dri-devel/2013-August/043077.html
Thanks
David
> ---
> drivers/gpu/drm/drm_drv.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 799..58f7f39 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -195,7 +195,9 @@ int drm_lastclose(struct drm_device * dev)
>
> mutex_lock(&dev->struct_mutex);
>
> +#if __OS_HAS_AGP
> drm_agp_clear(dev);
> +#endif
>
> if (drm_core_check_feature(dev, DRIVER_SG) && dev->sg &&
> !drm_core_check_feature(dev, DRIVER_MODESET)) {
> --
> 1.7.10.4
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"
Hi On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote: > In next-20130808, building tegra_defconfig for ARM yields: > >> drivers/built-in.o: In function `drm_lastclose': >> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198: >> undefined reference to `drm_agp_clear' > > That's because drm_agp_clear() is called unconditionally, yet is only > conditionally built into drm_agpsupport.c (#if __OS_HAS_AGP). > > Should the call from drm_drv.c be conditional, or should there be a > dummy static inline replacement in include/drm/drmP.h for when AGP > support isn't available? Sorry, I missed testing with AGP=n and the code I fixed depended on dead-code-elimination to link correctly. I overlooked that. There is a patch pending on dri-devel: http://lists.freedesktop.org/archives/dri-devel/2013-August/043077.html Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"
On 08/08/2013 12:13 PM, David Herrmann wrote: > Hi > > On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote: >> In next-20130808, building tegra_defconfig for ARM yields: >> >>> drivers/built-in.o: In function `drm_lastclose': >>> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198: >>> undefined reference to `drm_agp_clear' >> >> That's because drm_agp_clear() is called unconditionally, yet is only >> conditionally built into drm_agpsupport.c (#if __OS_HAS_AGP). >> >> Should the call from drm_drv.c be conditional, or should there be a >> dummy static inline replacement in include/drm/drmP.h for when AGP >> support isn't available? > > Sorry, I missed testing with AGP=n and the code I fixed depended on > dead-code-elimination to link correctly. I overlooked that. There is a > patch pending on dri-devel: > http://lists.freedesktop.org/archives/dri-devel/2013-August/043077.html That makes it worse! To solve it, you need: diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h index f926542..a184eee 100644 --- a/include/drm/drm_agpsupport.h +++ b/include/drm/drm_agpsupport.h @@ -8,7 +8,7 @@ #include #include -#ifdef __OS_HAS_AGP +#if __OS_HAS_AGP void drm_free_agp(DRM_AGP_MEM * handle, int pages); int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start); ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #85 from Sergey --- > Does disabling clockgating avoid the hangs? Caught hang after hibernate. -- 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 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #86 from Alex Deucher --- Ingoring suspend/hibernate, is anyone getting hangs or gpu resets with dpm enabled under normal operation? If so, can you try disabling clockgating as per comment 84? Lets address suspend/hibernate issues separately. -- 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 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #87 from Hrvoje Senjan --- (In reply to comment #86) > Ingoring suspend/hibernate, is anyone getting hangs or gpu resets with dpm > enabled under normal operation? If so, can you try disabling clockgating as > per comment 84? Lets address suspend/hibernate issues separately. Using it for some 6h, so far so good. Will be able to tell with more accuracy after a day or two without hangs. -- 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: Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"
Hi On Thu, Aug 8, 2013 at 9:21 PM, Stephen Warren wrote: > On 08/08/2013 12:13 PM, David Herrmann wrote: >> Hi >> >> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote: >>> In next-20130808, building tegra_defconfig for ARM yields: >>> >>>> drivers/built-in.o: In function `drm_lastclose': >>>> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198: >>>> undefined reference to `drm_agp_clear' >>> >>> That's because drm_agp_clear() is called unconditionally, yet is only >>> conditionally built into drm_agpsupport.c (#if __OS_HAS_AGP). >>> >>> Should the call from drm_drv.c be conditional, or should there be a >>> dummy static inline replacement in include/drm/drmP.h for when AGP >>> support isn't available? >> >> Sorry, I missed testing with AGP=n and the code I fixed depended on >> dead-code-elimination to link correctly. I overlooked that. There is a >> patch pending on dri-devel: >> http://lists.freedesktop.org/archives/dri-devel/2013-August/043077.html > > That makes it worse! To solve it, you need: Argh! I need some proper build environments to test all the non-x86 stuff. Thanks for the hint, I will resend the patch. Hopefully it'll work this time. Sorry for that.. Thanks David > diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h > index f926542..a184eee 100644 > --- a/include/drm/drm_agpsupport.h > +++ b/include/drm/drm_agpsupport.h > @@ -8,7 +8,7 @@ > #include > #include > > -#ifdef __OS_HAS_AGP > +#if __OS_HAS_AGP > > void drm_free_agp(DRM_AGP_MEM * handle, int pages); > int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: provide agp dummies for CONFIG_AGP=n
We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.
Fixes a build-regression introduced by:
commit 28ec711cd427f8b61f73712a43b8100ba8ca933b
Author: David Herrmann
Date: Sat Jul 27 16:37:00 2013 +0200
drm/agp: move AGP cleanup paths to drm_agpsupport.c
v2: switch #ifdef -> #if (spotted by Stephen)
Cc: Laurent Pinchart
Cc: Daniel Vetter
Cc: Stephen Warren
Signed-off-by: David Herrmann
---
include/drm/drmP.h | 49 +--
include/drm/drm_agpsupport.h | 194 +++
2 files changed, 196 insertions(+), 47 deletions(-)
create mode 100644 include/drm/drm_agpsupport.h
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fba5473..3ecdde6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -62,10 +62,8 @@
#endif
#include
#include
-#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
#include
#include
-#endif
#include
#include
#include
@@ -1226,16 +1224,6 @@ static inline int drm_dev_to_irq(struct drm_device *dev)
return dev->driver->bus->get_irq(dev);
}
-
-#if __OS_HAS_AGP
-static inline int drm_core_has_AGP(struct drm_device *dev)
-{
- return drm_core_check_feature(dev, DRIVER_USE_AGP);
-}
-#else
-#define drm_core_has_AGP(dev) (0)
-#endif
-
#if __OS_HAS_MTRR
static inline int drm_core_has_MTRR(struct drm_device *dev)
{
@@ -1292,14 +1280,6 @@ extern unsigned int drm_poll(struct file *filp, struct
poll_table_struct *wait);
/* Memory management support (drm_memory.h) */
#include
-extern void drm_free_agp(DRM_AGP_MEM * handle, int pages);
-extern int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start);
-extern DRM_AGP_MEM *drm_agp_bind_pages(struct drm_device *dev,
- struct page **pages,
- unsigned long num_pages,
- uint32_t gtt_offset,
- uint32_t type);
-extern int drm_unbind_agp(DRM_AGP_MEM * handle);
/* Misc. IOCTL support (drm_ioctl.h) */
extern int drm_irq_by_busid(struct drm_device *dev, void *data,
@@ -1453,33 +1433,8 @@ extern int drm_modeset_ctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
/* AGP/GART support (drm_agpsupport.h) */
-extern struct drm_agp_head *drm_agp_init(struct drm_device *dev);
-extern void drm_agp_destroy(struct drm_agp_head *agp);
-extern void drm_agp_clear(struct drm_device *dev);
-extern int drm_agp_acquire(struct drm_device *dev);
-extern int drm_agp_acquire_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern int drm_agp_release(struct drm_device *dev);
-extern int drm_agp_release_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern int drm_agp_enable(struct drm_device *dev, struct drm_agp_mode mode);
-extern int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int drm_agp_info(struct drm_device *dev, struct drm_agp_info *info);
-extern int drm_agp_info_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int drm_agp_alloc(struct drm_device *dev, struct drm_agp_buffer
*request);
-extern int drm_agp_alloc_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern int drm_agp_free(struct drm_device *dev, struct drm_agp_buffer
*request);
-extern int drm_agp_free_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int drm_agp_unbind(struct drm_device *dev, struct drm_agp_binding
*request);
-extern int drm_agp_unbind_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int drm_agp_bind(struct drm_device *dev, struct drm_agp_binding
*request);
-extern int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
+
+#include
/* Stub support (drm_stub.h) */
extern int drm_setmaster_ioctl(struct drm_device *dev, void *data,
diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
new file mode 100644
index 000..a184eee
--- /dev/null
+++ b/include/drm/drm_agpsupport.h
@@ -0,0 +1,194 @@
+#ifndef _DRM_AGPSUPPORT_H_
+#define _DRM_AGPSUPPORT_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#if __OS_HAS_AGP
+
+void drm_free_agp(DRM_AGP_MEM * handle, int pages);
+int drm_bind_agp(DRM_AGP_MEM * handle, unsigned int start);
+int drm_unbind_agp(DRM_AGP_MEM * handle);
+DRM_AGP_MEM *drm_agp_bind_pages(struct d
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #88 from Francisco Pina Martins --- I've been using DPM in my rv635 for a few days now (intensive use, as this is my main machine) and had no issues yet. I can however, still tempt fate and try some nasty things such as quick zoom in/out cycles in big .svg files in inkscape, and see if that causes issues. I know it used to a long time ago. -- 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: Can I put a V4L2 soc camera driver under other subsystem directory?
Hi Bryan, On Wed, 7 Aug 2013, Bryan Wu wrote: > Hi Guennadi and LMML, > > I'm working on a camera controller driver for Tegra, which is using > soc_camera. But we also need to use Tegra specific host1x interface > like syncpt APIs. > > Since host1x is quite Tegra specific framework which is in > drivers/gpu/host1x and has several host1x's client driver like graphic > 2D driver, my v4l2 soc_camera driver is also a host1x client driver. > Right now host1x does not expose any global include header files like > API in the kernel, because no other users. So we plan to put all > host1x related driver together, is that OK for us to put our Tegra > soc_camera driver into drivers/gpu/host1x/camera or similar? > > I guess besides it will introduce some extra maintenance it should be OK, > right? Exactly, there's already been a precedent: http://www.mail-archive.com/linux-media@vger.kernel.org/msg56213.html It hasn't been finalised yet though. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Add drm_bridge
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, dpms, and optionally connection detection.
Since a connector may not be able to determine the connection state
downstream of the bridge, bridges may implement detect() which will take
precedence over connector detect() if the bridge is already attached
to an encoder and that encoder is already attached to the connector.
In practical terms, this requires the drm driver to make these
associations at init time, which is fine for SoC applications where
this link is static.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_crtc.c| 50 +
drivers/gpu/drm/drm_crtc_helper.c | 112 ++
drivers/gpu/drm/drm_sysfs.c | 8 ++-
include/drm/drm_crtc.h| 48
include/drm/drm_crtc_helper.h | 34
5 files changed, 241 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..0311e2b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_connector_unplug_all);
+int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
+ const struct drm_bridge_funcs *funcs)
+{
+ int ret;
+
+ drm_modeset_lock_all(dev);
+
+ ret = drm_mode_object_get(dev, &bridge->base, DRM_MODE_OBJECT_BRIDGE);
+ if (ret)
+ goto out;
+
+ bridge->dev = dev;
+ bridge->funcs = funcs;
+
+ list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
+ dev->mode_config.num_bridge++;
+
+ out:
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_bridge_init);
+
+void drm_bridge_cleanup(struct drm_bridge *bridge)
+{
+ struct drm_device *dev = bridge->dev;
+
+ drm_modeset_lock_all(dev);
+ drm_mode_object_put(dev, &bridge->base);
+ list_del(&bridge->head);
+ dev->mode_config.num_bridge--;
+ drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_bridge_cleanup);
+
int drm_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
const struct drm_encoder_funcs *funcs,
@@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev,
struct drm_mode_group *gr
total_objects += dev->mode_config.num_crtc;
total_objects += dev->mode_config.num_connector;
total_objects += dev->mode_config.num_encoder;
+ total_objects += dev->mode_config.num_bridge;
group->id_list = kzalloc(total_objects * sizeof(uint32_t), GFP_KERNEL);
if (!group->id_list)
@@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev,
struct drm_mode_group *gr
group->num_crtcs = 0;
group->num_connectors = 0;
group->num_encoders = 0;
+ group->num_bridges = 0;
return 0;
}
@@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device
*dev,
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connector *connector;
+ struct drm_bridge *bridge;
int ret;
if ((ret = drm_mode_group_init(dev, group)))
@@ -1223,6 +1261,11 @@ int drm_mode_group_init_legacy_group(struct drm_device
*dev,
group->id_list[group->num_crtcs + group->num_encoders +
group->num_connectors++] = connector->base.id;
+ list_for_each_entry(bridge, &dev->mode_config.bridge_list, head)
+ group->id_list[group->num_crtcs + group->num_encoders +
+ group->num_connectors + group->num_bridges++] =
+ bridge->base.id;
+
return 0;
}
EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
@@ -3905,6 +3948,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.fb_list);
INIT_LIST_HEAD(&dev->mode_config.crtc_list);
INIT_LIST_HEAD(&dev->mode_config.connector_list);
+ INIT_LIST_HEAD(&dev->mode_config.bridge_list);
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
@@ -3941,6 +3985,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_connector *connector, *ot;
struct drm_crtc *crtc, *ct;
struct drm_encoder *encoder, *enct;
+ struct drm_bridge *bridge, *brt;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
struct drm_property_blob *blob, *bt;
@@ -3951,6 +3996,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
Re: [PATCH v2] drm: provide agp dummies for CONFIG_AGP=n
On 08/08/2013 02:19 PM, David Herrmann wrote: > We currently rely on gcc dead-code elimination so the drm_agp_* helpers > are not called if drm_core_has_AGP() is false. That's ugly as hell so > provide "static inline" dummies for the case that AGP is disabled. > > Fixes a build-regression introduced by: > > commit 28ec711cd427f8b61f73712a43b8100ba8ca933b > Author: David Herrmann > Date: Sat Jul 27 16:37:00 2013 +0200 > > drm/agp: move AGP cleanup paths to drm_agpsupport.c Tested-by: Stephen Warren ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #89 from Alex Deucher --- (In reply to comment #88) > I've been using DPM in my rv635 for a few days now (intensive use, as this > is my main machine) and had no issues yet. > I can however, still tempt fate and try some nasty things such as quick zoom > in/out cycles in big .svg files in inkscape, and see if that causes issues. > I know it used to a long time ago. If you do run into a problem make sure it's specific to dpm. If you had a particular problem in the past and you get it again, it's probably not dpm related. -- 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] drm: drm_drv: Only call drm_agp_clear() in __OS_HAS_AGP case
From: Fabio Estevam
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) causes the
following link error on ARM (imx_v6_v7_defconfig):
drivers/built-in.o: In function `drm_lastclose':
:(.text+0x588a0): undefined reference to `drm_agp_clear'
make: *** [vmlinux] Error 1
drm_agp_clear() is defined only '#if __OS_HAS_AGP' is true, so add this 'if'
logic when calling it.
Signed-off-by: Fabio Estevam
---
drivers/gpu/drm/drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 799..58f7f39 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -195,7 +195,9 @@ int drm_lastclose(struct drm_device * dev)
mutex_lock(&dev->struct_mutex);
+#if __OS_HAS_AGP
drm_agp_clear(dev);
+#endif
if (drm_core_check_feature(dev, DRIVER_SG) && dev->sg &&
!drm_core_check_feature(dev, DRIVER_MODESET)) {
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Several NXP TDA998x patches
Sebastian Hesselbarth wrote on Tue [2013-Aug-06 00:20:10 +0200]: > This patch set picks up several patches sent during the past months > related with NXP TDA998x HDMI transmitter driver. The patches have > been tested on Marvell Dove (Armada DRM) on several HDMI modes with > audio playing on S/PDIF. I have also quickly tested on Beaglebone > Black (tilcdc) for one DVI mode. > > As I squashed some patches and fixed some audio issues, it would > be great to have a formal Tested-by or Acked-by from Russell and > Darren for the whole patch set. > Sebastian, Looks good to me, I tried this series with all the known "problem" modes on the BeagleBone Black and they are working correctly now. I should just state for the record that I have so far tested DVI mode (no audio) and only boot time mode setting but this is all we have been using from the original mainline NXP/tilcdc drm drivers anyway. So for the series: Tested-by: Darren Etheridge Darren ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU
https://bugs.freedesktop.org/show_bug.cgi?id=67187 --- Comment #13 from Bastian Triller --- Resume from suspend only works when I have the power plug attached. It doesn't matter, if I suspended on AC or not as long I have attached it on resume. -- 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 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU
https://bugs.freedesktop.org/show_bug.cgi?id=67187 --- Comment #14 from Bastian Triller --- Created attachment 83867 --> https://bugs.freedesktop.org/attachment.cgi?id=83867&action=edit dmesg there was an error on the first suspend: ... [drm:rv770_stop_dpm] *ERROR* Could not force DPM to low. -- 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 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU
https://bugs.freedesktop.org/show_bug.cgi?id=67187 --- Comment #15 from Alex Deucher --- (In reply to comment #13) > Resume from suspend only works when I have the power plug attached. It > doesn't matter, if I suspended on AC or not as long I have attached it on > resume. Does resume work with dpm disabled? This bug is specifically about UVD. If there is an issue with dpm and resume, it should be filed separately. -- 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 67927] New: R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered
https://bugs.freedesktop.org/show_bug.cgi?id=67927 Priority: medium Bug ID: 67927 Assignee: dri-devel@lists.freedesktop.org Summary: R600_DEBUG=sb: Celestia show 2 earths, one wrongly rendered Severity: major Classification: Unclassified OS: Linux (All) Reporter: die...@nuetzel-hh.de Hardware: x86 (IA32) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 83869 --> https://bugs.freedesktop.org/attachment.cgi?id=83869&action=edit r600-sb-Celestia-2-earths.png Start Celestia, wait for earth. Try 'Demo' (d) - or move, scale (zoom) around - nice effects. -Dieter -- 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: Add drm_bridge
On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it will participate in mode
> set, dpms, and optionally connection detection.
>
> Since a connector may not be able to determine the connection state
> downstream of the bridge, bridges may implement detect() which will take
> precedence over connector detect() if the bridge is already attached
> to an encoder and that encoder is already attached to the connector.
> In practical terms, this requires the drm driver to make these
> associations at init time, which is fine for SoC applications where
> this link is static.
>
> Signed-off-by: Sean Paul
A few comments below. I think overall any such infrastructure simply
needs to demonstrate viability on a few drivers, that makes it much
simpler to check whether the interfaces make sense. Generally I'd make
more sense for me if the bridge is just an implementation detail of a
given encoder and if the bridge would not be exposed to the crtc
helpers. With that abstraction chaining would be more natural imo and
we'd also have a much higher chance that bridge drivers work accross
different drm drivers: Atm you can run some encoder stuff in the crtc
callbacks and the other way round (and pretty much every driver for a
bit more complicated hw does that), and every driver can differ in
those tricks a bit. If we bake the bridge callbacks into the crtc
helpers I expect that for bridges with tricky ordering constraints
this will become a giant mess. So I'd prefer much if this would work
like drm i2c slave encoders.
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_crtc.c| 50 +
> drivers/gpu/drm/drm_crtc_helper.c | 112
> ++
> drivers/gpu/drm/drm_sysfs.c | 8 ++-
> include/drm/drm_crtc.h| 48
> include/drm/drm_crtc_helper.h | 34
> 5 files changed, 241 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fc83bb9..0311e2b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_connector_unplug_all);
>
> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
> + const struct drm_bridge_funcs *funcs)
> +{
> + int ret;
> +
> + drm_modeset_lock_all(dev);
> +
> + ret = drm_mode_object_get(dev, &bridge->base, DRM_MODE_OBJECT_BRIDGE);
> + if (ret)
> + goto out;
> +
> + bridge->dev = dev;
> + bridge->funcs = funcs;
> +
> + list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
> + dev->mode_config.num_bridge++;
> +
> + out:
> + drm_modeset_unlock_all(dev);
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_bridge_init);
> +
> +void drm_bridge_cleanup(struct drm_bridge *bridge)
> +{
> + struct drm_device *dev = bridge->dev;
> +
> + drm_modeset_lock_all(dev);
> + drm_mode_object_put(dev, &bridge->base);
> + list_del(&bridge->head);
> + dev->mode_config.num_bridge--;
> + drm_modeset_unlock_all(dev);
> +}
> +EXPORT_SYMBOL(drm_bridge_cleanup);
> +
> int drm_encoder_init(struct drm_device *dev,
> struct drm_encoder *encoder,
> const struct drm_encoder_funcs *funcs,
> @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev,
> struct drm_mode_group *gr
> total_objects += dev->mode_config.num_crtc;
> total_objects += dev->mode_config.num_connector;
> total_objects += dev->mode_config.num_encoder;
> + total_objects += dev->mode_config.num_bridge;
>
> group->id_list = kzalloc(total_objects * sizeof(uint32_t),
> GFP_KERNEL);
> if (!group->id_list)
> @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev,
> struct drm_mode_group *gr
> group->num_crtcs = 0;
> group->num_connectors = 0;
> group->num_encoders = 0;
> + group->num_bridges = 0;
> return 0;
> }
>
> @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device
> *dev,
> struct drm_crtc *crtc;
> struct drm_encoder *encoder;
> struct drm_connector *connector;
> + struct drm_bridge *bridge;
> int ret;
>
> if ((ret = drm_mode_group_init(dev, group)))
> @@ -1223,6 +1261,11 @@ int drm_mode_group_init_legacy_group(struct drm_device
> *dev,
> group->id_list[group->num_crtcs + group->num_encoders +
>group->num_connectors++] = connector->base.id;
>
> + list_for_each_entry(bridge, &dev->mode_config.bridge_list, head)
> + group-
Re: [PATCH] drm: Add drm_bridge
On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and bridge. Once a
>> bridge is associated with an encoder, it will participate in mode
>> set, dpms, and optionally connection detection.
>>
>> Since a connector may not be able to determine the connection state
>> downstream of the bridge, bridges may implement detect() which will take
>> precedence over connector detect() if the bridge is already attached
>> to an encoder and that encoder is already attached to the connector.
>> In practical terms, this requires the drm driver to make these
>> associations at init time, which is fine for SoC applications where
>> this link is static.
>>
>> Signed-off-by: Sean Paul
>
> A few comments below. I think overall any such infrastructure simply
> needs to demonstrate viability on a few drivers, that makes it much
> simpler to check whether the interfaces make sense.
Just a quick note.. I have a branch of msm where I've been using a
slightly earlier version of this (and in next day or so will be
rebased on this version).
and I guess Sean is using this on a driver or two. So that's at least
two drivers ;-)
BR,
-R
> Generally I'd make
> more sense for me if the bridge is just an implementation detail of a
> given encoder and if the bridge would not be exposed to the crtc
> helpers. With that abstraction chaining would be more natural imo and
> we'd also have a much higher chance that bridge drivers work accross
> different drm drivers: Atm you can run some encoder stuff in the crtc
> callbacks and the other way round (and pretty much every driver for a
> bit more complicated hw does that), and every driver can differ in
> those tricks a bit. If we bake the bridge callbacks into the crtc
> helpers I expect that for bridges with tricky ordering constraints
> this will become a giant mess. So I'd prefer much if this would work
> like drm i2c slave encoders.
>
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/drm_crtc.c| 50 +
>> drivers/gpu/drm/drm_crtc_helper.c | 112
>> ++
>> drivers/gpu/drm/drm_sysfs.c | 8 ++-
>> include/drm/drm_crtc.h| 48
>> include/drm/drm_crtc_helper.h | 34
>> 5 files changed, 241 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index fc83bb9..0311e2b 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>> }
>> EXPORT_SYMBOL(drm_connector_unplug_all);
>>
>> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> + const struct drm_bridge_funcs *funcs)
>> +{
>> + int ret;
>> +
>> + drm_modeset_lock_all(dev);
>> +
>> + ret = drm_mode_object_get(dev, &bridge->base,
>> DRM_MODE_OBJECT_BRIDGE);
>> + if (ret)
>> + goto out;
>> +
>> + bridge->dev = dev;
>> + bridge->funcs = funcs;
>> +
>> + list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
>> + dev->mode_config.num_bridge++;
>> +
>> + out:
>> + drm_modeset_unlock_all(dev);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_init);
>> +
>> +void drm_bridge_cleanup(struct drm_bridge *bridge)
>> +{
>> + struct drm_device *dev = bridge->dev;
>> +
>> + drm_modeset_lock_all(dev);
>> + drm_mode_object_put(dev, &bridge->base);
>> + list_del(&bridge->head);
>> + dev->mode_config.num_bridge--;
>> + drm_modeset_unlock_all(dev);
>> +}
>> +EXPORT_SYMBOL(drm_bridge_cleanup);
>> +
>> int drm_encoder_init(struct drm_device *dev,
>> struct drm_encoder *encoder,
>> const struct drm_encoder_funcs *funcs,
>> @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev,
>> struct drm_mode_group *gr
>> total_objects += dev->mode_config.num_crtc;
>> total_objects += dev->mode_config.num_connector;
>> total_objects += dev->mode_config.num_encoder;
>> + total_objects += dev->mode_config.num_bridge;
>>
>> group->id_list = kzalloc(total_objects * sizeof(uint32_t),
>> GFP_KERNEL);
>> if (!group->id_list)
>> @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev,
>> struct drm_mode_group *gr
>> group->num_crtcs = 0;
>> group->num_connectors = 0;
>> group->num_encoders = 0;
>> + group->num_bridges = 0;
>> return 0;
>> }
>>
>> @@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device
>> *dev,
>> struct drm_crtc *crtc;
>> struct drm_encoder *encoder;
>> struct drm_connector *connector;
>> + st
Re: [PATCH] drm: Add drm_bridge
On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and bridge. Once a
>> bridge is associated with an encoder, it will participate in mode
>> set, dpms, and optionally connection detection.
>>
>> Since a connector may not be able to determine the connection state
>> downstream of the bridge, bridges may implement detect() which will take
>> precedence over connector detect() if the bridge is already attached
>> to an encoder and that encoder is already attached to the connector.
>> In practical terms, this requires the drm driver to make these
>> associations at init time, which is fine for SoC applications where
>> this link is static.
>>
>> Signed-off-by: Sean Paul
>
> A few comments below. I think overall any such infrastructure simply
> needs to demonstrate viability on a few drivers, that makes it much
> simpler to check whether the interfaces make sense.
We have two bridges using it here, and we're working on adding a
third. Rob want to add one too.
> Generally I'd make
> more sense for me if the bridge is just an implementation detail of a
> given encoder and if the bridge would not be exposed to the crtc
> helpers. With that abstraction chaining would be more natural imo and
> we'd also have a much higher chance that bridge drivers work accross
> different drm drivers: Atm you can run some encoder stuff in the crtc
> callbacks and the other way round (and pretty much every driver for a
> bit more complicated hw does that), and every driver can differ in
> those tricks a bit. If we bake the bridge callbacks into the crtc
> helpers I expect that for bridges with tricky ordering constraints
> this will become a giant mess. So I'd prefer much if this would work
> like drm i2c slave encoders.
Interestingly, this is how we started. We first put these bridges
drivers in the i2c/ dir and called them directly from exynos. Then
things grew, and became very invasive in the host driver. So we added
a new interface which allowed us to implement this properly in all
drivers in a way which also extends to more drivers.
Stéphane
>
> Cheers, Daniel
>
>> ---
>> drivers/gpu/drm/drm_crtc.c| 50 +
>> drivers/gpu/drm/drm_crtc_helper.c | 112
>> ++
>> drivers/gpu/drm/drm_sysfs.c | 8 ++-
>> include/drm/drm_crtc.h| 48
>> include/drm/drm_crtc_helper.h | 34
>> 5 files changed, 241 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index fc83bb9..0311e2b 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
>> }
>> EXPORT_SYMBOL(drm_connector_unplug_all);
>>
>> +int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
>> + const struct drm_bridge_funcs *funcs)
>> +{
>> + int ret;
>> +
>> + drm_modeset_lock_all(dev);
>> +
>> + ret = drm_mode_object_get(dev, &bridge->base,
>> DRM_MODE_OBJECT_BRIDGE);
>> + if (ret)
>> + goto out;
>> +
>> + bridge->dev = dev;
>> + bridge->funcs = funcs;
>> +
>> + list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
>> + dev->mode_config.num_bridge++;
>> +
>> + out:
>> + drm_modeset_unlock_all(dev);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(drm_bridge_init);
>> +
>> +void drm_bridge_cleanup(struct drm_bridge *bridge)
>> +{
>> + struct drm_device *dev = bridge->dev;
>> +
>> + drm_modeset_lock_all(dev);
>> + drm_mode_object_put(dev, &bridge->base);
>> + list_del(&bridge->head);
>> + dev->mode_config.num_bridge--;
>> + drm_modeset_unlock_all(dev);
>> +}
>> +EXPORT_SYMBOL(drm_bridge_cleanup);
>> +
>> int drm_encoder_init(struct drm_device *dev,
>> struct drm_encoder *encoder,
>> const struct drm_encoder_funcs *funcs,
>> @@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev,
>> struct drm_mode_group *gr
>> total_objects += dev->mode_config.num_crtc;
>> total_objects += dev->mode_config.num_connector;
>> total_objects += dev->mode_config.num_encoder;
>> + total_objects += dev->mode_config.num_bridge;
>>
>> group->id_list = kzalloc(total_objects * sizeof(uint32_t),
>> GFP_KERNEL);
>> if (!group->id_list)
>> @@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev,
>> struct drm_mode_group *gr
>> group->num_crtcs = 0;
>> group->num_connectors = 0;
>> group->num_encoders = 0;
>> + group->num_bridges = 0;
>> return 0;
>> }
>>
>> @@ -1207,6 +1244,7 @@ int drm_mode_grou
[Bug 60709] With 3.10.3 / 3.10.5 screen output is "green" - looks like a green overlay
https://bugzilla.kernel.org/show_bug.cgi?id=60709 --- Comment #17 from Torsten Krah --- Done with bisect - did take some time but got it: d3418eacad403033e95e49dc14afa37c2112c134 is the first bad commit commit d3418eacad403033e95e49dc14afa37c2112c134 Author: Rafał Miłecki Date: Thu Apr 18 09:23:12 2013 -0400 drm/radeon/evergreen: setup HDMI before enabling it Closed source driver fglrx seems to enable infoframes and audio packets at the end, which makes sense, do the same. Signed-off-by: Rafał Miłecki Signed-off-by: Alex Deucher :04 04 67e10b90afeefe688d0c291e603c80dd7a9e810a 1105ef4336989eee87c971b035fedcc092c42417 Mdrivers -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/agp: Fix build for non-AGP platforms
From: Mark Brown
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
broke the build for platforms which do not have AGP since it moved the
AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
unconditionally in drm_drv.c. This causes build failures for embedded
SoCs which use DRM but do not have AGP.
Fix this by providing stub static inlines in the header.
Signed-off-by: Mark Brown
---
include/drm/drmP.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fba5473..e7f7da0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1453,6 +1453,7 @@ extern int drm_modeset_ctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
/* AGP/GART support (drm_agpsupport.h) */
+#if __OS_HAS_AGP
extern struct drm_agp_head *drm_agp_init(struct drm_device *dev);
extern void drm_agp_destroy(struct drm_agp_head *agp);
extern void drm_agp_clear(struct drm_device *dev);
@@ -1480,6 +1481,10 @@ extern int drm_agp_unbind_ioctl(struct drm_device *dev,
void *data,
extern int drm_agp_bind(struct drm_device *dev, struct drm_agp_binding
*request);
extern int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+#else
+static inline void drm_agp_destroy(struct drm_agp_head *agp) { }
+static inline void drm_agp_clear(struct drm_device *dev) { }
+#endif
/* Stub support (drm_stub.h) */
extern int drm_setmaster_ioctl(struct drm_device *dev, void *data,
--
1.8.4.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [3.11-rc4] [HD2400] - radeon.dpm
Hi, thanks for the explanation. Do you know if this is a hardware limitation, or if an updated version of the driver will come some day? Regards, Sam > Date: Wed, 7 Aug 2013 18:06:05 -0400 > Subject: Re: [3.11-rc4] [HD2400] - radeon.dpm > From: alexdeuc...@gmail.com > To: miaous...@hotmail.com > CC: dri-devel@lists.freedesktop.org > > On Wed, Aug 7, 2013 at 5:53 PM, miaou sami wrote: > > Hi, > > > > thanks for your reply. > > Here is the dmesg. > > > > Let me know if you need further testing. > > As I suspected, on your system all the performance levels are the same: > > [8.961675] == power state 0 == > [8.961677]ui class: none > [8.961679]internal class: boot > [8.961682]caps: video > [8.961684]uvdvclk: 0 dclk: 0 > [8.961686]power level 0sclk: 45000 mclk: 5 vddc: > 950 > [8.961688]power level 1sclk: 45000 mclk: 5 vddc: > 950 > [8.961690]power level 2sclk: 45000 mclk: 5 vddc: > 950 > [8.961691]status: c r b > [8.961695] == power state 1 == > [8.961696]ui class: performance > [8.961698]internal class: none > [8.961700]caps: video > [8.961703]uvdvclk: 0 dclk: 0 > [8.961704]power level 0sclk: 45000 mclk: 5 vddc: > 950 > [8.961706]power level 1sclk: 45000 mclk: 5 vddc: > 950 > [8.961708]power level 2sclk: 45000 mclk: 5 vddc: > 950 > [8.961709]status: > > So there is no dynamic switching supported on your system. > > Alex > > > > > Regards > > Sam > > > >> Date: Wed, 7 Aug 2013 09:13:20 -0400 > >> Subject: Re: [3.11-rc4] [HD2400] - radeon.dpm > >> From: alexdeuc...@gmail.com > >> To: miaous...@hotmail.com > >> CC: dri-devel@lists.freedesktop.org > > > >> > >> On Tue, Aug 6, 2013 at 4:03 PM, * SAMÍ * wrote: > >> > Hi, > >> > > >> > I was testing 3.11-rc4 with and without radeon.dpm=1 and I expected some > >> > results, either in performance or in power consumption, but I do not > >> > notice > >> > any change... > >> > Should I worry? > >> > Or do you want me to do any specific test? > >> > >> Please attach your dmesg output. Some early rv6xx cards had identical > >> performance levels in all power states so they didn't actually support > >> dynamic clock switching. > >> > >> Alex > >> > >> > > >> > I have an ATI Mobility HD2400 (RV610). > >> > > >> > cat /sys/class/drm/card0/device/power_dpm_state > >> > balanced > >> > > >> > dmesg: radeon: dpm initialized > >> > > >> > No specific error in dmesg... > >> > > >> > Regards > >> > Sam > >> > > >> > ___ > >> > 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: Can I put a V4L2 soc camera driver under other subsystem directory?
On Thu, Aug 8, 2013 at 1:52 PM, Guennadi Liakhovetski wrote: > Hi Bryan, > > On Wed, 7 Aug 2013, Bryan Wu wrote: > >> Hi Guennadi and LMML, >> >> I'm working on a camera controller driver for Tegra, which is using >> soc_camera. But we also need to use Tegra specific host1x interface >> like syncpt APIs. >> >> Since host1x is quite Tegra specific framework which is in >> drivers/gpu/host1x and has several host1x's client driver like graphic >> 2D driver, my v4l2 soc_camera driver is also a host1x client driver. >> Right now host1x does not expose any global include header files like >> API in the kernel, because no other users. So we plan to put all >> host1x related driver together, is that OK for us to put our Tegra >> soc_camera driver into drivers/gpu/host1x/camera or similar? >> >> I guess besides it will introduce some extra maintenance it should be OK, >> right? > > Exactly, there's already been a precedent: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg56213.html > > It hasn't been finalised yet though. > OK, cool. I will try to provide the first version soon. Thanks a lot, -Bryan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66738] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)
https://bugs.freedesktop.org/show_bug.cgi?id=66738 --- Comment #12 from lh --- (In reply to comment #11) > Are you running the same userspace stack with both kernel 3.9 and kernel > 3.10/3.11? If so, it sounds like this is UVD related. Yes, I have two kernels: arch official kernel 3.9.9 and kernel 3.11-rc4(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git) which compiled myself. 3.9.9 was quiet stable here. -- 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: use common drm_gem_dmabuf_release in i915/exynos drivers
On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote: > 2013/8/7 Daniel Vetter > > > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote: > > > > > > > > > 2013/8/7 Daniel Vetter > > >> > > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote: > > >> > On 08/07/2013 06:55 PM, Daniel Vetter wrote: > > >> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae > > wrote: > > >> > >>>-Original Message- > > >> > >>>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] > > >> > >>>Sent: Wednesday, August 07, 2013 6:15 PM > > >> > >>>To: DRI Development > > >> > >>>Cc: Intel Graphics Development; Daniel Vetter; Inki Dae > > >> > >>>Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in > > >> > >>> i915/exynos > > >> > >>>drivers > > >> > >>> > > >> > >>>Note that this is slightly tricky since both drivers store their > > >> > >>>native objects in dma_buf->priv. But both also embed the base > > >> > >>>drm_gem_object at the first position, so the implicit cast is ok. > > >> > >>> > > >> > >>>To use the release helper we need to export it, too. > > >> > >>Yeah, may I repost this patch with additional work? We also need to > > >> > >> export > > >> > >>with a gem object instead of specific one like you did. > > >> > > > >> > I think dmabuf stuff of exynos can be replaced to common > > drm_gem_dmabuf. > > >> > Already dmabuf stuff of drm_gem_cma_helper.c was substituted to common > > >> > drm_gem_dmabuf with low-level hook functions to use prime helpers. > > >> > > >> Ah, but that can easily be done on top of this, right? > > > > > > > > > Daniel, could you remove exynos related codes from your patch set? Your > > > patch set would make exynos broken because you didn't consider exporting > > > with a gem object for exynos like [PATCH 3/3] drm/i915: explicit store > > base > > > gem object in dma_buf->priv. So I think your patch set is not complete > > set, > > > and That is why exynos needs the additional work I mentioned above. So I > > > just wanted to repost your patch set + new one. > > > > Nope, my patch should not break exynos since the base gem_object is > > the first member of the exynos object, so we don't have any issues > > > > Ah, right. However, it does not seem like good way. > > > > with upcasting in exynos dma-buf code. The same applies to i915 > > dma-buf code, my follow-up patch just makes the code a bit safer. > > > > > > > > > > > > > > However, I think not only exynos could go to common drm_gem_dmabuf > > directly > > > but also it would make your patch set to be complete set if you remove > > > exynos related codes from your patch set. Otherwise, we have to work > > twice. > > > one is the additional work for resolving exynos broken issue by your > > patch > > > set, and other is to replace existing dmabuf stuff of exynos to common > > > drm_gem_dmabuf. > > > > Yeah np, I'll drop exynos then. > > > > Thanks a lot. :) Ah, I remember again why I want to also convert over exynos to the common dma buf release function: Later patches in my prime locking series will change things in there to avoid a userspace-triggerable oops. If we leave out exynos it'll break rather badly for dma-buf export. I need to think a bit more about what stuff looks like atm, but if I resend those parts I'll include exynos. It's a bit tricky that it still works, but that way you can fix it up without the introduction of a bisect failure point. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #81 from Hrvoje Senjan --- Similar as Sergey. It's pretty stable now, and boots correctly 100%, but sometimes it can hang during usage. Found the following in the log: Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: GPU lockup CP stall for more than 1msec Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: GPU lockup (waiting for 0x0015f962 last fence id 0x0015f960) Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: Saved 601 dwords of commands on ring 0. Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: GPU softreset: 0x0008 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008010_GRBM_STATUS = 0xA0003030 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008014_GRBM_STATUS2 = 0x0003 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_000E50_SRBM_STATUS = 0x200010C0 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x0002 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008680_CP_STAT = 0x8645 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x4001 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: SRBM_SOFT_RESET=0x0100 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008010_GRBM_STATUS = 0xA0003030 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008014_GRBM_STATUS2 = 0x0003 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_000E50_SRBM_STATUS = 0x200080C0 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_008680_CP_STAT = 0x8010 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: GPU reset succeeded, trying to resume Aug 07 23:35:49 shumarija kernel: [drm] PCIE GART of 512M enabled (table at 0x0004). Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: WB enabled Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x8801359cac00 Aug 07 23:35:49 shumarija kernel: radeon :01:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x8801359cac0c Aug 07 23:35:49 shumarija kernel: [drm] ring test on 0 succeeded in 1 usecs Aug 07 23:35:49 shumarija kernel: [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) Aug 07 23:35:49 shumarija kernel: [drm:r600_resume] *ERROR* r600 startup failed on resume -- 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/20130808/091381d5/attachment.html>
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #82 from Alex Deucher --- (In reply to comment #81) > Similar as Sergey. It's pretty stable now, and boots correctly 100%, but > sometimes it can hang during usage. Found the following in the log: Do you also get GPU hangs with dpm disabled? -- 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/20130808/7fe95399/attachment.html>
[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #83 from Hrvoje Senjan --- (In reply to comment #82) > (In reply to comment #81) > > Similar as Sergey. It's pretty stable now, and boots correctly 100%, but > > sometimes it can hang during usage. Found the following in the log: > > Do you also get GPU hangs with dpm disabled? Nope. I was running with the old dynpm method for a day, did not get a hang. With dpm i had it once or twice already today. -- 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/20130808/0c7dd62c/attachment.html>
[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC
Hi Dave,
I've got a couple of arch/arm/ patches that depend on this series and that I
would like to get merged in v3.12. They should go upstream through the arm-soc
tree. Would you be able to provide a stable branch with this patch set based
on one of the 3.11-rcX tags ? Ideally that branch should have as little
patches as possible other than this set.
On Wednesday 07 August 2013 13:23:08 Laurent Pinchart wrote:
> Hi Dave,
>
> The following changes since commit 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a:
>
> Merge tag 'drm-intel-next-2013-07-26-fixed' of
> git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-08-07
> 18:11:35 +1000)
>
> are available in the git repository at:
>
> git://linuxtv.org/pinchartl/fbdev.git drm/next/du
>
> for you to fetch changes up to 59e8f92fca87577b0f43516503f2abde9790a3a6:
>
> drm/rcar-du: Add FBDEV emulation support (2013-08-07 13:04:44 +0200)
>
>
> Laurent Pinchart (23):
> drm/rcar-du: Add missing alpha plane register definitions
> drm/rcar-du: Use devm_ioremap_resource()
> drm/rcar-du: Add platform module device table
> drm/rcar-du: Support per-CRTC clock and IRQ
> drm/rcar-du: Clarify comment regarding plane Y source coordinate
> drm/rcar-du: Split LVDS encoder and connector
> drm/rcar-du: Split VGA encoder and connector
> drm/rcar-du: Merge LVDS and VGA encoder code
> drm/rcar-du: Rename platform data fields to match what they describe
> drm/rcar-du: Create rcar_du_planes structure
> drm/rcar-du: Rename rcar_du_plane_(init|register) to rcar_du_planes_*
> drm/rcar-du: Introduce CRTCs groups
> drm/rcar-du: Use dynamic number of CRTCs instead of CRTCs array size
> drm/rcar-du: Remove register definitions for the second channel
> drm/rcar-du: Move output routing configuration to group
> drm/rcar-du: Add support for the R8A7790 DU
> drm/rcar-du: Fix buffer pitch alignment for R8A7790 DU
> drm/rcar-du: Add support for multiple groups
> drm/rcar-du: Add support for DEFR8 register
> drm/rcar-du: Rework output routing support
> drm/rcar-du: Configure RGB output routing to DPAD0
> drm/rcar-du: Add internal LVDS encoder support
> drm/rcar-du: Add FBDEV emulation support
>
> drivers/gpu/drm/rcar-du/Kconfig | 7 +
> drivers/gpu/drm/rcar-du/Makefile| 10 +-
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 255
> +-- drivers/gpu/drm/rcar-du/rcar_du_crtc.h |
> 13 +-
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 173
> +++ drivers/gpu/drm/rcar-du/rcar_du_drv.h |
> 63 -- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 202
> +++ drivers/gpu/drm/rcar-du/rcar_du_encoder.h |
> 49 + drivers/gpu/drm/rcar-du/rcar_du_group.c | 187
> +++ drivers/gpu/drm/rcar-du/rcar_du_group.h |
> 50 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 165
> --- drivers/gpu/drm/rcar-du/rcar_du_kms.h |
> 29 +-- .../drm/rcar-du/{rcar_du_lvds.c => rcar_du_lvdscon.c} | 101
> +- .../drm/rcar-du/{rcar_du_lvds.h => rcar_du_lvdscon.h} | 17 +-
> drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 196
> +++ drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |
> 46 + drivers/gpu/drm/rcar-du/rcar_du_plane.c | 170
> +++ drivers/gpu/drm/rcar-du/rcar_du_plane.h |
> 26 ++- drivers/gpu/drm/rcar-du/rcar_du_regs.h | 94
> +++-- .../gpu/drm/rcar-du/{rcar_du_vga.c => rcar_du_vgacon.c} | 65
> +- .../gpu/drm/rcar-du/{rcar_du_vga.h => rcar_du_vgacon.h} | 15 +-
> drivers/gpu/drm/rcar-du/rcar_lvds_regs.h| 69 +++
> include/linux/platform_data/rcar-du.h | 34 +++-
> 23 files changed, 1420 insertions(+), 616 deletions(-)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_group.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_group.h
> rename drivers/gpu/drm/rcar-du/{rcar_du_lvds.c => rcar_du_lvdscon.c} (57%)
> rename drivers/gpu/drm/rcar-du/{rcar_du_lvds.h => rcar_du_lvdscon.h} (53%)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
> rename drivers/gpu/drm/rcar-du/{rcar_du_vga.c => rcar_du_vgacon.c} (59%)
> rename drivers/gpu/drm/rcar-du/{rcar_du_vga.h => rcar_du_vgacon.h} (56%)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
--
Regards,
Laurent Pinchart
[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC
On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > Hi Dave, > > I've got a couple of arch/arm/ patches that depend on this series and that I > would like to get merged in v3.12. They should go upstream through the arm-soc > tree. Would you be able to provide a stable branch with this patch set based > on one of the 3.11-rcX tags ? Ideally that branch should have as little > patches as possible other than this set. Yeah that shouldn't be a problem, though is there any interface changes or things with this wrt drm-next? i.e. will this tree build on v3.11-rcX and drm-next? Dave.
[Bug 67876] linux v4.11-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot
https://bugs.freedesktop.org/show_bug.cgi?id=67876 --- Comment #2 from jim.cromie at gmail.com --- thank you Alex, the firmware page helped some. Turns out I needed more than the CEDAR_smc.bin, (which fwiw was never warned about) [1.756212] radeon :01:00.0: radeon_uvd: Can't load firmware "radeon/CYPRESS_uvd.bin" which went away only after fetching that FW too. So, having both FWs, I tested current master and it worked. (I'll assume that means my bisect-bad would too) $ uname -r 3.11.0-rc4-x2-00050-gb7bc9e7 [jimc at groucho bootlogs]$ dmesg| grep -E 'radeon|drm' [1.741557] [drm] Initialized drm 1.1.0 20060810 [1.773454] dynamic_debug:ddebug_add_module: 1 debug prints in module radeon [1.775402] [drm] radeon kernel modesetting enabled. [1.775714] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68E1 0x1787:0x3000). [1.775734] [drm] register mmio base: 0xFE9E [1.775735] [drm] register mmio size: 131072 [1.776643] radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [1.776645] radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF [1.776647] [drm] Detected VRAM RAM=1024M, BAR=256M [1.776648] [drm] RAM width 64bits DDR [1.776755] [drm] radeon: 1024M of VRAM memory ready [1.776757] [drm] radeon: 512M of GTT memory ready. [1.88] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.778782] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [1.778799] [drm] Loading CEDAR Microcode [1.788485] [drm] PCIE GART of 512M enabled (table at 0x0025D000). [1.788599] radeon :01:00.0: WB enabled [1.788602] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88021e466c00 [1.788604] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x88021e466c0c [1.788607] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc9001101c418 [1.788609] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.788610] [drm] Driver supports precise vblank timestamp query. [1.788632] radeon :01:00.0: irq 42 for MSI/MSI-X [1.788644] radeon :01:00.0: radeon: using MSI. [1.788667] [drm] radeon: irq initialized. [1.804943] [drm] ring test on 0 succeeded in 1 usecs [1.805001] [drm] ring test on 3 succeeded in 1 usecs [2.992422] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [4.013574] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [5.034731] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [6.055874] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [7.077016] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [8.098157] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [9.119302] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 10.140429] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.161610] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 12.182794] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 12.202894] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 12.202973] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). Im a bit puzzled at the apparent need for 2 different CODENAME_ firmwares, an also why theres no warning for missing CEDAR_smc.bin -- 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/20130808/91d8796e/attachment.html>
[PATCH 1/2] drm/i915: unpin backing storage in dmabuf_unmap
On Wed, Aug 07, 2013 at 08:50:20PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
> > This fixes a WARN in i915_gem_free_object when the
> > obj->pages_pin_count isn't 0.
> >
> > v2: Add locking to unmap, noticed by Chris Wilson. Note that even
> > though we call unmap with our own dev->struct_mutex held that won't
> > result in an immediate deadlock since we never go through the dma_buf
> > interfaces for our own, reimported buffers. But it's still easy to
> > blow up and anger lockdep, but that's already the case with our ->map
> > implementation. Fixing this for real will involve per dma-buf ww mutex
> > locking by the callers. And lots of fun. So go with the duct-tape
> > approach for now.
> >
> > Cc: Chris Wilson
> > Reported-by: Maarten Lankhorst
> > Cc: Maarten Lankhorst
> > Tested-by: Armin K. (v1)
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > index 63ee1a9..f7e1682 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> > @@ -85,9 +85,17 @@ static void i915_gem_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,
> >struct sg_table *sg,
> >enum dma_data_direction dir)
> > {
> > + struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
> > +
> > + mutex_lock(&obj->base.dev->struct_mutex);
> > +
> > dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir);
> > sg_free_table(sg);
> > kfree(sg);
> > +
> > + i915_gem_object_unpin_pages(obj);
>
> I am curious - would it logic of first unpinning, and then doing the
> dma_unmap_sg
> make more sense? As in, in the map path we do:
>
> dma_map
> pin
Actually this is the wrong way around, and is a potential issue.
Hindsight is a powerful tool.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC
Hi Dave, (CC'ing Simon Horman, the shmobile tree maintainer) On Thursday 08 August 2013 10:57:33 Dave Airlie wrote: > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > > Hi Dave, > > > > I've got a couple of arch/arm/ patches that depend on this series and that > > I would like to get merged in v3.12. They should go upstream through the > > arm-soc tree. Would you be able to provide a stable branch with this > > patch set based on one of the 3.11-rcX tags ? Ideally that branch should > > have as little patches as possible other than this set. > > Yeah that shouldn't be a problem, though is there any interface changes or > things with this wrt drm-next? > > i.e. will this tree build on v3.11-rcX and drm-next? They depend on a fix that went in between -rc1 and -rc2. You can base the branch on any -rc >= 2. -- Regards, Laurent Pinchart
[PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos drivers
> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Thursday, August 08, 2013 8:21 AM > To: Inki Dae > Cc: Daniel Vetter; Intel Graphics Development; DRI Development > Subject: Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in > i915/exynos drivers > > On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote: > > 2013/8/7 Daniel Vetter > > > > > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote: > > > > > > > > > > > > 2013/8/7 Daniel Vetter > > > >> > > > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote: > > > >> > On 08/07/2013 06:55 PM, Daniel Vetter wrote: > > > >> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae > > > wrote: > > > >> > >>>-Original Message- > > > >> > >>>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] > > > >> > >>>Sent: Wednesday, August 07, 2013 6:15 PM > > > >> > >>>To: DRI Development > > > >> > >>>Cc: Intel Graphics Development; Daniel Vetter; Inki Dae > > > >> > >>>Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in > > > >> > >>> i915/exynos > > > >> > >>>drivers > > > >> > >>> > > > >> > >>>Note that this is slightly tricky since both drivers store > their > > > >> > >>>native objects in dma_buf->priv. But both also embed the base > > > >> > >>>drm_gem_object at the first position, so the implicit cast is > ok. > > > >> > >>> > > > >> > >>>To use the release helper we need to export it, too. > > > >> > >>Yeah, may I repost this patch with additional work? We also > need to > > > >> > >> export > > > >> > >>with a gem object instead of specific one like you did. > > > >> > > > > >> > I think dmabuf stuff of exynos can be replaced to common > > > drm_gem_dmabuf. > > > >> > Already dmabuf stuff of drm_gem_cma_helper.c was substituted to > common > > > >> > drm_gem_dmabuf with low-level hook functions to use prime helpers. > > > >> > > > >> Ah, but that can easily be done on top of this, right? > > > > > > > > > > > > Daniel, could you remove exynos related codes from your patch set? > Your > > > > patch set would make exynos broken because you didn't consider > exporting > > > > with a gem object for exynos like [PATCH 3/3] drm/i915: explicit > store > > > base > > > > gem object in dma_buf->priv. So I think your patch set is not > complete > > > set, > > > > and That is why exynos needs the additional work I mentioned above. > So I > > > > just wanted to repost your patch set + new one. > > > > > > Nope, my patch should not break exynos since the base gem_object is > > > the first member of the exynos object, so we don't have any issues > > > > > > > Ah, right. However, it does not seem like good way. > > > > > > > with upcasting in exynos dma-buf code. The same applies to i915 > > > dma-buf code, my follow-up patch just makes the code a bit safer. > > > > > > > > > > > > > > > > > > > > > > However, I think not only exynos could go to common drm_gem_dmabuf > > > directly > > > > but also it would make your patch set to be complete set if you > remove > > > > exynos related codes from your patch set. Otherwise, we have to work > > > twice. > > > > one is the additional work for resolving exynos broken issue by your > > > patch > > > > set, and other is to replace existing dmabuf stuff of exynos to > common > > > > drm_gem_dmabuf. > > > > > > Yeah np, I'll drop exynos then. > > > > > > > Thanks a lot. :) > > Ah, I remember again why I want to also convert over exynos to the common > dma buf release function: Later patches in my prime locking series will > change things in there to avoid a userspace-triggerable oops. If we leave > out exynos it'll break rather badly for dma-buf export. > > I need to think a bit more about what stuff looks like atm, but if I > resend those parts I'll include exynos. It's a bit tricky that it still > works, but that way you can fix it up without the introduction of a bisect > failure point. I'll repost your patch set + new one that exports to a common gem object; already worked and tested. I think it's good for they to be one set because only using the patch 1/3 doesn't look good even though Exynos works fine with the path 1/3. So I'll repost it like below if you agree with me, [PATCH 0/4] Small i915/exynos prime cleanup [PATCH 1/4] drm: use common drm_gem_dmabuf_release in i915/exynos drivers [PATCH 2/4] drm/i915: unpin backing storage in dmabuf_unmap [PATCH 3/4] drm/i915: explicit store base gem object in dma_buf->priv [PATCH 4/4] drm/exynos: explicit store base gem object in dma_buf->priv After this, you can take care of them until merged to next. Or you can repost this patch set including my patch again. What you proper doesn't matter to me. :) And it seems better that exynos keeps using existing dmabuf interfaces without replacing them to common drm_gem_dmabuf ones because we may need features only for Exynos. Actually, now exynos dmabuf includes some features related to v4l2 and gpu driver for more performance. Than
[pull] radeon drm-fixes-3.11
2013/8/8 Alex Deucher : > Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs > with dpm on more rv6xx asics, and fixes suspend and resume with UVD. That fix audio dto calculation on DCE3+ looks promising, I had no idea you're working on that. Thanks for releasing that! Maybe you could post your patches for review on dri-devel@? If you don't want Dave to take them, maybe just post them with [RFC]? -- Rafa?
[PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf->priv
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -22,6 +22,11 @@ struct exynos_drm_dmabuf_attachment {
bool is_mapped;
};
+static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
+{
+ return to_exynos_gem_obj(buf->priv);
+}
+
static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
struct device *dev,
struct dma_buf_attachment *attach)
@@ -63,7 +68,7 @@ static struct sg_table *
enum dma_data_direction dir)
{
struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
- struct exynos_drm_gem_obj *gem_obj = attach->dmabuf->priv;
+ struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
struct drm_device *dev = gem_obj->base.dev;
struct exynos_drm_gem_buf *buf;
struct scatterlist *rd, *wr;
@@ -180,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
drm_device *drm_dev,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
- return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops,
+ return dma_buf_export(obj, &exynos_dmabuf_ops,
exynos_gem_obj->base.size, flags);
}
@@ -198,8 +203,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
if (dma_buf->ops == &exynos_dmabuf_ops) {
struct drm_gem_object *obj;
- exynos_gem_obj = dma_buf->priv;
- obj = &exynos_gem_obj->base;
+ obj = dma_buf->priv;
/* is it from our device? */
if (obj->dev == drm_dev) {
--
1.7.5.4
[PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf->priv
Hi, Daniel. You can repost your patch set including the below my patch. And
my patch numbering is wrong. Sorry about that.
[PATCH 1/4] -> [PATCH 4/4]
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Thursday, August 08, 2013 1:40 PM
> To: daniel at ffwll.ch
> Cc: dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org;
> Inki
> Dae; Kyungmin Park
> Subject: [PATCH 1/4] drm/exynos: explicit store base gem object in
> dma_buf->priv
>
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
> 1 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> index 3cd56e1..fd76449 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
> @@ -22,6 +22,11 @@ struct exynos_drm_dmabuf_attachment {
> bool is_mapped;
> };
>
> +static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
> +{
> + return to_exynos_gem_obj(buf->priv);
> +}
> +
> static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
> struct device *dev,
> struct dma_buf_attachment *attach)
> @@ -63,7 +68,7 @@ static struct sg_table *
> enum dma_data_direction dir)
> {
> struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
> - struct exynos_drm_gem_obj *gem_obj = attach->dmabuf->priv;
> + struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
> struct drm_device *dev = gem_obj->base.dev;
> struct exynos_drm_gem_buf *buf;
> struct scatterlist *rd, *wr;
> @@ -180,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
> drm_device *drm_dev,
> {
> struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
>
> - return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops,
> + return dma_buf_export(obj, &exynos_dmabuf_ops,
> exynos_gem_obj->base.size, flags);
> }
>
> @@ -198,8 +203,7 @@ struct drm_gem_object
> *exynos_dmabuf_prime_import(struct drm_device *drm_dev,
> if (dma_buf->ops == &exynos_dmabuf_ops) {
> struct drm_gem_object *obj;
>
> - exynos_gem_obj = dma_buf->priv;
> - obj = &exynos_gem_obj->base;
> + obj = dma_buf->priv;
>
> /* is it from our device? */
> if (obj->dev == drm_dev) {
> --
> 1.7.5.4
[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC
On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote: > Hi Dave, > > (CC'ing Simon Horman, the shmobile tree maintainer) > > On Thursday 08 August 2013 10:57:33 Dave Airlie wrote: > > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > > > Hi Dave, > > > > > > I've got a couple of arch/arm/ patches that depend on this series and that > > > I would like to get merged in v3.12. They should go upstream through the > > > arm-soc tree. Would you be able to provide a stable branch with this > > > patch set based on one of the 3.11-rcX tags ? Ideally that branch should > > > have as little patches as possible other than this set. > > > > Yeah that shouldn't be a problem, though is there any interface changes or > > things with this wrt drm-next? > > > > i.e. will this tree build on v3.11-rcX and drm-next? > > They depend on a fix that went in between -rc1 and -rc2. You can base the > branch on any -rc >= 2. An rc2 or rc3 base would be ideal for me, but any rc would be fine.
[PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos drivers
On Thu, Aug 8, 2013 at 6:32 AM, Inki Dae wrote: > > >> -Original Message- >> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel >> Vetter >> Sent: Thursday, August 08, 2013 8:21 AM >> To: Inki Dae >> Cc: Daniel Vetter; Intel Graphics Development; DRI Development >> Subject: Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in >> i915/exynos drivers >> >> On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote: >> > 2013/8/7 Daniel Vetter >> > >> > > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote: >> > > > >> > > > >> > > > 2013/8/7 Daniel Vetter >> > > >> >> > > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote: >> > > >> > On 08/07/2013 06:55 PM, Daniel Vetter wrote: >> > > >> > >On Wed, Aug 7, 2013 at 11:40 AM, Inki Dae >> > > wrote: >> > > >> > >>>-Original Message- >> > > >> > >>>From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] >> > > >> > >>>Sent: Wednesday, August 07, 2013 6:15 PM >> > > >> > >>>To: DRI Development >> > > >> > >>>Cc: Intel Graphics Development; Daniel Vetter; Inki Dae >> > > >> > >>>Subject: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in >> > > >> > >>> i915/exynos >> > > >> > >>>drivers >> > > >> > >>> >> > > >> > >>>Note that this is slightly tricky since both drivers store >> their >> > > >> > >>>native objects in dma_buf->priv. But both also embed the base >> > > >> > >>>drm_gem_object at the first position, so the implicit cast is >> ok. >> > > >> > >>> >> > > >> > >>>To use the release helper we need to export it, too. >> > > >> > >>Yeah, may I repost this patch with additional work? We also >> need to >> > > >> > >> export >> > > >> > >>with a gem object instead of specific one like you did. >> > > >> > >> > > >> > I think dmabuf stuff of exynos can be replaced to common >> > > drm_gem_dmabuf. >> > > >> > Already dmabuf stuff of drm_gem_cma_helper.c was substituted to >> common >> > > >> > drm_gem_dmabuf with low-level hook functions to use prime > helpers. >> > > >> >> > > >> Ah, but that can easily be done on top of this, right? >> > > > >> > > > >> > > > Daniel, could you remove exynos related codes from your patch set? >> Your >> > > > patch set would make exynos broken because you didn't consider >> exporting >> > > > with a gem object for exynos like [PATCH 3/3] drm/i915: explicit >> store >> > > base >> > > > gem object in dma_buf->priv. So I think your patch set is not >> complete >> > > set, >> > > > and That is why exynos needs the additional work I mentioned above. >> So I >> > > > just wanted to repost your patch set + new one. >> > > >> > > Nope, my patch should not break exynos since the base gem_object is >> > > the first member of the exynos object, so we don't have any issues >> > > >> > >> > Ah, right. However, it does not seem like good way. >> > >> > >> > > with upcasting in exynos dma-buf code. The same applies to i915 >> > > dma-buf code, my follow-up patch just makes the code a bit safer. >> > > >> > > >> > > >> > >> > > >> > >> > > >> > > However, I think not only exynos could go to common drm_gem_dmabuf >> > > directly >> > > > but also it would make your patch set to be complete set if you >> remove >> > > > exynos related codes from your patch set. Otherwise, we have to work >> > > twice. >> > > > one is the additional work for resolving exynos broken issue by your >> > > patch >> > > > set, and other is to replace existing dmabuf stuff of exynos to >> common >> > > > drm_gem_dmabuf. >> > > >> > > Yeah np, I'll drop exynos then. >> > > >> > >> > Thanks a lot. :) >> >> Ah, I remember again why I want to also convert over exynos to the common >> dma buf release function: Later patches in my prime locking series will >> change things in there to avoid a userspace-triggerable oops. If we leave >> out exynos it'll break rather badly for dma-buf export. >> >> I need to think a bit more about what stuff looks like atm, but if I >> resend those parts I'll include exynos. It's a bit tricky that it still >> works, but that way you can fix it up without the introduction of a bisect >> failure point. > > I'll repost your patch set + new one that exports to a common gem object; > already worked and tested. I think it's good for they to be one set because > only using the patch 1/3 doesn't look good even though Exynos works fine > with the path 1/3. > > So I'll repost it like below if you agree with me, > [PATCH 0/4] Small i915/exynos prime cleanup > [PATCH 1/4] drm: use common drm_gem_dmabuf_release in i915/exynos drivers > [PATCH 2/4] drm/i915: unpin backing storage in dmabuf_unmap > [PATCH 3/4] drm/i915: explicit store base gem object in dma_buf->priv > [PATCH 4/4] drm/exynos: explicit store base gem object in dma_buf->priv > > After this, you can take care of them until merged to next. Or you can > repost this patch set including my patch again. What you proper doesn't > matter to me. :) Yeah, sounds like a plan. And I think those 4 patches can go in earlier, the later patches I
