Re: [PATCHv2 0/7] Miscellaneous fixes to host1x

[Terje Bergström]

On 29.05.2013 13:26, Arto Merilainen wrote:
> This patch series fixes two issues in the host1x driver: First, the
> command buffer validation routine had vulnerabilities that were not
> detected in earlier testing. Second, the return codes of some
> functions were misleading or completely missing. This caused the
> driver to give wrong return codes also to the userspace.
> 
> The series is based on top of 3.10rc3. I have tested the patch series
> on cardhu by running host1x and gr2d test cases (available at [0]).
> I would appreciate any help in testing/reviewing these patches.
> 
> Changes from v1:
>  * Rebased on top of 3.10rc3
>  * Split firewall fixes to smaller patches
>  * Reworked no-reloc case in firewall code. Fix in v1 was not
>sufficient in all cases
>  * Dropped patch "Fix syncpoint wait return value" as it is not
>critical and discussion on it has not yet settled.
>  * Fixed style and whitespace issues
> 
> [0] https://gitorious.org/linux-host1x/libdrm-host1x
> 
> Arto Merilainen (5):
>   gpu: host1x: Check reloc table before usage
>   gpu: host1x: Copy gathers before verification
>   gpu: host1x: Fix memory access in syncpt request
>   gpu: host1x: Fix client_managed type
>   gpu: host1x: Rework CPU syncpoint increment
> 
> Terje Bergstrom (2):
>   gpu: host1x: Check INCR opcode correctly
>   gpu: host1x: Don't reset firewall between gathers
> 
>  drivers/gpu/host1x/dev.h  |   8 +--
>  drivers/gpu/host1x/drm/drm.c  |   3 +-
>  drivers/gpu/host1x/drm/gr2d.c |   2 +-
>  drivers/gpu/host1x/hw/cdma_hw.c   |   2 +-
>  drivers/gpu/host1x/hw/syncpt_hw.c |  12 ++--
>  drivers/gpu/host1x/job.c  | 135 
> +-
>  drivers/gpu/host1x/syncpt.c   |  26 +++-
>  drivers/gpu/host1x/syncpt.h   |  13 ++--
>  8 files changed, 85 insertions(+), 116 deletions(-)
> 

Arto's patches above,

Acked-By: Terje Bergstrom 

Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] MAINTAINERS: update path for drm tegra driver

[Ying Xue]

Since 4231c6b01af9f0f3eeca4b8d0d87125d78233b41 commit, drm tegra
driver was moved to host1x, however, its correspding entry in
MAINTAINERS is not updated in time.

Signed-off-by: Ying Xue 
---
 MAINTAINERS |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7714c3c..d672968 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2702,7 +2702,7 @@ L:dri-devel@lists.freedesktop.org
 L: linux-te...@vger.kernel.org
 T: git git://gitorious.org/thierryreding/linux.git
 S: Maintained
-F: drivers/gpu/drm/tegra/
+F: drivers/gpu/host1x/drm/
 F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
 
 DSBR100 USB FM RADIO DRIVER
-- 
1.7.9.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Seung-Woo Kim]

importer private data in dma-buf attachment can be used by importer to
reimport same dma-buf.

Seung-Woo Kim (2):
  dma-buf: add importer private data to attachment
  drm/prime: find gem object from the reimported dma-buf

 drivers/base/dma-buf.c |   31 
 drivers/gpu/drm/drm_prime.c|   19 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
 drivers/gpu/drm/udl/udl_gem.c  |1 +
 include/linux/dma-buf.h|4 +++
 6 files changed, 52 insertions(+), 5 deletions(-)

-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH 2/2] drm/prime: find gem object from the reimported dma-buf

[Seung-Woo Kim]

Reimported dma-buf can reuse same gem object only when prime import
is done with same drm open context. So prime import is done with
other drm open context, gem object is newly created and mapped even
there is already mapped gem object. To avoid recreating gem object,
importer private data can be used at reimport time if it is assigned
with drm gem object at first import.
This can also remove remapping dma address for the hardware having
its own iommu.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/drm_prime.c|   19 ++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
 drivers/gpu/drm/udl/udl_gem.c  |1 +
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index dcde352..78a3c7d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -294,6 +294,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
}
 
obj->import_attach = attach;
+   attach->importer_priv = obj;
 
return obj;
 
@@ -312,6 +313,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
 {
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
+   struct dma_buf_attachment *attach;
int ret;
 
dma_buf = dma_buf_get(prime_fd);
@@ -327,11 +329,18 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto out_put;
}
 
-   /* never seen this one, need to import */
-   obj = dev->driver->gem_prime_import(dev, dma_buf);
-   if (IS_ERR(obj)) {
-   ret = PTR_ERR(obj);
-   goto out_put;
+   attach = dma_buf_get_attachment(dma_buf, dev->dev);
+   if (IS_ERR(attach)) {
+   /* never seen this one, need to import */
+   obj = dev->driver->gem_prime_import(dev, dma_buf);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto out_put;
+   }
+   } else {
+   /* found attachment to same device */
+   obj = attach->importer_priv;
+   drm_gem_object_reference(obj);
}
 
ret = drm_gem_handle_create(file_priv, obj, handle);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ff7f2a8..268da36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -285,6 +285,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
exynos_gem_obj->buffer = buffer;
buffer->sgt = sgt;
exynos_gem_obj->base.import_attach = attach;
+   attach->importer_priv = &exynos_gem_obj->base;
 
DRM_DEBUG_PRIME("dma_addr = 0x%x, size = 0x%lx\n", buffer->dma_addr,
buffer->size);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..75ef28c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -297,6 +297,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 
i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops);
obj->base.import_attach = attach;
+   attach->importer_priv = &obj->base;
 
return &obj->base;
 
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index ef034fa..0652db1 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -317,6 +317,7 @@ struct drm_gem_object *udl_gem_prime_import(struct 
drm_device *dev,
}
 
uobj->base.import_attach = attach;
+   attach->importer_priv = &uobj->base;
 
return &uobj->base;
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC][PATCH 1/2] dma-buf: add importer private data to attachment

[Seung-Woo Kim]

dma-buf attachment has only exporter private data, but importer private data
can be useful for importer especially to re-import the same dma-buf.
To use importer private data in attachment of the device, the function to
search attachment in the attachment list of dma-buf is also added.

Signed-off-by: Seung-Woo Kim 
---
 drivers/base/dma-buf.c  |   31 +++
 include/linux/dma-buf.h |4 
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 08fe897..a1eaaf2 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -259,6 +259,37 @@ err_attach:
 EXPORT_SYMBOL_GPL(dma_buf_attach);
 
 /**
+ * dma_buf_get_attachment - Get attachment with the device from dma_buf's
+ * attachments list
+ * @dmabuf:[in]buffer to find device from.
+ * @dev:   [in]device to be found.
+ *
+ * Returns struct dma_buf_attachment * attaching the device; may return
+ * negative error codes.
+ *
+ */
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+   struct dma_buf_attachment *attach;
+
+   if (WARN_ON(!dmabuf || !dev))
+   return ERR_PTR(-EINVAL);
+
+   mutex_lock(&dmabuf->lock);
+   list_for_each_entry(attach, &dmabuf->attachments, node) {
+   if (attach->dev == dev) {
+   mutex_unlock(&dmabuf->lock);
+   return attach;
+   }
+   }
+   mutex_unlock(&dmabuf->lock);
+
+   return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
+
+/**
  * dma_buf_detach - Remove the given attachment from dmabuf's attachments list;
  * optionally calls detach() of dma_buf_ops for device-specific detach
  * @dmabuf:[in]buffer to detach from.
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..09cff0f 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -136,6 +136,7 @@ struct dma_buf {
  * @dev: device attached to the buffer.
  * @node: list of dma_buf_attachment.
  * @priv: exporter specific attachment data.
+ * @importer_priv: importer specific attachment data.
  *
  * This structure holds the attachment information between the dma_buf buffer
  * and its user device(s). The list contains one attachment struct per device
@@ -146,6 +147,7 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+   void *importer_priv;
 };
 
 /**
@@ -164,6 +166,8 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
 
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+   struct device *dev);
 void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);
 
-- 
1.7.4.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  wrote:
> importer private data in dma-buf attachment can be used by importer to
> reimport same dma-buf.
>
> Seung-Woo Kim (2):
>   dma-buf: add importer private data to attachment
>   drm/prime: find gem object from the reimported dma-buf

Self-import should already work (at least with the latest refcount
fixes merged). At least the tests to check both re-import on the same
drm fd and on a different all work as expected now.

Second, the dma_buf_attachment is _definitely_ the wrong place to do
this. If you need iommu mapping caching, that should happen at a lower
level (i.e. in the map_attachment callback somewhere of the exporter,
that's what the priv field in the attachment is for). Snatching away
the attachement from some random other import is certainly not the way
to go - attachements are _not_ refcounted!
-Daniel

>
>  drivers/base/dma-buf.c |   31 
> 
>  drivers/gpu/drm/drm_prime.c|   19 
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
>  drivers/gpu/drm/udl/udl_gem.c  |1 +
>  include/linux/dma-buf.h|4 +++
>  6 files changed, 52 insertions(+), 5 deletions(-)
>
> --
> 1.7.4.1
>



--
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 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #11 from Michel Dänzer  ---
(In reply to comment #10)
> Should I use newer tag than 1.1?

You wrote the problem happens with 9.1.2 but not with 9.1.1, so it's probably
best to stay within those tags for now.


> I think strage that compiling mAster was on error for me.. Normally aren't
> the pull self-contined?

Can't really say anything about that without at least seeing the error.

-- 
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 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65192

--- Comment #2 from Michel Dänzer  ---
(In reply to comment #2)
> Setting R600_HYPERZ=0 in /etc/environment didn't help.

Are you sure this ended up in the environment of the screensaver hacks? Can you
try e.g.

R600_HYPERZ=0 /usr/lib/xscreensaver/antmaze

manually to see if that works better? Same thing might be interesting for
R600_DEBUG=sb (or R600_LLVM=0, but AFAICT you're building without the r600g
LLVM compiler backend anyway?).

-- 
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: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[김승우]

Hello Daniel,

Thanks for your comment.

On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  
> wrote:
>> importer private data in dma-buf attachment can be used by importer to
>> reimport same dma-buf.
>>
>> Seung-Woo Kim (2):
>>   dma-buf: add importer private data to attachment
>>   drm/prime: find gem object from the reimported dma-buf
> 
> Self-import should already work (at least with the latest refcount
> fixes merged). At least the tests to check both re-import on the same
> drm fd and on a different all work as expected now.

Currently, prime works well for all case including self-importing,
importing, and reimporting as you describe. Just, importing dma-buf from
other driver twice with different drm_fd, each import create its own gem
object even two import is done for same buffer because prime_priv is in
struct drm_file. This means mapping to the device is done also twice.
IMHO, these duplicated creations and maps are not necessary if drm can
find previous import in different prime_priv.

> 
> Second, the dma_buf_attachment is _definitely_ the wrong place to do
> this. If you need iommu mapping caching, that should happen at a lower
> level (i.e. in the map_attachment callback somewhere of the exporter,
> that's what the priv field in the attachment is for). Snatching away
> the attachement from some random other import is certainly not the way
> to go - attachements are _not_ refcounted!

Yes, attachments do not have refcount, so importer should handle and drm
case in my patch, importer private data is gem object and it has, of
course, refcount.

And at current, exporter can not classify map_dma_buf requests of same
importer to same buffer with different attachment because dma_buf_attach
always makes new attachments. To resolve this exporter should search all
different attachment from same importer of dma-buf and it seems more
complex than importer private data to me.

If I misunderstood something, please let me know.

Best Regards,
- Seung-Woo Kim

> -Daniel
> 
>>
>>  drivers/base/dma-buf.c |   31 
>> 
>>  drivers/gpu/drm/drm_prime.c|   19 
>>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
>>  drivers/gpu/drm/udl/udl_gem.c  |1 +
>>  include/linux/dma-buf.h|4 +++
>>  6 files changed, 52 insertions(+), 5 deletions(-)
>>
>> --
>> 1.7.4.1
>>
> 
> 
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: Preserve the list head in drm_mode_copy

[ville . syrjala]

From: Ville Syrjälä 

Preserve the destination mode's list head in drm_mode_copy. Just
in case someone decides that it's a good idea to overwrite a mode which
happens to be on some list,

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a371ff8..ba86316 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -787,16 +787,17 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
  * LOCKING:
  * None.
  *
- * Copy an existing mode into another mode, preserving the object id
- * of the destination mode.
+ * Copy an existing mode into another mode, preserving the object id and
+ * list head of the destination mode.
  */
 void drm_mode_copy(struct drm_display_mode *dst, const struct drm_display_mode 
*src)
 {
int id = dst->base.id;
+   struct list_head head = dst->head;
 
*dst = *src;
dst->base.id = id;
-   INIT_LIST_HEAD(&dst->head);
+   dst->head = head;
 }
 EXPORT_SYMBOL(drm_mode_copy);
 
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm: Add probed modes in probe order

[ville . syrjala]

From: Ville Syrjälä 

Keeping the modes in the same order as we probe them makes it a bit
easier to track what's happening.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..f072ac6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -657,7 +657,7 @@ EXPORT_SYMBOL(drm_crtc_cleanup);
 void drm_mode_probed_add(struct drm_connector *connector,
 struct drm_display_mode *mode)
 {
-   list_add(&mode->head, &connector->probed_modes);
+   list_add_tail(&mode->head, &connector->probed_modes);
 }
 EXPORT_SYMBOL(drm_mode_probed_add);
 
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm: Sort connector modes based on vrefresh

[ville . syrjala]

From: Ville Syrjälä 

Keeping the modes sorted by vrefresh before the pixel clock makes the
mode list somehow more pleasing to the eye.

Signed-off-by: Ville Syrjälä 
---
This is quite a subjective thing, so if no one else wants it, I'm fine
with dropping it. More of an RFC really...

 drivers/gpu/drm/drm_crtc_helper.c | 5 +++--
 drivers/gpu/drm/drm_modes.c   | 5 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ed1334e..f554516 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -189,13 +189,14 @@ prune:
if (list_empty(&connector->modes))
return 0;
 
+   list_for_each_entry(mode, &connector->modes, head)
+   mode->vrefresh = drm_mode_vrefresh(mode);
+
drm_mode_sort(&connector->modes);
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] probed modes :\n", connector->base.id,
drm_get_connector_name(connector));
list_for_each_entry(mode, &connector->modes, head) {
-   mode->vrefresh = drm_mode_vrefresh(mode);
-
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
drm_mode_debug_printmodeline(mode);
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ba86316..4370fd4 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1018,6 +1018,11 @@ static int drm_mode_compare(void *priv, struct list_head 
*lh_a, struct list_head
diff = b->hdisplay * b->vdisplay - a->hdisplay * a->vdisplay;
if (diff)
return diff;
+
+   diff = b->vrefresh - a->vrefresh;
+   if (diff)
+   return diff;
+
diff = b->clock - a->clock;
return diff;
 }
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[ville . syrjala]

From: Ville Syrjälä 

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä 
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.

 drivers/gpu/drm/drm_edid.c | 102 ++---
 1 file changed, 88 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e62bbe..e8d17ee 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2321,6 +2321,31 @@ u8 *drm_find_cea_extension(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_find_cea_extension);
 
+/*
+ * Calculate the alternate clock for the CEA mode
+ * (60Hz vs. 59.94Hz etc.)
+ */
+static unsigned int
+cea_mode_alternate_clock(const struct drm_display_mode *cea_mode)
+{
+   unsigned int clock = cea_mode->clock;
+
+   if (cea_mode->vrefresh % 6 != 0)
+   return clock;
+
+   /*
+* edid_cea_modes contains the 59.94Hz
+* variant for 240 and 480 line modes,
+* and the 60Hz variant otherwise.
+*/
+   if (cea_mode->vdisplay == 240 || cea_mode->vdisplay == 480)
+   clock = clock * 1001 / 1000;
+   else
+   clock = DIV_ROUND_UP(clock * 1000, 1001);
+
+   return clock;
+}
+
 /**
  * drm_match_cea_mode - look for a CEA mode matching given mode
  * @to_match: display mode
@@ -2339,21 +2364,9 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
const struct drm_display_mode *cea_mode = &edid_cea_modes[mode];
unsigned int clock1, clock2;
 
-   clock1 = clock2 = cea_mode->clock;
-
/* Check both 60Hz and 59.94Hz */
-   if (cea_mode->vrefresh % 6 == 0) {
-   /*
-* edid_cea_modes contains the 59.94Hz
-* variant for 240 and 480 line modes,
-* and the 60Hz variant otherwise.
-*/
-   if (cea_mode->vdisplay == 240 ||
-   cea_mode->vdisplay == 480)
-   clock1 = clock1 * 1001 / 1000;
-   else
-   clock2 = DIV_ROUND_UP(clock2 * 1000, 1001);
-   }
+   clock1 = cea_mode->clock;
+   clock2 = cea_mode_alternate_clock(cea_mode);
 
if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
 KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
@@ -2364,6 +2377,66 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);
 
+static int
+add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *mode, *tmp;
+   LIST_HEAD(list);
+   int modes = 0;
+
+   /* Don't add CEA modes if the CEA extension block is missing */
+   if (!drm_find_cea_extension(edid))
+   return 0;
+
+   /*
+* Go through all probed modes and create a new mode
+* with the alternate clock for certain CEA modes.
+*/
+   list_for_each_entry(mode, &connector->probed_modes, head) {
+   const struct drm_display_mode *cea_mode;
+   struct drm_display_mode *newmode;
+   u8 cea_mode_idx = drm_match_cea_mode(mode) - 1;
+   unsigned int clock1, clock2;
+
+   if (cea_mode_idx >= ARRAY_SIZE(edid_cea_modes))
+   continue;
+
+   cea_mode = &edid_cea_modes[cea_mode_idx];
+
+   clock1 = cea_mode->clock;
+   clock2 = cea_mode_alternate_clock(cea_mode);
+
+   if (clock1 == clock2)
+   continue;
+
+   if (mode->clock != clock1 && mode->clock != clock2)
+   continue;
+
+   newmode = drm_mode_duplicate(dev, cea_mode);
+   if (!newmode)
+   continue;

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

Andreas Boll  changed:

   What|Removed |Added

 CC||pt...@yandex.ru

--- Comment #4 from Andreas Boll  ---
Are you using the default backend + sb or llvm backend + sb?

Ccing vadimg.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: Preserve the list head in drm_mode_copy

[Alex Deucher]

On Fri, May 31, 2013 at 8:17 AM,   wrote:
> From: Ville Syrjälä 
>
> Preserve the destination mode's list head in drm_mode_copy. Just
> in case someone decides that it's a good idea to overwrite a mode which
> happens to be on some list,
>
> Signed-off-by: Ville Syrjälä 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_modes.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index a371ff8..ba86316 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -787,16 +787,17 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
>   * LOCKING:
>   * None.
>   *
> - * Copy an existing mode into another mode, preserving the object id
> - * of the destination mode.
> + * Copy an existing mode into another mode, preserving the object id and
> + * list head of the destination mode.
>   */
>  void drm_mode_copy(struct drm_display_mode *dst, const struct 
> drm_display_mode *src)
>  {
> int id = dst->base.id;
> +   struct list_head head = dst->head;
>
> *dst = *src;
> dst->base.id = id;
> -   INIT_LIST_HEAD(&dst->head);
> +   dst->head = head;
>  }
>  EXPORT_SYMBOL(drm_mode_copy);
>
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"

[Konrad Rzeszutek Wilk]

On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
> 
> > My NV96 does not resume from suspend to ram (the screen stays black, magic
> > sysrq keys do work) with the current linus git kernel, i bisected it to the
> > following commit.
> >
> > drm/nv50/fifo: prevent races between clients updating playlists
> > b5096566f6e1ee2b88324772f020ae9bc0cfa9a0
> >
> > It's not obvious to me how this causes problems, but reverting this commit
> > does solve my problem.
> 
> Same here on my NV86.

And as well on this:

01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] 
(rev a1)


Ben, any ideas?
> 
> Cheers,
>Sven
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64475] Slow work and low brightness in Euro Track Simulator II game with HD6850

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64475

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

--- Comment #1 from Andreas Boll  ---
Could you attach a screenshot of the game using the gallium hud

e.g
GALLIUM_HUD="cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,primitives-generated"

Have you tried to set the cpu-governor to performance?
Are you using the high power state of you gpu?

-- 
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 65091] power_profile not working for HD5650

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65091

Andreas Boll  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/DRI/R600|DRM/Radeon

-- 
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 59101] New: Gnome shell crashes after sleep mode

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=59101

   Summary: Gnome shell crashes after sleep mode
   Product: Drivers
   Version: 2.5
Kernel Version: 3.9.4-200.fc18.x86_64
  Platform: All
OS/Version: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: cx42...@gmail.com
Regression: No


Hi!

I opened a ticket at Gnome bugzilla about this crash, but it appears to be a
problem regarding my driver from the graphic card :

When I have Gnome-shell that crashes, I can close the session (via the Aww snap
message) and re-open a session, I can then show dmesg which displays everytime
this message :

> [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

I tried to install the proprietary drivers, but it's not supported by Fedora
18.

For information, I work with a Dual Screen, and I'm using Fedora 18.

If you need any more information, please ask :)

For information, here's the ticket I opened at Gnome :
https://bugzilla.gnome.org/show_bug.cgi?id=701248

Thanks.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

--- Comment #5 from Vadim Girlin  ---
Created attachment 80097
  --> https://bugs.freedesktop.org/attachment.cgi?id=80097&action=edit
[PATCH] r600g/sb: fix broken assert

Attached patch should fix the assert. Does it fix you issues?

-- 
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 59101] Gnome shell crashes after sleep mode

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=59101


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com




--- Comment #1 from Alex Deucher   2013-05-31 13:58:59 
---
This may be a duplicate of this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=61182
Please attach your xorg log and dmesg output.  What version of mesa are you
using?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> Hello Daniel,
> 
> Thanks for your comment.
> 
> On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  
> > wrote:
> >> importer private data in dma-buf attachment can be used by importer to
> >> reimport same dma-buf.
> >>
> >> Seung-Woo Kim (2):
> >>   dma-buf: add importer private data to attachment
> >>   drm/prime: find gem object from the reimported dma-buf
> > 
> > Self-import should already work (at least with the latest refcount
> > fixes merged). At least the tests to check both re-import on the same
> > drm fd and on a different all work as expected now.
> 
> Currently, prime works well for all case including self-importing,
> importing, and reimporting as you describe. Just, importing dma-buf from
> other driver twice with different drm_fd, each import create its own gem
> object even two import is done for same buffer because prime_priv is in
> struct drm_file. This means mapping to the device is done also twice.
> IMHO, these duplicated creations and maps are not necessary if drm can
> find previous import in different prime_priv.

Well, that's imo a bug with the other driver. If it doesn't export
something really simple (e.g. contiguous memory which doesn't require any
mmio resources at all) it should have a cache of exported dma_buf fds so
that it hands out the same dma_buf every time.

Or it needs to be more clever in it's dma_buf_attachment_map functions and
lookup up a pre-existing iommu mapping.

But dealing with this in the importer is just broken.

> > Second, the dma_buf_attachment is _definitely_ the wrong place to do
> > this. If you need iommu mapping caching, that should happen at a lower
> > level (i.e. in the map_attachment callback somewhere of the exporter,
> > that's what the priv field in the attachment is for). Snatching away
> > the attachement from some random other import is certainly not the way
> > to go - attachements are _not_ refcounted!
> 
> Yes, attachments do not have refcount, so importer should handle and drm
> case in my patch, importer private data is gem object and it has, of
> course, refcount.
> 
> And at current, exporter can not classify map_dma_buf requests of same
> importer to same buffer with different attachment because dma_buf_attach
> always makes new attachments. To resolve this exporter should search all
> different attachment from same importer of dma-buf and it seems more
> complex than importer private data to me.
> 
> If I misunderstood something, please let me know.

Like I've said above, just fix this in the exporter. If an importer sees
two different dma_bufs it can very well presume that it those two indeed
point to different backing storage.

This will be even more important if we attach fences two dma_bufs. If your
broken exporter creates multiple dma_bufs each one of them will have their
own fences attached, leading to a complete disasters. Ok, strictly
speaking if you keep the same reservation pointer for each dma_buf it'll
work, but that's just a detail of how you solve this in the exporter.

Cheers, Daniel
-- 
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] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Daniel Vetter]

On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Having both modes can be beneficial for video playback cases. If you can
> match the video framerate exactly, and the audio and video clocks come
> from the same source, you should be able to avoid dropped/repeated
> frames without expensive operations such as resampling the audio to
> match video output rate.
> 
> Rather than add both variants based on the CEA extension short video
> descriptors in do_cea_modes(), add only one variant there. Once all
> the EDID has been fully probed, do a loop over the entire probed mode
> list, during which we add the other variants for all modes that match
> CEA modes. This allows us to match modes that didn't come via the CEA
> short video descriptors. For example one Samsung TV here doesn't have
> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
> timing descriptor.
> 
> Signed-off-by: Ville Syrjälä 
> ---
> A few people requested this. Originally I was a bit opposed to it, but
> when I thought about it a bit more I figured if the audio and video
> clocks come from the same source (or happen to be close enough w/o
> significant drift), this could provide a better A/V sync w/o resampling
> tricks.

Yeah, I think this should be useful for a bunch of people. I've recently
chatted with a few xbmc folks on #irc and one thing they've requested is
mode fine-tuning. For DP we should have plenty of precision, but for HDMI
we'd need to (slightly) frob the vtotal ever so often to compensate. With
some runtime-tuning a la npt we should have perfect a/v sync without any
audio resampling.

Anyway, on the patch:

Reviewed-by: Daniel Vetter 
> 
>  drivers/gpu/drm/drm_edid.c | 102 
> ++---
>  1 file changed, 88 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9e62bbe..e8d17ee 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2321,6 +2321,31 @@ u8 *drm_find_cea_extension(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_find_cea_extension);
>  
> +/*
> + * Calculate the alternate clock for the CEA mode
> + * (60Hz vs. 59.94Hz etc.)
> + */
> +static unsigned int
> +cea_mode_alternate_clock(const struct drm_display_mode *cea_mode)
> +{
> + unsigned int clock = cea_mode->clock;
> +
> + if (cea_mode->vrefresh % 6 != 0)
> + return clock;
> +
> + /*
> +  * edid_cea_modes contains the 59.94Hz
> +  * variant for 240 and 480 line modes,
> +  * and the 60Hz variant otherwise.
> +  */
> + if (cea_mode->vdisplay == 240 || cea_mode->vdisplay == 480)
> + clock = clock * 1001 / 1000;
> + else
> + clock = DIV_ROUND_UP(clock * 1000, 1001);
> +
> + return clock;
> +}
> +
>  /**
>   * drm_match_cea_mode - look for a CEA mode matching given mode
>   * @to_match: display mode
> @@ -2339,21 +2364,9 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>   const struct drm_display_mode *cea_mode = &edid_cea_modes[mode];
>   unsigned int clock1, clock2;
>  
> - clock1 = clock2 = cea_mode->clock;
> -
>   /* Check both 60Hz and 59.94Hz */
> - if (cea_mode->vrefresh % 6 == 0) {
> - /*
> -  * edid_cea_modes contains the 59.94Hz
> -  * variant for 240 and 480 line modes,
> -  * and the 60Hz variant otherwise.
> -  */
> - if (cea_mode->vdisplay == 240 ||
> - cea_mode->vdisplay == 480)
> - clock1 = clock1 * 1001 / 1000;
> - else
> - clock2 = DIV_ROUND_UP(clock2 * 1000, 1001);
> - }
> + clock1 = cea_mode->clock;
> + clock2 = cea_mode_alternate_clock(cea_mode);
>  
>   if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
>KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
> @@ -2364,6 +2377,66 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>  }
>  EXPORT_SYMBOL(drm_match_cea_mode);
>  
> +static int
> +add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *mode, *tmp;
> + LIST_HEAD(list);
> + int modes = 0;
> +
> + /* Don't add CEA modes if the CEA extension block is missing */
> + if (!drm_find_cea_extension(edid))
> + return 0;
> +
> + /*
> +  * Go through all probed modes and create a new mode
> +  * with the alternate clock for certain CEA modes.
> +  */
> + list_for_each_entry(mode, &connector->probed_modes, head) {
> + const struct drm_display_mode *cea_mode;
> + struct drm_display_mode *newmode;
> + u8 cea_mod

Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Lucas Stach]

Am Freitag, den 31.05.2013, 17:29 +0200 schrieb Daniel Vetter:
> On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> > Hello Daniel,
> > 
> > Thanks for your comment.
> > 
> > On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> > > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  
> > > wrote:
> > >> importer private data in dma-buf attachment can be used by importer to
> > >> reimport same dma-buf.
> > >>
> > >> Seung-Woo Kim (2):
> > >>   dma-buf: add importer private data to attachment
> > >>   drm/prime: find gem object from the reimported dma-buf
> > > 
> > > Self-import should already work (at least with the latest refcount
> > > fixes merged). At least the tests to check both re-import on the same
> > > drm fd and on a different all work as expected now.
> > 
> > Currently, prime works well for all case including self-importing,
> > importing, and reimporting as you describe. Just, importing dma-buf from
> > other driver twice with different drm_fd, each import create its own gem
> > object even two import is done for same buffer because prime_priv is in
> > struct drm_file. This means mapping to the device is done also twice.
> > IMHO, these duplicated creations and maps are not necessary if drm can
> > find previous import in different prime_priv.
> 
> Well, that's imo a bug with the other driver. If it doesn't export
> something really simple (e.g. contiguous memory which doesn't require any
> mmio resources at all) it should have a cache of exported dma_buf fds so
> that it hands out the same dma_buf every time.

I agree with the reasoning here.

Though it would be nice to have this "expected driver behavior" put down
somewhere in the documentation. Any volunteers?

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65192

--- Comment #3 from Luzipher  ---
I did as suggested and ran:

R600_HYPERZ=0 /usr/lib/misc/xscreensaver/antmaze

This worked more often, but I could make it crash when using different
screensavers. Using

R600_HYPERZ=0 /usr/bin/xscreensaver-demo

and switching between screensavers crashed as often as without R600_HYPERZ=0.
Also, the screensaver juggler3d crashed twice when exiting the window it ran
in.

R600_DEBUG=sb didn't help either.

I also confirmed that environment variables are working as they should via
setting GALLIUM_HUD.

-- 
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 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

--- Comment #6 from Alexandre Demers  ---
(In reply to comment #4)
> Are you using the default backend + sb or llvm backend + sb?
> 
> Ccing vadimg.

R600_DEBUG=sb is set.

In my build script, I set the following:
baseExec="./autogen.sh --prefix=/usr \
--enable-debug \
--enable-osmesa \
--enable-gbm \
--enable-xvmc \
--enable-vdpau \
--enable-gles1 \
--enable-gles2 \
--enable-openvg \
--enable-xorg \
--enable-xa \
--enable-egl \
--enable-gallium-egl \
--enable-glx-tls \
--enable-texture-float \
--enable-wgl \
--with-gallium-drivers=r600,swrast,svga \
--with-dri-drivers= \
--with-egl-platforms=x11,drm,wayland"

So that would be default + SB, right?

-- 
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 0/7] drm/i915: fbdev mode restoration improvements v2

[ville . syrjala]

Another attempt at restoring the fbdev mode.

Changes from v1:
- Cursors and sprites are disabled permanently (well, until someone
  explicitly re-enabls them). This was actually already the case for
  the old video overlay.
- Since the disabling is now permanent, all extra planes can be
  disabled before the crtc modeset/set_base is performed so there should
  be no extra blinking of the planes

I still left the new fbdev_restore_mode hook in place because I was too
lazy to figure out if I could just disable planes/cursors from drm_fb_helper
directly (i915 would be fine, but other drivers could have issues with it),
and even with i915 we still have to disable the old video overlay, which is
driven via some custom API, and hence can't be disabled from the common code.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/7] drm: Add fb_helper->restore_fbdev_mode hook

[ville . syrjala]

From: Ville Syrjälä 

Drivers may need to turn off overlay planes, cursors, etc. when
restoring the fbdev mode. So allow drivers to provide their own
version of drm_fb_helper_restore_fbdev_mode() that can take care
of such details.

Initially just plug in drm_fb_helper_restore_fbdev_mode for all
drivers.

v2: Add kernel-doc for the new hook

Reviewed-by: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/ast/ast_fb.c  | 1 +
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 +
 drivers/gpu/drm/drm_fb_cma_helper.c   | 1 +
 drivers/gpu/drm/drm_fb_helper.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 +
 drivers/gpu/drm/gma500/framebuffer.c  | 1 +
 drivers/gpu/drm/i915/intel_fb.c   | 1 +
 drivers/gpu/drm/mgag200/mgag200_fb.c  | 1 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 1 +
 drivers/gpu/drm/qxl/qxl_fb.c  | 1 +
 drivers/gpu/drm/radeon/radeon_fb.c| 1 +
 drivers/gpu/drm/udl/udl_fb.c  | 1 +
 include/drm/drm_fb_helper.h   | 2 ++
 14 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index fbc0823..a9cafe2 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -290,6 +290,7 @@ static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };
 
 static void ast_fbdev_destroy(struct drm_device *dev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 3541b56..064a182 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,6 +288,7 @@ static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };
 
 int cirrus_fbdev_init(struct cirrus_device *cdev)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 0b5af7d..f011628 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -330,6 +330,7 @@ err_drm_gem_cma_free_object:
 
 static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };
 
 /**
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0df0ebb..e9af615 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -318,7 +318,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
 
-   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   ret = helper->funcs->restore_fbdev_mode(helper);
if (ret)
error = true;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 68f0045..6ed4065 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -228,6 +228,7 @@ out:
 
 static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };
 
 int exynos_drm_fbdev_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 1534e22..8d7f9c0 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -567,6 +567,7 @@ static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
.gamma_set = psbfb_gamma_set,
.gamma_get = psbfb_gamma_get,
.fb_probe = psbfb_probe,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };
 
 static int psb_fbdev_destroy(struct drm_device *dev, struct psb_fbdev *fbdev)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 6b7c3ca..5fe525a 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -187,6 +187,7 @@ static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.gamma_set = intel_crtc_fb_gamma_set,
.gamma_get = intel_crtc_fb_gamma_get,
.fb_probe = intelfb_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };
 
 static void intel_fbdev_destroy(struct drm_device *dev,
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 5da824c..1720316 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -275,6 +275,7 @@ static struct drm_fb_helper_funcs mga_f

[PATCH 2/7] drm: Add drm_plane_force_disable()

[ville . syrjala]

From: Ville Syrjälä 

drm_plane_force_disable() will forcibly disable the plane even if user
had previously requested the plane to be enabled.

This can be used to force planes to be off when restoring the fbdev
mode.

The code was simply pulled from drm_framebuffer_remove(), which now
calls the new function as well.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_crtc.c | 27 +--
 include/drm/drm_crtc.h |  1 +
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..c65124d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -569,16 +569,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
}
 
list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
-   if (plane->fb == fb) {
-   /* should turn off the crtc */
-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("failed to disable plane with 
busy fb\n");
-   /* disconnect the plane from the fb and crtc: */
-   __drm_framebuffer_unreference(plane->fb);
-   plane->fb = NULL;
-   plane->crtc = NULL;
-   }
+   if (plane->fb == fb)
+   drm_plane_force_disable(plane);
}
drm_modeset_unlock_all(dev);
}
@@ -867,6 +859,21 @@ void drm_plane_cleanup(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_cleanup);
 
+void drm_plane_force_disable(struct drm_plane *plane)
+{
+   int ret;
+
+   /* should turn off the crtc */
+   ret = plane->funcs->disable_plane(plane);
+   if (ret)
+   DRM_ERROR("failed to disable plane with busy fb\n");
+   /* disconnect the plane from the fb and crtc: */
+   __drm_framebuffer_unreference(plane->fb);
+   plane->fb = NULL;
+   plane->crtc = NULL;
+}
+EXPORT_SYMBOL(drm_plane_force_disable);
+
 /**
  * drm_mode_create - create a new display mode
  * @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..db7a885 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -894,6 +894,7 @@ extern int drm_plane_init(struct drm_device *dev,
  const uint32_t *formats, uint32_t format_count,
  bool priv);
 extern void drm_plane_cleanup(struct drm_plane *plane);
+extern void drm_plane_force_disable(struct drm_plane *plane);
 
 extern void drm_encoder_cleanup(struct drm_encoder *encoder);
 
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code

[ville . syrjala]

From: Ville Syrjälä 

plane->enabled is never set, so this code didn't do anything.

Fix the code for sprites by calling the new drm_plane_force_disable()
function. That means the plane will remain off until someone explicitly
turns it back on.

And do the same for cursors and the old video overlays, since we only
want to see the primary plane for fbdev.

v2: Disable sprites/cursors until explicitly re-enabled

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 16 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_fb.c  |  9 ++---
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 944b6d5..1d1a3fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct 
drm_i915_error_state_buf *m,
}
 }
 #endif
+
+void intel_disable_cursors_and_sprites(struct drm_device *dev)
+{
+   struct drm_crtc *crtc;
+   struct drm_plane *plane;
+
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+   intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
+   intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
+   }
+
+   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+   if (plane->fb)
+   drm_plane_force_disable(plane);
+   }
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d0a8c1a..f8e76cf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -800,5 +800,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct 
drm_device *dev,
 extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev,
 enum transcoder pch_transcoder,
 bool enable);
+extern void intel_disable_cursors_and_sprites(struct drm_device *dev);
 
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 5fe525a..b34ccf3 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -293,22 +293,17 @@ void intel_fb_restore_mode(struct drm_device *dev)
 {
int ret;
drm_i915_private_t *dev_priv = dev->dev_private;
-   struct drm_mode_config *config = &dev->mode_config;
-   struct drm_plane *plane;
 
if (INTEL_INFO(dev)->num_pipes == 0)
return;
 
drm_modeset_lock_all(dev);
 
+   intel_disable_cursors_and_sprites(dev);
+
ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
if (ret)
DRM_DEBUG("failed to restore crtc mode\n");
 
-   /* Be sure to shut off any planes that may be active */
-   list_for_each_entry(plane, &config->plane_list, head)
-   if (plane->enabled)
-   plane->funcs->disable_plane(plane);
-
drm_modeset_unlock_all(dev);
 }
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 4/7] drm/i915: Use a custom restore_fbdev_mode hook

[ville . syrjala]

From: Ville Syrjälä 

Disable sprite planes and cursors when restoring the fbdev mode.

Should makes oopses more readable if they're not covered by sprites and
cursors.

v2: Rebased due to changes earlier in the series

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_fb.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index b34ccf3..e8389df 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -183,11 +183,25 @@ out:
return ret;
 }
 
+static bool intel_fb_restore_fbdev_mode(struct drm_fb_helper *helper)
+{
+   struct drm_device *dev = helper->dev;
+   bool ret;
+
+   intel_disable_cursors_and_sprites(dev);
+
+   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   if (ret)
+   DRM_DEBUG("failed to restore crtc mode\n");
+
+   return ret;
+}
+
 static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.gamma_set = intel_crtc_fb_gamma_set,
.gamma_get = intel_crtc_fb_gamma_get,
.fb_probe = intelfb_create,
-   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
+   .restore_fbdev_mode = intel_fb_restore_fbdev_mode,
 };
 
 static void intel_fbdev_destroy(struct drm_device *dev,
@@ -291,7 +305,6 @@ void intel_fb_output_poll_changed(struct drm_device *dev)
 
 void intel_fb_restore_mode(struct drm_device *dev)
 {
-   int ret;
drm_i915_private_t *dev_priv = dev->dev_private;
 
if (INTEL_INFO(dev)->num_pipes == 0)
@@ -299,11 +312,7 @@ void intel_fb_restore_mode(struct drm_device *dev)
 
drm_modeset_lock_all(dev);
 
-   intel_disable_cursors_and_sprites(dev);
-
-   ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
+   intel_fb_restore_fbdev_mode(&dev_priv->fbdev->helper);
 
drm_modeset_unlock_all(dev);
 }
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] drm/i915: Use container_of() in the fbdev code

[ville . syrjala]

From: Ville Syrjälä 

Use container_of() instead of a cast to get struct intel_fbdev
from struct drm_fb_helper.

Also populate the fb_info->par correctly with the drm_fb_helper pointer
instead of the intel_fbdev pointer.

There's no actual functional change since the drm_fb_helper happens to
be the first member inside intel_fbdev.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_fb.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index e8389df..60d0cf6 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -60,8 +60,9 @@ static struct fb_ops intelfb_ops = {
 static int intelfb_create(struct drm_fb_helper *helper,
  struct drm_fb_helper_surface_size *sizes)
 {
-   struct intel_fbdev *ifbdev = (struct intel_fbdev *)helper;
-   struct drm_device *dev = ifbdev->helper.dev;
+   struct intel_fbdev *ifbdev =
+   container_of(helper, struct intel_fbdev, helper);
+   struct drm_device *dev = helper->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct fb_info *info;
struct drm_framebuffer *fb;
@@ -108,7 +109,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unpin;
}
 
-   info->par = ifbdev;
+   info->par = helper;
 
ret = intel_framebuffer_init(dev, &ifbdev->ifb, &mode_cmd, obj);
if (ret)
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/7] drm/i915: s/drm_i915_private_t/struct drm_i915_private/

[ville . syrjala]

From: Ville Syrjälä 

People don't like typedefs these days. Eliminate their use from intel_fb.c.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_fb.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 60d0cf6..ae3a348 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -233,7 +233,7 @@ static void intel_fbdev_destroy(struct drm_device *dev,
 int intel_fbdev_init(struct drm_device *dev)
 {
struct intel_fbdev *ifbdev;
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
int ret;
 
ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
@@ -258,7 +258,7 @@ int intel_fbdev_init(struct drm_device *dev)
 
 void intel_fbdev_initial_config(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
 
/* Due to peculiar init order wrt to hpd handling this is separate. */
drm_fb_helper_initial_config(&dev_priv->fbdev->helper, 32);
@@ -266,7 +266,7 @@ void intel_fbdev_initial_config(struct drm_device *dev)
 
 void intel_fbdev_fini(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
if (!dev_priv->fbdev)
return;
 
@@ -277,7 +277,7 @@ void intel_fbdev_fini(struct drm_device *dev)
 
 void intel_fbdev_set_suspend(struct drm_device *dev, int state)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_fbdev *ifbdev = dev_priv->fbdev;
struct fb_info *info;
 
@@ -300,13 +300,13 @@ MODULE_LICENSE("GPL and additional rights");
 
 void intel_fb_output_poll_changed(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
 }
 
 void intel_fb_restore_mode(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
 
if (INTEL_INFO(dev)->num_pipes == 0)
return;
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 7/7] drm: Remove some unused stuff from drm_plane

[ville . syrjala]

From: Ville Syrjälä 

There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.

v2: Remove all of it from kernel-doc too

Reviewed-by: Laurent Pinchart 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_crtc.c |  2 +-
 include/drm/drm_crtc.h | 11 ---
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c65124d..bbbfb3f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1747,7 +1747,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,
 
plane_resp->plane_id = plane->base.id;
plane_resp->possible_crtcs = plane->possible_crtcs;
-   plane_resp->gamma_size = plane->gamma_size;
+   plane_resp->gamma_size = 0;
 
/*
 * This ioctl is called twice, once to determine how much space is
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index db7a885..3c14b46 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -654,11 +654,7 @@ struct drm_plane_funcs {
  * @format_count: number of formats supported
  * @crtc: currently bound CRTC
  * @fb: currently bound fb
- * @gamma_size: size of gamma table
- * @gamma_store: gamma correction table
- * @enabled: enabled flag
  * @funcs: helper functions
- * @helper_private: storage for drver layer
  * @properties: property tracking for this plane
  */
 struct drm_plane {
@@ -674,14 +670,7 @@ struct drm_plane {
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
 
-   /* CRTC gamma size for reporting to userspace */
-   uint32_t gamma_size;
-   uint16_t *gamma_store;
-
-   bool enabled;
-
const struct drm_plane_funcs *funcs;
-   void *helper_private;
 
struct drm_object_properties properties;
 };
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

--- Comment #7 from Alexandre Demers  ---
(In reply to comment #5)
> Created attachment 80097 [details] [review]
> [PATCH] r600g/sb: fix broken assert
> 
> Attached patch should fix the assert. Does it fix you issues?

Yes, it does.

-- 
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 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

Vadim Girlin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Vadim Girlin  ---
Patch pushed with commit eb4c992ea5e69083d2bc705d2460ce956c5063a7

-- 
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/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Daniel Vetter wrote:

On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrjälä 
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.


Yeah, I think this should be useful for a bunch of people. I've recently
chatted with a few xbmc folks on #irc and one thing they've requested is
mode fine-tuning. For DP we should have plenty of precision, but for HDMI
we'd need to (slightly) frob the vtotal ever so often to compensate. With
some runtime-tuning a la npt we should have perfect a/v sync without any
audio resampling.


Apologies, for jumping in here, but assuming I haven't missed anything 
you've done already: do you have any plans for supporting CEA interlaced 
modes?


That's assuming they actually need any more support - I only know that 
they are slightly wrong for me testing with radeon + my TV - are they 
tested and known to work / not work on intel hw?


The symptom I get is not instantly obvious - the second half of the 
bottom line gets rendered and repeated as the top line.


For me the reason that proper support could in theory be useful, is that 
were there in future a way to sync up properly,  my TV will do a nice 
"free" deinterlace. Even on a fast quad core PC doing one as good on cpu 
is not possible for HD 50i.




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Daniel Vetter]

On Fri, May 31, 2013 at 8:56 PM, Andy Furniss  wrote:
> Daniel Vetter wrote:
>>
>> On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrj...@linux.intel.com
>> wrote:
>>>
>>> From: Ville Syrjälä 
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the video framerate exactly, and the audio and video clocks come
>>> from the same source, you should be able to avoid dropped/repeated
>>> frames without expensive operations such as resampling the audio to
>>> match video output rate.
>>>
>>> Rather than add both variants based on the CEA extension short video
>>> descriptors in do_cea_modes(), add only one variant there. Once all
>>> the EDID has been fully probed, do a loop over the entire probed mode
>>> list, during which we add the other variants for all modes that match
>>> CEA modes. This allows us to match modes that didn't come via the CEA
>>> short video descriptors. For example one Samsung TV here doesn't have
>>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>>> timing descriptor.
>>>
>>> Signed-off-by: Ville Syrjälä 
>>> ---
>>> A few people requested this. Originally I was a bit opposed to it, but
>>> when I thought about it a bit more I figured if the audio and video
>>> clocks come from the same source (or happen to be close enough w/o
>>> significant drift), this could provide a better A/V sync w/o resampling
>>> tricks.
>>
>>
>> Yeah, I think this should be useful for a bunch of people. I've recently
>> chatted with a few xbmc folks on #irc and one thing they've requested is
>> mode fine-tuning. For DP we should have plenty of precision, but for HDMI
>> we'd need to (slightly) frob the vtotal ever so often to compensate. With
>> some runtime-tuning a la npt we should have perfect a/v sync without any
>> audio resampling.
>
>
> Apologies, for jumping in here, but assuming I haven't missed anything
> you've done already: do you have any plans for supporting CEA interlaced
> modes?
>
> That's assuming they actually need any more support - I only know that they
> are slightly wrong for me testing with radeon + my TV - are they tested and
> known to work / not work on intel hw?
>
> The symptom I get is not instantly obvious - the second half of the bottom
> line gets rendered and repeated as the top line.
>
> For me the reason that proper support could in theory be useful, is that
> were there in future a way to sync up properly,  my TV will do a nice "free"
> deinterlace. Even on a fast quad core PC doing one as good on cpu is not
> possible for HD 50i.

Interlaced modes are supported on all intel platforms (except i8xx, hw
can't do it there) and we have full support for CEA modes.
-Daniel
--
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: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 06:21:09PM +0200, Lucas Stach wrote:
> Am Freitag, den 31.05.2013, 17:29 +0200 schrieb Daniel Vetter:
> > On Fri, May 31, 2013 at 07:22:24PM +0900, 김승우 wrote:
> > > Hello Daniel,
> > > 
> > > Thanks for your comment.
> > > 
> > > On 2013년 05월 31일 18:14, Daniel Vetter wrote:
> > > > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim 
> > > >  wrote:
> > > >> importer private data in dma-buf attachment can be used by importer to
> > > >> reimport same dma-buf.
> > > >>
> > > >> Seung-Woo Kim (2):
> > > >>   dma-buf: add importer private data to attachment
> > > >>   drm/prime: find gem object from the reimported dma-buf
> > > > 
> > > > Self-import should already work (at least with the latest refcount
> > > > fixes merged). At least the tests to check both re-import on the same
> > > > drm fd and on a different all work as expected now.
> > > 
> > > Currently, prime works well for all case including self-importing,
> > > importing, and reimporting as you describe. Just, importing dma-buf from
> > > other driver twice with different drm_fd, each import create its own gem
> > > object even two import is done for same buffer because prime_priv is in
> > > struct drm_file. This means mapping to the device is done also twice.
> > > IMHO, these duplicated creations and maps are not necessary if drm can
> > > find previous import in different prime_priv.
> > 
> > Well, that's imo a bug with the other driver. If it doesn't export
> > something really simple (e.g. contiguous memory which doesn't require any
> > mmio resources at all) it should have a cache of exported dma_buf fds so
> > that it hands out the same dma_buf every time.
> 
> I agree with the reasoning here.
> 
> Though it would be nice to have this "expected driver behavior" put down
> somewhere in the documentation. Any volunteers?

I'm not sure how much sense this makes. Imo the importer side is rather
clearly spelled out, everything else is only now shaping up. And even with
the clear interface spec we pretty much have no in-tree dma_buf user who
doesn't cut corners somewhere for one or the other reason. As long the set
of exporters is fairly limited we should be fine for now.
-Daniel
-- 
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

[PATCH] drm/mgag200: Add missing write to index before accessing data register

[Christopher Harvey]

This is a bug fix for some versions of g200se cards while doing
mode-setting.

Signed-off-by: Christopher Harvey 
Tested-by: Julia Lemire 
Acked-by: Julia Lemire Julia Lemire 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index deed0bd..5b1a9e7 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1034,13 +1034,14 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
else
hi_pri_lvl = 5;
 
-   WREG8(0x1fde, 0x06);
-   WREG8(0x1fdf, hi_pri_lvl);
+   WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
+   WREG8(MGAREG_CRTCEXT_DATA, hi_pri_lvl);
} else {
+   WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
if (mdev->reg_1e24 >= 0x01)
-   WREG8(0x1fdf, 0x03);
+   WREG8(MGAREG_CRTCEXT_DATA, 0x03);
else
-   WREG8(0x1fdf, 0x04);
+   WREG8(MGAREG_CRTCEXT_DATA, 0x04);
}
}
return 0;
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/mgag200: Add missing write to index before accessing data register

[Christopher Harvey]

On Fri, May 31 2013, Christopher Harvey  wrote:
> This is a bug fix for some versions of g200se cards while doing
> mode-setting.
>
> Signed-off-by: Christopher Harvey 
> Tested-by: Julia Lemire 
> Acked-by: Julia Lemire Julia Lemire 

hmmm, feel free to delete the extra "Julia Lemire "
before applying. (or I could just re-send)

thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #12 from mombelli.ma...@gmail.com ---
here the error tring to compile TAG 9.1.2 with patch (but error is in a
different file).
This is with autogen.sh without any option and with option ./autogen.sh
--prefix=/usr --sysconfdir=/etc
--with-dri-driverdir=/usr/lib/xorg/modules/dri
--with-gallium-drivers=radeonsi
--with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast
--enable-gallium-llvm --enable-egl --enable-gallium-egl
--with-egl-platforms=x11,drm,wayland --enable-shared-glapi
--enable-gbm --enable-glx-tls --enable-dri --enable-glx
--enable-osmesa --enable-gles1 --enable-gles2
--enable-texture-float --enable-xa --enable-vdpau

gcc (GCC) 4.8.0 20130502 (prerelease)
with latest llvm from http://llvm.org/svn/llvm-project/llvm/trunk/


gallivm/lp_bld_debug.cpp: In member function 'virtual void
raw_debug_ostream::write_impl(const char*, size_t)':
gallivm/lp_bld_debug.cpp:106:40: warning: cast from type 'const char*' to
type 'char*' casts away qualifiers [-Wcast-qual]
   char *lastPtr = (char *)&Ptr[Size];
^
gallivm/lp_bld_debug.cpp: In function 'void lp_disassemble(const void*)':
gallivm/lp_bld_debug.cpp:206:64: error: no matching function for call to
'llvm::Target::createMCAsmInfo(std::string&) const'
OwningPtr AsmInfo(T->createMCAsmInfo(Triple));
^
gallivm/lp_bld_debug.cpp:206:64: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:37:0:
/usr/include/llvm/Support/TargetRegistry.h:298:16: note: llvm::MCAsmInfo*
llvm::Target::createMCAsmInfo(const llvm::MCRegisterInfo&, llvm::StringRef)
const
 MCAsmInfo *createMCAsmInfo(const MCRegisterInfo &MRI,
^
/usr/include/llvm/Support/TargetRegistry.h:298:16: note:   candidate
expects 2 arguments, 1 provided




2013/5/31 

>   *Comment # 11 on bug
> 64776  from Michel
> Dänzer  *
>
> (In reply to comment #10 
> )
> > Should I use newer tag than 1.1?
>
>
> You wrote the problem happens with 9.1.2 but not with 9.1.1, so it's probably
> best to stay within those tags for now.
>
>
> > I think strage that compiling mAster was on error for me.. Normally aren't
> > the pull self-contined?
>
>
> Can't really say anything about that without at least seeing the error.
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #13 from Laurent carlier  ---
(In reply to comment #12)
> here the error tring to compile TAG 9.1.2 with patch (but error is in a
> different file).
> This is with autogen.sh without any option and with option ./autogen.sh
> --prefix=/usr --sysconfdir=/etc
> --with-dri-driverdir=/usr/lib/xorg/modules/dri
> --with-gallium-drivers=radeonsi
> --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast
> --enable-gallium-llvm --enable-egl --enable-gallium-egl
> --with-egl-platforms=x11,drm,wayland --enable-shared-glapi
> --enable-gbm --enable-glx-tls --enable-dri --enable-glx
> --enable-osmesa --enable-gles1 --enable-gles2
> --enable-texture-float --enable-xa --enable-vdpau
> 
> gcc (GCC) 4.8.0 20130502 (prerelease)
> with latest llvm from http://llvm.org/svn/llvm-project/llvm/trunk/
> 

For mesa-9.1.x the proper llvm is here:
http://cgit.freedesktop.org/~tstellar/llvm/

-- 
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 10/15] drm/tilcd: select BACKLIGHT_LCD_SUPPORT

[Arnd Bergmann]

The dependecies for BACKLIGHT_CLASS_DEVICE are defined a bit
strange, but it seems one has to always select both BACKLIGHT_CLASS_DEVICE
and BACKLIGHT_LCD_SUPPORT to avoid this error:

drivers/gpu/drm/tilcdc/tilcdc_panel.c:396:
 undefined reference to `of_find_backlight_by_node'

Cc: Rob Clark 
Cc: dri-devel@lists.freedesktop.org
Cc: Dave Airlie 
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tilcdc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index e461e99..7a4d101 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -6,6 +6,7 @@ config DRM_TILCDC
select DRM_GEM_CMA_HELPER
select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
+   select BACKLIGHT_LCD_SUPPORT
help
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/15] drm/nouveau: use mdelay instead of large udelay constants

[Arnd Bergmann]

ARM cannot handle udelay for more than 2 miliseconds, so we
should use mdelay instead for those.

Signed-off-by: Arnd Bergmann 
Cc: David Airlie 
Cc: Ben Skeggs 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
index d0817d9..ed7415e 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c
@@ -51,7 +51,8 @@ nv50_dac_sense(struct nv50_disp_priv *priv, int or, u32 
loadval)
const u32 doff = (or * 0x800);
int load = -EINVAL;
nv_wr32(priv, 0x61a00c + doff, 0x0010 | loadval);
-   udelay(9500);
+   mdelay(9);
+   udelay(500);
nv_wr32(priv, 0x61a00c + doff, 0x8000);
load = (nv_rd32(priv, 0x61a00c + doff) & 0x3800) >> 27;
nv_wr32(priv, 0x61a00c + doff, 0x);
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/15] Linux-3.10 ARM randconfig fixes

[Arnd Bergmann]

Hi subsystem maintainers,

These are a few patches left over from doing randconfig tests
a couple of weeks ago. Please apply them directly into your
trees unless you see problems. All patches can theoretically
be seen as bug fixes for 3.10, but they are not critical,
so applying them for 3.11 is fine as well.

Arnd

Arnd Bergmann (15):
  irqdomain: export irq_domain_add_simple
  mtd: omap2: allow bulding as a module
  drm/nouveau: use mdelay instead of large udelay constants
  [SCSI] nsp32: use mdelay instead of large udelay constants
  hwrng: bcm2835: fix MODULE_LICENSE tag
  cpuidle: calxeda: select ARM_CPU_SUSPEND
  cpufreq: spear needs cpufreq table
  thermal: cpu_cooling: fix stub function
  drm: always provide debugfs function prototypes
  drm/tilcd: select BACKLIGHT_LCD_SUPPORT
  iwlegacy: il_pm_ops is only provided for PM_SLEEP
  [media] davinci: vpfe_capture needs i2c
  [media] omap3isp: include linux/mm_types.h
  clk: tegra: provide tegra_periph_reset_assert alternative
  OF: remove #ifdef from linux/of_platform.h

 drivers/char/hw_random/bcm2835-rng.c   |  2 +-
 drivers/cpufreq/Kconfig.arm|  1 +
 drivers/cpuidle/Kconfig|  1 +
 drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |  3 ++-
 drivers/gpu/drm/tilcdc/Kconfig |  1 +
 drivers/media/platform/davinci/Kconfig |  3 +++
 drivers/media/platform/omap3isp/ispqueue.h |  1 +
 drivers/mtd/nand/Kconfig   |  2 +-
 drivers/net/wireless/iwlegacy/common.h |  6 +++---
 drivers/scsi/nsp32.c   |  2 +-
 include/drm/drmP.h |  3 +--
 include/linux/clk/tegra.h  |  5 +
 include/linux/cpu_cooling.h|  4 ++--
 include/linux/of_platform.h| 14 +++---
 kernel/irq/irqdomain.c |  1 +
 15 files changed, 27 insertions(+), 22 deletions(-)

Cc: "James E.J. Bottomley" 
Cc: Artem Bityutskiy 
Cc: Dave Airlie 
Cc: David Woodhouse 
Cc: Herbert Xu 
Cc: John W. Linville 
Cc: Laurent Pinchart 
Cc: Mauro Carvalho Chehab 
Cc: Rafael J. Wysocki 
Cc: Rob Clark 
Cc: Rob Herring 
Cc: Russell King 
Cc: Stephen Warren 
Cc: Thomas Gleixner 
Cc: Viresh Kumar 
Cc: cpuf...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-s...@vger.kernel.org


-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=65068

--- Comment #4 from Austin Lund  ---
I'm not sure if this has anything to do with this bug, but the PCI config space
is all messed up when running on the integrated GPU:

# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr::00:02.0
1:DIS: :Off::01:00.0
2:DIS-Audio: :Off::01:00.1
# lspci -s 01:00 -xx
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Whistler [Radeon HD 6600M/6700M/7600M Series] (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Turks/Whistler
HDMI Audio [Radeon HD 6000 Series] (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Maybe this is why suspend/resume doesn't work?  Should the apple gmuxer remove
the radeon device from the list of pci devices when in this state?  (Like
hotplugging?)

-- 
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 54867] bug in r300 compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=54867

--- Comment #1 from Chistopher Krakowiak  ---
Created attachment 80074
  --> https://bugs.freedesktop.org/attachment.cgi?id=80074&action=edit
s/signed/int/

-- 
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/20130531/6cd58909/attachment.html>

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

one qxl 32-bit warning fix, the rest is a bunch of radeon fixes from Alex 
for some issues we've been seeing.

Dave.

The following changes since commit c89b65e7fffef745bdd36c372aa0dea778fecbab:

  qxl: fix Kconfig deps - select FB_DEFERRED_IO (2013-05-28 17:03:37 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 970fa986fadb1165cf38b45b70e98302a3bee497:

  drm/qxl: fix build warnings on 32-bit (2013-05-31 12:45:09 +1000)


Alex Deucher (4):
  drm/radeon: fix typo in cu_per_sh on verde
  drm/radeon: fix card_posted check for newer asics
  drm/radeon: don't check crtcs in card_posted() on cards without DCE
  drm/radeon: narrow scope of Apple re-POST hack

Christian K?nig (1):
  drm/radeon: UVD block on SUMO2 is the same as on SUMO

Dave Airlie (2):
  Merge branch 'drm-fixes-3.10' of 
git://people.freedesktop.org/~agd5f/linux into drm-next
  drm/qxl: fix build warnings on 32-bit

Kleber Sacilotto de Souza (1):
  radeon: use max_bus_speed to activate gen2 speeds

 drivers/gpu/drm/qxl/qxl_ioctl.c|  4 ++--
 drivers/gpu/drm/qxl/qxl_kms.c  |  9 +
 drivers/gpu/drm/radeon/evergreen.c | 10 +++---
 drivers/gpu/drm/radeon/r600.c  |  9 ++---
 drivers/gpu/drm/radeon/radeon_device.c | 27 ---
 drivers/gpu/drm/radeon/rv770.c | 13 +++--
 drivers/gpu/drm/radeon/si.c|  2 +-
 7 files changed, 32 insertions(+), 42 deletions(-)

[PATCH v3 0/9] Clean up write-combining MTRR addition

[Dave Airlie]

On Fri, May 24, 2013 at 4:35 AM, Andy Lutomirski  wrote:
> On Mon, May 13, 2013 at 4:58 PM, Andy Lutomirski  
> wrote:
>> A fair number of drivers (mostly graphics) add write-combining MTRRs.
>> Most ignore errors and most add the MTRR even on PAT systems which don't
>> need to use MTRRs.
>>
>> This series adds new functions arch_phys_wc_{add,del} that, on PAT-less
>> x86 systems with MTRRs, add MTRRs and report errors, and that do nothing
>> otherwise.  (Other architectures, if any, with a similar mechanism could
>> implement them.)
>
> That's the path to upstream for this?  Should it go through drm-next?
> (Sorry for possible noob question -- I've never sent in anything other
> than trivial fixes to drm stuff before.)

I've pulled the v3 series into drm-next, lets see how they go for a while,

I suppose I should try and boot an AGP box with them.

Dave.

[PATCH v3 3/9] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

[Dave Airlie]

On Tue, May 14, 2013 at 9:58 AM, Andy Lutomirski  wrote:
> Previously, DRM_FRAME_BUFFER mappings, as well as DRM_REGISTERS
> mappings with DRM_WRITE_COMBINING set, resulted in an unconditional
> MTRR being added but the actual mappings being created as UC-.
>
> Now these mappings have the MTRR added only if needed, but they will
> be mapped with pgprot_writecombine.
>
> The non-WC DRM_REGISTERS case now uses pgprot_noncached instead of
> hardcoding the bit twiddling.
>
> The DRM_AGP case is unchanged for now.

Just FYI this breaks on powerpc build, I've fixed it up and pushed the
fixed version to
drm-next-staging, I'll push that to drm-next in a couple of days, once
kbuild robot hits it.

Dave.

[PATCHv2 0/7] Miscellaneous fixes to host1x

[Terje Bergström]

On 29.05.2013 13:26, Arto Merilainen wrote:
> This patch series fixes two issues in the host1x driver: First, the
> command buffer validation routine had vulnerabilities that were not
> detected in earlier testing. Second, the return codes of some
> functions were misleading or completely missing. This caused the
> driver to give wrong return codes also to the userspace.
> 
> The series is based on top of 3.10rc3. I have tested the patch series
> on cardhu by running host1x and gr2d test cases (available at [0]).
> I would appreciate any help in testing/reviewing these patches.
> 
> Changes from v1:
>  * Rebased on top of 3.10rc3
>  * Split firewall fixes to smaller patches
>  * Reworked no-reloc case in firewall code. Fix in v1 was not
>sufficient in all cases
>  * Dropped patch "Fix syncpoint wait return value" as it is not
>critical and discussion on it has not yet settled.
>  * Fixed style and whitespace issues
> 
> [0] https://gitorious.org/linux-host1x/libdrm-host1x
> 
> Arto Merilainen (5):
>   gpu: host1x: Check reloc table before usage
>   gpu: host1x: Copy gathers before verification
>   gpu: host1x: Fix memory access in syncpt request
>   gpu: host1x: Fix client_managed type
>   gpu: host1x: Rework CPU syncpoint increment
> 
> Terje Bergstrom (2):
>   gpu: host1x: Check INCR opcode correctly
>   gpu: host1x: Don't reset firewall between gathers
> 
>  drivers/gpu/host1x/dev.h  |   8 +--
>  drivers/gpu/host1x/drm/drm.c  |   3 +-
>  drivers/gpu/host1x/drm/gr2d.c |   2 +-
>  drivers/gpu/host1x/hw/cdma_hw.c   |   2 +-
>  drivers/gpu/host1x/hw/syncpt_hw.c |  12 ++--
>  drivers/gpu/host1x/job.c  | 135 
> +-
>  drivers/gpu/host1x/syncpt.c   |  26 +++-
>  drivers/gpu/host1x/syncpt.h   |  13 ++--
>  8 files changed, 85 insertions(+), 116 deletions(-)
> 

Arto's patches above,

Acked-By: Terje Bergstrom 

Terje

[PATCH] MAINTAINERS: update path for drm tegra driver

[Ying Xue]

Since 4231c6b01af9f0f3eeca4b8d0d87125d78233b41 commit, drm tegra
driver was moved to host1x, however, its correspding entry in
MAINTAINERS is not updated in time.

Signed-off-by: Ying Xue 
---
 MAINTAINERS |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7714c3c..d672968 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2702,7 +2702,7 @@ L:dri-devel at lists.freedesktop.org
 L: linux-tegra at vger.kernel.org
 T: git git://gitorious.org/thierryreding/linux.git
 S: Maintained
-F: drivers/gpu/drm/tegra/
+F: drivers/gpu/host1x/drm/
 F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt

 DSBR100 USB FM RADIO DRIVER
-- 
1.7.9.5

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Seung-Woo Kim]

importer private data in dma-buf attachment can be used by importer to
reimport same dma-buf.

Seung-Woo Kim (2):
  dma-buf: add importer private data to attachment
  drm/prime: find gem object from the reimported dma-buf

 drivers/base/dma-buf.c |   31 
 drivers/gpu/drm/drm_prime.c|   19 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
 drivers/gpu/drm/udl/udl_gem.c  |1 +
 include/linux/dma-buf.h|4 +++
 6 files changed, 52 insertions(+), 5 deletions(-)

-- 
1.7.4.1

[RFC][PATCH 2/2] drm/prime: find gem object from the reimported dma-buf

[Seung-Woo Kim]

Reimported dma-buf can reuse same gem object only when prime import
is done with same drm open context. So prime import is done with
other drm open context, gem object is newly created and mapped even
there is already mapped gem object. To avoid recreating gem object,
importer private data can be used at reimport time if it is assigned
with drm gem object at first import.
This can also remove remapping dma address for the hardware having
its own iommu.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/drm_prime.c|   19 ++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
 drivers/gpu/drm/udl/udl_gem.c  |1 +
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index dcde352..78a3c7d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -294,6 +294,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
}

obj->import_attach = attach;
+   attach->importer_priv = obj;

return obj;

@@ -312,6 +313,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
 {
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
+   struct dma_buf_attachment *attach;
int ret;

dma_buf = dma_buf_get(prime_fd);
@@ -327,11 +329,18 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto out_put;
}

-   /* never seen this one, need to import */
-   obj = dev->driver->gem_prime_import(dev, dma_buf);
-   if (IS_ERR(obj)) {
-   ret = PTR_ERR(obj);
-   goto out_put;
+   attach = dma_buf_get_attachment(dma_buf, dev->dev);
+   if (IS_ERR(attach)) {
+   /* never seen this one, need to import */
+   obj = dev->driver->gem_prime_import(dev, dma_buf);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto out_put;
+   }
+   } else {
+   /* found attachment to same device */
+   obj = attach->importer_priv;
+   drm_gem_object_reference(obj);
}

ret = drm_gem_handle_create(file_priv, obj, handle);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ff7f2a8..268da36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -285,6 +285,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
exynos_gem_obj->buffer = buffer;
buffer->sgt = sgt;
exynos_gem_obj->base.import_attach = attach;
+   attach->importer_priv = &exynos_gem_obj->base;

DRM_DEBUG_PRIME("dma_addr = 0x%x, size = 0x%lx\n", buffer->dma_addr,
buffer->size);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..75ef28c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -297,6 +297,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,

i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops);
obj->base.import_attach = attach;
+   attach->importer_priv = &obj->base;

return &obj->base;

diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index ef034fa..0652db1 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -317,6 +317,7 @@ struct drm_gem_object *udl_gem_prime_import(struct 
drm_device *dev,
}

uobj->base.import_attach = attach;
+   attach->importer_priv = &uobj->base;

return &uobj->base;

-- 
1.7.4.1

[RFC][PATCH 1/2] dma-buf: add importer private data to attachment

[Seung-Woo Kim]

dma-buf attachment has only exporter private data, but importer private data
can be useful for importer especially to re-import the same dma-buf.
To use importer private data in attachment of the device, the function to
search attachment in the attachment list of dma-buf is also added.

Signed-off-by: Seung-Woo Kim 
---
 drivers/base/dma-buf.c  |   31 +++
 include/linux/dma-buf.h |4 
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 08fe897..a1eaaf2 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -259,6 +259,37 @@ err_attach:
 EXPORT_SYMBOL_GPL(dma_buf_attach);

 /**
+ * dma_buf_get_attachment - Get attachment with the device from dma_buf's
+ * attachments list
+ * @dmabuf:[in]buffer to find device from.
+ * @dev:   [in]device to be found.
+ *
+ * Returns struct dma_buf_attachment * attaching the device; may return
+ * negative error codes.
+ *
+ */
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+   struct dma_buf_attachment *attach;
+
+   if (WARN_ON(!dmabuf || !dev))
+   return ERR_PTR(-EINVAL);
+
+   mutex_lock(&dmabuf->lock);
+   list_for_each_entry(attach, &dmabuf->attachments, node) {
+   if (attach->dev == dev) {
+   mutex_unlock(&dmabuf->lock);
+   return attach;
+   }
+   }
+   mutex_unlock(&dmabuf->lock);
+
+   return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
+
+/**
  * dma_buf_detach - Remove the given attachment from dmabuf's attachments list;
  * optionally calls detach() of dma_buf_ops for device-specific detach
  * @dmabuf:[in]buffer to detach from.
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..09cff0f 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -136,6 +136,7 @@ struct dma_buf {
  * @dev: device attached to the buffer.
  * @node: list of dma_buf_attachment.
  * @priv: exporter specific attachment data.
+ * @importer_priv: importer specific attachment data.
  *
  * This structure holds the attachment information between the dma_buf buffer
  * and its user device(s). The list contains one attachment struct per device
@@ -146,6 +147,7 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+   void *importer_priv;
 };

 /**
@@ -164,6 +166,8 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)

 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+   struct device *dev);
 void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);

-- 
1.7.4.1

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  
wrote:
> importer private data in dma-buf attachment can be used by importer to
> reimport same dma-buf.
>
> Seung-Woo Kim (2):
>   dma-buf: add importer private data to attachment
>   drm/prime: find gem object from the reimported dma-buf

Self-import should already work (at least with the latest refcount
fixes merged). At least the tests to check both re-import on the same
drm fd and on a different all work as expected now.

Second, the dma_buf_attachment is _definitely_ the wrong place to do
this. If you need iommu mapping caching, that should happen at a lower
level (i.e. in the map_attachment callback somewhere of the exporter,
that's what the priv field in the attachment is for). Snatching away
the attachement from some random other import is certainly not the way
to go - attachements are _not_ refcounted!
-Daniel

>
>  drivers/base/dma-buf.c |   31 
> 
>  drivers/gpu/drm/drm_prime.c|   19 
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
>  drivers/gpu/drm/udl/udl_gem.c  |1 +
>  include/linux/dma-buf.h|4 +++
>  6 files changed, 52 insertions(+), 5 deletions(-)
>
> --
> 1.7.4.1
>



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #11 from Michel D?nzer  ---
(In reply to comment #10)
> Should I use newer tag than 1.1?

You wrote the problem happens with 9.1.2 but not with 9.1.1, so it's probably
best to stay within those tags for now.


> I think strage that compiling mAster was on error for me.. Normally aren't
> the pull self-contined?

Can't really say anything about that without at least seeing the error.

-- 
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/20130531/255e6ec6/attachment.html>

[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65192

--- Comment #2 from Michel D?nzer  ---
(In reply to comment #2)
> Setting R600_HYPERZ=0 in /etc/environment didn't help.

Are you sure this ended up in the environment of the screensaver hacks? Can you
try e.g.

R600_HYPERZ=0 /usr/lib/xscreensaver/antmaze

manually to see if that works better? Same thing might be interesting for
R600_DEBUG=sb (or R600_LLVM=0, but AFAICT you're building without the r600g
LLVM compiler backend anyway?).

-- 
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/20130531/67575081/attachment.html>

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[김승우]

Hello Daniel,

Thanks for your comment.

On 2013? 05? 31? 18:14, Daniel Vetter wrote:
> On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  
> wrote:
>> importer private data in dma-buf attachment can be used by importer to
>> reimport same dma-buf.
>>
>> Seung-Woo Kim (2):
>>   dma-buf: add importer private data to attachment
>>   drm/prime: find gem object from the reimported dma-buf
> 
> Self-import should already work (at least with the latest refcount
> fixes merged). At least the tests to check both re-import on the same
> drm fd and on a different all work as expected now.

Currently, prime works well for all case including self-importing,
importing, and reimporting as you describe. Just, importing dma-buf from
other driver twice with different drm_fd, each import create its own gem
object even two import is done for same buffer because prime_priv is in
struct drm_file. This means mapping to the device is done also twice.
IMHO, these duplicated creations and maps are not necessary if drm can
find previous import in different prime_priv.

> 
> Second, the dma_buf_attachment is _definitely_ the wrong place to do
> this. If you need iommu mapping caching, that should happen at a lower
> level (i.e. in the map_attachment callback somewhere of the exporter,
> that's what the priv field in the attachment is for). Snatching away
> the attachement from some random other import is certainly not the way
> to go - attachements are _not_ refcounted!

Yes, attachments do not have refcount, so importer should handle and drm
case in my patch, importer private data is gem object and it has, of
course, refcount.

And at current, exporter can not classify map_dma_buf requests of same
importer to same buffer with different attachment because dma_buf_attach
always makes new attachments. To resolve this exporter should search all
different attachment from same importer of dma-buf and it seems more
complex than importer private data to me.

If I misunderstood something, please let me know.

Best Regards,
- Seung-Woo Kim

> -Daniel
> 
>>
>>  drivers/base/dma-buf.c |   31 
>> 
>>  drivers/gpu/drm/drm_prime.c|   19 
>>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
>>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
>>  drivers/gpu/drm/udl/udl_gem.c  |1 +
>>  include/linux/dma-buf.h|4 +++
>>  6 files changed, 52 insertions(+), 5 deletions(-)
>>
>> --
>> 1.7.4.1
>>
> 
> 
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 

-- 
Seung-Woo Kim
Samsung Software R&D Center
--

[PATCH 1/3] drm: Preserve the list head in drm_mode_copy

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Preserve the destination mode's list head in drm_mode_copy. Just
in case someone decides that it's a good idea to overwrite a mode which
happens to be on some list,

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_modes.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a371ff8..ba86316 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -787,16 +787,17 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
  * LOCKING:
  * None.
  *
- * Copy an existing mode into another mode, preserving the object id
- * of the destination mode.
+ * Copy an existing mode into another mode, preserving the object id and
+ * list head of the destination mode.
  */
 void drm_mode_copy(struct drm_display_mode *dst, const struct drm_display_mode 
*src)
 {
int id = dst->base.id;
+   struct list_head head = dst->head;

*dst = *src;
dst->base.id = id;
-   INIT_LIST_HEAD(&dst->head);
+   dst->head = head;
 }
 EXPORT_SYMBOL(drm_mode_copy);

-- 
1.8.1.5

[PATCH 2/3] drm: Add probed modes in probe order

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Keeping the modes in the same order as we probe them makes it a bit
easier to track what's happening.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..f072ac6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -657,7 +657,7 @@ EXPORT_SYMBOL(drm_crtc_cleanup);
 void drm_mode_probed_add(struct drm_connector *connector,
 struct drm_display_mode *mode)
 {
-   list_add(&mode->head, &connector->probed_modes);
+   list_add_tail(&mode->head, &connector->probed_modes);
 }
 EXPORT_SYMBOL(drm_mode_probed_add);

-- 
1.8.1.5

[PATCH 3/3] drm: Sort connector modes based on vrefresh

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Keeping the modes sorted by vrefresh before the pixel clock makes the
mode list somehow more pleasing to the eye.

Signed-off-by: Ville Syrj?l? 
---
This is quite a subjective thing, so if no one else wants it, I'm fine
with dropping it. More of an RFC really...

 drivers/gpu/drm/drm_crtc_helper.c | 5 +++--
 drivers/gpu/drm/drm_modes.c   | 5 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index ed1334e..f554516 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -189,13 +189,14 @@ prune:
if (list_empty(&connector->modes))
return 0;

+   list_for_each_entry(mode, &connector->modes, head)
+   mode->vrefresh = drm_mode_vrefresh(mode);
+
drm_mode_sort(&connector->modes);

DRM_DEBUG_KMS("[CONNECTOR:%d:%s] probed modes :\n", connector->base.id,
drm_get_connector_name(connector));
list_for_each_entry(mode, &connector->modes, head) {
-   mode->vrefresh = drm_mode_vrefresh(mode);
-
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
drm_mode_debug_printmodeline(mode);
}
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ba86316..4370fd4 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1018,6 +1018,11 @@ static int drm_mode_compare(void *priv, struct list_head 
*lh_a, struct list_head
diff = b->hdisplay * b->vdisplay - a->hdisplay * a->vdisplay;
if (diff)
return diff;
+
+   diff = b->vrefresh - a->vrefresh;
+   if (diff)
+   return diff;
+
diff = b->clock - a->clock;
return diff;
 }
-- 
1.8.1.5

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Having both modes can be beneficial for video playback cases. If you can
match the video framerate exactly, and the audio and video clocks come
from the same source, you should be able to avoid dropped/repeated
frames without expensive operations such as resampling the audio to
match video output rate.

Rather than add both variants based on the CEA extension short video
descriptors in do_cea_modes(), add only one variant there. Once all
the EDID has been fully probed, do a loop over the entire probed mode
list, during which we add the other variants for all modes that match
CEA modes. This allows us to match modes that didn't come via the CEA
short video descriptors. For example one Samsung TV here doesn't have
the 640x480-60 mode as a SVD, but instead it's specified via a detailed
timing descriptor.

Signed-off-by: Ville Syrj?l? 
---
A few people requested this. Originally I was a bit opposed to it, but
when I thought about it a bit more I figured if the audio and video
clocks come from the same source (or happen to be close enough w/o
significant drift), this could provide a better A/V sync w/o resampling
tricks.

 drivers/gpu/drm/drm_edid.c | 102 ++---
 1 file changed, 88 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e62bbe..e8d17ee 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2321,6 +2321,31 @@ u8 *drm_find_cea_extension(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_find_cea_extension);

+/*
+ * Calculate the alternate clock for the CEA mode
+ * (60Hz vs. 59.94Hz etc.)
+ */
+static unsigned int
+cea_mode_alternate_clock(const struct drm_display_mode *cea_mode)
+{
+   unsigned int clock = cea_mode->clock;
+
+   if (cea_mode->vrefresh % 6 != 0)
+   return clock;
+
+   /*
+* edid_cea_modes contains the 59.94Hz
+* variant for 240 and 480 line modes,
+* and the 60Hz variant otherwise.
+*/
+   if (cea_mode->vdisplay == 240 || cea_mode->vdisplay == 480)
+   clock = clock * 1001 / 1000;
+   else
+   clock = DIV_ROUND_UP(clock * 1000, 1001);
+
+   return clock;
+}
+
 /**
  * drm_match_cea_mode - look for a CEA mode matching given mode
  * @to_match: display mode
@@ -2339,21 +2364,9 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
const struct drm_display_mode *cea_mode = &edid_cea_modes[mode];
unsigned int clock1, clock2;

-   clock1 = clock2 = cea_mode->clock;
-
/* Check both 60Hz and 59.94Hz */
-   if (cea_mode->vrefresh % 6 == 0) {
-   /*
-* edid_cea_modes contains the 59.94Hz
-* variant for 240 and 480 line modes,
-* and the 60Hz variant otherwise.
-*/
-   if (cea_mode->vdisplay == 240 ||
-   cea_mode->vdisplay == 480)
-   clock1 = clock1 * 1001 / 1000;
-   else
-   clock2 = DIV_ROUND_UP(clock2 * 1000, 1001);
-   }
+   clock1 = cea_mode->clock;
+   clock2 = cea_mode_alternate_clock(cea_mode);

if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
 KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
@@ -2364,6 +2377,66 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
 }
 EXPORT_SYMBOL(drm_match_cea_mode);

+static int
+add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_display_mode *mode, *tmp;
+   LIST_HEAD(list);
+   int modes = 0;
+
+   /* Don't add CEA modes if the CEA extension block is missing */
+   if (!drm_find_cea_extension(edid))
+   return 0;
+
+   /*
+* Go through all probed modes and create a new mode
+* with the alternate clock for certain CEA modes.
+*/
+   list_for_each_entry(mode, &connector->probed_modes, head) {
+   const struct drm_display_mode *cea_mode;
+   struct drm_display_mode *newmode;
+   u8 cea_mode_idx = drm_match_cea_mode(mode) - 1;
+   unsigned int clock1, clock2;
+
+   if (cea_mode_idx >= ARRAY_SIZE(edid_cea_modes))
+   continue;
+
+   cea_mode = &edid_cea_modes[cea_mode_idx];
+
+   clock1 = cea_mode->clock;
+   clock2 = cea_mode_alternate_clock(cea_mode);
+
+   if (clock1 == clock2)
+   continue;
+
+   if (mode->clock != clock1 && mode->clock != clock2)
+   continue;
+
+   newmode = drm_mode_duplicate(dev, cea_mode);
+   if (!newmode)
+   continue;
+
+

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

Andreas Boll  changed:

   What|Removed |Added

 CC||ptpzz at yandex.ru

--- Comment #4 from Andreas Boll  ---
Are you using the default backend + sb or llvm backend + sb?

Ccing vadimg.

-- 
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/20130531/394aa47f/attachment.html>

[PATCH 1/3] drm: Preserve the list head in drm_mode_copy

[Alex Deucher]

On Fri, May 31, 2013 at 8:17 AM,   wrote:
> From: Ville Syrj?l? 
>
> Preserve the destination mode's list head in drm_mode_copy. Just
> in case someone decides that it's a good idea to overwrite a mode which
> happens to be on some list,
>
> Signed-off-by: Ville Syrj?l? 

For the series:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_modes.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index a371ff8..ba86316 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -787,16 +787,17 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
>   * LOCKING:
>   * None.
>   *
> - * Copy an existing mode into another mode, preserving the object id
> - * of the destination mode.
> + * Copy an existing mode into another mode, preserving the object id and
> + * list head of the destination mode.
>   */
>  void drm_mode_copy(struct drm_display_mode *dst, const struct 
> drm_display_mode *src)
>  {
> int id = dst->base.id;
> +   struct list_head head = dst->head;
>
> *dst = *src;
> dst->base.id = id;
> -   INIT_LIST_HEAD(&dst->head);
> +   dst->head = head;
>  }
>  EXPORT_SYMBOL(drm_mode_copy);
>
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"

[Konrad Rzeszutek Wilk]

On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
> 
> > My NV96 does not resume from suspend to ram (the screen stays black, magic
> > sysrq keys do work) with the current linus git kernel, i bisected it to the
> > following commit.
> >
> > drm/nv50/fifo: prevent races between clients updating playlists
> > b5096566f6e1ee2b88324772f020ae9bc0cfa9a0
> >
> > It's not obvious to me how this causes problems, but reverting this commit
> > does solve my problem.
> 
> Same here on my NV86.

And as well on this:

01:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] 
(rev a1)


Ben, any ideas?
> 
> Cheers,
>Sven

[Bug 64475] Slow work and low brightness in Euro Track Simulator II game with HD6850

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64475

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

--- Comment #1 from Andreas Boll  ---
Could you attach a screenshot of the game using the gallium hud

e.g
GALLIUM_HUD="cpu0+cpu1+cpu2+cpu3:100,cpu:100,fps;draw-calls,requested-VRAM+requested-GTT,primitives-generated"

Have you tried to set the cpu-governor to performance?
Are you using the high power state of you gpu?

-- 
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/20130531/3741fc63/attachment-0001.html>

[Bug 65091] power_profile not working for HD5650

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65091

Andreas Boll  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/DRI/R600|DRM/Radeon

-- 
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/20130531/aa1d87d2/attachment.html>

[Bug 59101] New: Gnome shell crashes after sleep mode

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=59101

   Summary: Gnome shell crashes after sleep mode
   Product: Drivers
   Version: 2.5
Kernel Version: 3.9.4-200.fc18.x86_64
  Platform: All
OS/Version: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: cx42net at gmail.com
Regression: No


Hi!

I opened a ticket at Gnome bugzilla about this crash, but it appears to be a
problem regarding my driver from the graphic card :

When I have Gnome-shell that crashes, I can close the session (via the Aww snap
message) and re-open a session, I can then show dmesg which displays everytime
this message :

> [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!

I tried to install the proprietary drivers, but it's not supported by Fedora
18.

For information, I work with a Dual Screen, and I'm using Fedora 18.

If you need any more information, please ask :)

For information, here's the ticket I opened at Gnome :
https://bugzilla.gnome.org/show_bug.cgi?id=701248

Thanks.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

--- Comment #5 from Vadim Girlin  ---
Created attachment 80097
  --> https://bugs.freedesktop.org/attachment.cgi?id=80097&action=edit
[PATCH] r600g/sb: fix broken assert

Attached patch should fix the assert. Does it fix you issues?

-- 
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/20130531/57d69ef0/attachment.html>

[Bug 59101] Gnome shell crashes after sleep mode

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=59101


Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com




--- Comment #1 from Alex Deucher   2013-05-31 
13:58:59 ---
This may be a duplicate of this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=61182
Please attach your xorg log and dmesg output.  What version of mesa are you
using?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
> Hello Daniel,
> 
> Thanks for your comment.
> 
> On 2013? 05? 31? 18:14, Daniel Vetter wrote:
> > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  
> > wrote:
> >> importer private data in dma-buf attachment can be used by importer to
> >> reimport same dma-buf.
> >>
> >> Seung-Woo Kim (2):
> >>   dma-buf: add importer private data to attachment
> >>   drm/prime: find gem object from the reimported dma-buf
> > 
> > Self-import should already work (at least with the latest refcount
> > fixes merged). At least the tests to check both re-import on the same
> > drm fd and on a different all work as expected now.
> 
> Currently, prime works well for all case including self-importing,
> importing, and reimporting as you describe. Just, importing dma-buf from
> other driver twice with different drm_fd, each import create its own gem
> object even two import is done for same buffer because prime_priv is in
> struct drm_file. This means mapping to the device is done also twice.
> IMHO, these duplicated creations and maps are not necessary if drm can
> find previous import in different prime_priv.

Well, that's imo a bug with the other driver. If it doesn't export
something really simple (e.g. contiguous memory which doesn't require any
mmio resources at all) it should have a cache of exported dma_buf fds so
that it hands out the same dma_buf every time.

Or it needs to be more clever in it's dma_buf_attachment_map functions and
lookup up a pre-existing iommu mapping.

But dealing with this in the importer is just broken.

> > Second, the dma_buf_attachment is _definitely_ the wrong place to do
> > this. If you need iommu mapping caching, that should happen at a lower
> > level (i.e. in the map_attachment callback somewhere of the exporter,
> > that's what the priv field in the attachment is for). Snatching away
> > the attachement from some random other import is certainly not the way
> > to go - attachements are _not_ refcounted!
> 
> Yes, attachments do not have refcount, so importer should handle and drm
> case in my patch, importer private data is gem object and it has, of
> course, refcount.
> 
> And at current, exporter can not classify map_dma_buf requests of same
> importer to same buffer with different attachment because dma_buf_attach
> always makes new attachments. To resolve this exporter should search all
> different attachment from same importer of dma-buf and it seems more
> complex than importer private data to me.
> 
> If I misunderstood something, please let me know.

Like I've said above, just fix this in the exporter. If an importer sees
two different dma_bufs it can very well presume that it those two indeed
point to different backing storage.

This will be even more important if we attach fences two dma_bufs. If your
broken exporter creates multiple dma_bufs each one of them will have their
own fences attached, leading to a complete disasters. Ok, strictly
speaking if you keep the same reservation pointer for each dma_buf it'll
work, but that's just a detail of how you solve this in the exporter.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Daniel Vetter]

On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrj?l? 
> 
> Having both modes can be beneficial for video playback cases. If you can
> match the video framerate exactly, and the audio and video clocks come
> from the same source, you should be able to avoid dropped/repeated
> frames without expensive operations such as resampling the audio to
> match video output rate.
> 
> Rather than add both variants based on the CEA extension short video
> descriptors in do_cea_modes(), add only one variant there. Once all
> the EDID has been fully probed, do a loop over the entire probed mode
> list, during which we add the other variants for all modes that match
> CEA modes. This allows us to match modes that didn't come via the CEA
> short video descriptors. For example one Samsung TV here doesn't have
> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
> timing descriptor.
> 
> Signed-off-by: Ville Syrj?l? 
> ---
> A few people requested this. Originally I was a bit opposed to it, but
> when I thought about it a bit more I figured if the audio and video
> clocks come from the same source (or happen to be close enough w/o
> significant drift), this could provide a better A/V sync w/o resampling
> tricks.

Yeah, I think this should be useful for a bunch of people. I've recently
chatted with a few xbmc folks on #irc and one thing they've requested is
mode fine-tuning. For DP we should have plenty of precision, but for HDMI
we'd need to (slightly) frob the vtotal ever so often to compensate. With
some runtime-tuning a la npt we should have perfect a/v sync without any
audio resampling.

Anyway, on the patch:

Reviewed-by: Daniel Vetter 
> 
>  drivers/gpu/drm/drm_edid.c | 102 
> ++---
>  1 file changed, 88 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9e62bbe..e8d17ee 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2321,6 +2321,31 @@ u8 *drm_find_cea_extension(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_find_cea_extension);
>  
> +/*
> + * Calculate the alternate clock for the CEA mode
> + * (60Hz vs. 59.94Hz etc.)
> + */
> +static unsigned int
> +cea_mode_alternate_clock(const struct drm_display_mode *cea_mode)
> +{
> + unsigned int clock = cea_mode->clock;
> +
> + if (cea_mode->vrefresh % 6 != 0)
> + return clock;
> +
> + /*
> +  * edid_cea_modes contains the 59.94Hz
> +  * variant for 240 and 480 line modes,
> +  * and the 60Hz variant otherwise.
> +  */
> + if (cea_mode->vdisplay == 240 || cea_mode->vdisplay == 480)
> + clock = clock * 1001 / 1000;
> + else
> + clock = DIV_ROUND_UP(clock * 1000, 1001);
> +
> + return clock;
> +}
> +
>  /**
>   * drm_match_cea_mode - look for a CEA mode matching given mode
>   * @to_match: display mode
> @@ -2339,21 +2364,9 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>   const struct drm_display_mode *cea_mode = &edid_cea_modes[mode];
>   unsigned int clock1, clock2;
>  
> - clock1 = clock2 = cea_mode->clock;
> -
>   /* Check both 60Hz and 59.94Hz */
> - if (cea_mode->vrefresh % 6 == 0) {
> - /*
> -  * edid_cea_modes contains the 59.94Hz
> -  * variant for 240 and 480 line modes,
> -  * and the 60Hz variant otherwise.
> -  */
> - if (cea_mode->vdisplay == 240 ||
> - cea_mode->vdisplay == 480)
> - clock1 = clock1 * 1001 / 1000;
> - else
> - clock2 = DIV_ROUND_UP(clock2 * 1000, 1001);
> - }
> + clock1 = cea_mode->clock;
> + clock2 = cea_mode_alternate_clock(cea_mode);
>  
>   if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
>KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
> @@ -2364,6 +2377,66 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
> *to_match)
>  }
>  EXPORT_SYMBOL(drm_match_cea_mode);
>  
> +static int
> +add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *mode, *tmp;
> + LIST_HEAD(list);
> + int modes = 0;
> +
> + /* Don't add CEA modes if the CEA extension block is missing */
> + if (!drm_find_cea_extension(edid))
> + return 0;
> +
> + /*
> +  * Go through all probed modes and create a new mode
> +  * with the alternate clock for certain CEA modes.
> +  */
> + list_for_each_entry(mode, &connector->probed_modes, head) {
> + const struct drm_display_mode *cea_mode;
> + struct drm_display_mode *newmode;
> + u8 cea

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Lucas Stach]

Am Freitag, den 31.05.2013, 17:29 +0200 schrieb Daniel Vetter:
> On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
> > Hello Daniel,
> > 
> > Thanks for your comment.
> > 
> > On 2013? 05? 31? 18:14, Daniel Vetter wrote:
> > > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  > > samsung.com> wrote:
> > >> importer private data in dma-buf attachment can be used by importer to
> > >> reimport same dma-buf.
> > >>
> > >> Seung-Woo Kim (2):
> > >>   dma-buf: add importer private data to attachment
> > >>   drm/prime: find gem object from the reimported dma-buf
> > > 
> > > Self-import should already work (at least with the latest refcount
> > > fixes merged). At least the tests to check both re-import on the same
> > > drm fd and on a different all work as expected now.
> > 
> > Currently, prime works well for all case including self-importing,
> > importing, and reimporting as you describe. Just, importing dma-buf from
> > other driver twice with different drm_fd, each import create its own gem
> > object even two import is done for same buffer because prime_priv is in
> > struct drm_file. This means mapping to the device is done also twice.
> > IMHO, these duplicated creations and maps are not necessary if drm can
> > find previous import in different prime_priv.
> 
> Well, that's imo a bug with the other driver. If it doesn't export
> something really simple (e.g. contiguous memory which doesn't require any
> mmio resources at all) it should have a cache of exported dma_buf fds so
> that it hands out the same dma_buf every time.

I agree with the reasoning here.

Though it would be nice to have this "expected driver behavior" put down
somewhere in the documentation. Any volunteers?

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 65192] [r600g] Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65192

--- Comment #3 from Luzipher  ---
I did as suggested and ran:

R600_HYPERZ=0 /usr/lib/misc/xscreensaver/antmaze

This worked more often, but I could make it crash when using different
screensavers. Using

R600_HYPERZ=0 /usr/bin/xscreensaver-demo

and switching between screensavers crashed as often as without R600_HYPERZ=0.
Also, the screensaver juggler3d crashed twice when exiting the window it ran
in.

R600_DEBUG=sb didn't help either.

I also confirmed that environment variables are working as they should via
setting GALLIUM_HUD.

-- 
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/20130531/687483a0/attachment.html>

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

--- Comment #6 from Alexandre Demers  ---
(In reply to comment #4)
> Are you using the default backend + sb or llvm backend + sb?
> 
> Ccing vadimg.

R600_DEBUG=sb is set.

In my build script, I set the following:
baseExec="./autogen.sh --prefix=/usr \
--enable-debug \
--enable-osmesa \
--enable-gbm \
--enable-xvmc \
--enable-vdpau \
--enable-gles1 \
--enable-gles2 \
--enable-openvg \
--enable-xorg \
--enable-xa \
--enable-egl \
--enable-gallium-egl \
--enable-glx-tls \
--enable-texture-float \
--enable-wgl \
--with-gallium-drivers=r600,swrast,svga \
--with-dri-drivers= \
--with-egl-platforms=x11,drm,wayland"

So that would be default + SB, right?

-- 
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/20130531/4e1b167c/attachment.html>

[PATCH 0/7] drm/i915: fbdev mode restoration improvements v2

[ville.syrj...@linux.intel.com]

Another attempt at restoring the fbdev mode.

Changes from v1:
- Cursors and sprites are disabled permanently (well, until someone
  explicitly re-enabls them). This was actually already the case for
  the old video overlay.
- Since the disabling is now permanent, all extra planes can be
  disabled before the crtc modeset/set_base is performed so there should
  be no extra blinking of the planes

I still left the new fbdev_restore_mode hook in place because I was too
lazy to figure out if I could just disable planes/cursors from drm_fb_helper
directly (i915 would be fine, but other drivers could have issues with it),
and even with i915 we still have to disable the old video overlay, which is
driven via some custom API, and hence can't be disabled from the common code.

[PATCH v2 1/7] drm: Add fb_helper->restore_fbdev_mode hook

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Drivers may need to turn off overlay planes, cursors, etc. when
restoring the fbdev mode. So allow drivers to provide their own
version of drm_fb_helper_restore_fbdev_mode() that can take care
of such details.

Initially just plug in drm_fb_helper_restore_fbdev_mode for all
drivers.

v2: Add kernel-doc for the new hook

Reviewed-by: Laurent Pinchart 
Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/ast/ast_fb.c  | 1 +
 drivers/gpu/drm/cirrus/cirrus_fbdev.c | 1 +
 drivers/gpu/drm/drm_fb_cma_helper.c   | 1 +
 drivers/gpu/drm/drm_fb_helper.c   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 +
 drivers/gpu/drm/gma500/framebuffer.c  | 1 +
 drivers/gpu/drm/i915/intel_fb.c   | 1 +
 drivers/gpu/drm/mgag200/mgag200_fb.c  | 1 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c  | 1 +
 drivers/gpu/drm/qxl/qxl_fb.c  | 1 +
 drivers/gpu/drm/radeon/radeon_fb.c| 1 +
 drivers/gpu/drm/udl/udl_fb.c  | 1 +
 include/drm/drm_fb_helper.h   | 2 ++
 14 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index fbc0823..a9cafe2 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -290,6 +290,7 @@ static struct drm_fb_helper_funcs ast_fb_helper_funcs = {
.gamma_set = ast_fb_gamma_set,
.gamma_get = ast_fb_gamma_get,
.fb_probe = astfb_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };

 static void ast_fbdev_destroy(struct drm_device *dev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 3541b56..064a182 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -288,6 +288,7 @@ static struct drm_fb_helper_funcs cirrus_fb_helper_funcs = {
.gamma_set = cirrus_crtc_fb_gamma_set,
.gamma_get = cirrus_crtc_fb_gamma_get,
.fb_probe = cirrusfb_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };

 int cirrus_fbdev_init(struct cirrus_device *cdev)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 0b5af7d..f011628 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -330,6 +330,7 @@ err_drm_gem_cma_free_object:

 static struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
.fb_probe = drm_fbdev_cma_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };

 /**
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0df0ebb..e9af615 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -318,7 +318,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;

-   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   ret = helper->funcs->restore_fbdev_mode(helper);
if (ret)
error = true;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 68f0045..6ed4065 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -228,6 +228,7 @@ out:

 static struct drm_fb_helper_funcs exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };

 int exynos_drm_fbdev_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 1534e22..8d7f9c0 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -567,6 +567,7 @@ static struct drm_fb_helper_funcs psb_fb_helper_funcs = {
.gamma_set = psbfb_gamma_set,
.gamma_get = psbfb_gamma_get,
.fb_probe = psbfb_probe,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };

 static int psb_fbdev_destroy(struct drm_device *dev, struct psb_fbdev *fbdev)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 6b7c3ca..5fe525a 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -187,6 +187,7 @@ static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.gamma_set = intel_crtc_fb_gamma_set,
.gamma_get = intel_crtc_fb_gamma_get,
.fb_probe = intelfb_create,
+   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
 };

 static void intel_fbdev_destroy(struct drm_device *dev,
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 5da824c..1720316 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -275,6 +275,7 @@ static struct drm_fb_helper_funcs mga_fb_helper_

[PATCH 2/7] drm: Add drm_plane_force_disable()

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

drm_plane_force_disable() will forcibly disable the plane even if user
had previously requested the plane to be enabled.

This can be used to force planes to be off when restoring the fbdev
mode.

The code was simply pulled from drm_framebuffer_remove(), which now
calls the new function as well.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c | 27 +--
 include/drm/drm_crtc.h |  1 +
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..c65124d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -569,16 +569,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
}

list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
-   if (plane->fb == fb) {
-   /* should turn off the crtc */
-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("failed to disable plane with 
busy fb\n");
-   /* disconnect the plane from the fb and crtc: */
-   __drm_framebuffer_unreference(plane->fb);
-   plane->fb = NULL;
-   plane->crtc = NULL;
-   }
+   if (plane->fb == fb)
+   drm_plane_force_disable(plane);
}
drm_modeset_unlock_all(dev);
}
@@ -867,6 +859,21 @@ void drm_plane_cleanup(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_cleanup);

+void drm_plane_force_disable(struct drm_plane *plane)
+{
+   int ret;
+
+   /* should turn off the crtc */
+   ret = plane->funcs->disable_plane(plane);
+   if (ret)
+   DRM_ERROR("failed to disable plane with busy fb\n");
+   /* disconnect the plane from the fb and crtc: */
+   __drm_framebuffer_unreference(plane->fb);
+   plane->fb = NULL;
+   plane->crtc = NULL;
+}
+EXPORT_SYMBOL(drm_plane_force_disable);
+
 /**
  * drm_mode_create - create a new display mode
  * @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..db7a885 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -894,6 +894,7 @@ extern int drm_plane_init(struct drm_device *dev,
  const uint32_t *formats, uint32_t format_count,
  bool priv);
 extern void drm_plane_cleanup(struct drm_plane *plane);
+extern void drm_plane_force_disable(struct drm_plane *plane);

 extern void drm_encoder_cleanup(struct drm_encoder *encoder);

-- 
1.8.1.5

[PATCH v2 3/7] drm/i915: Fix fbdev sprite disable code

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

plane->enabled is never set, so this code didn't do anything.

Fix the code for sprites by calling the new drm_plane_force_disable()
function. That means the plane will remain off until someone explicitly
turns it back on.

And do the same for cursors and the old video overlays, since we only
want to see the primary plane for fbdev.

v2: Disable sprites/cursors until explicitly re-enabled

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_display.c | 16 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_fb.c  |  9 ++---
 3 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 944b6d5..1d1a3fd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9842,3 +9842,19 @@ intel_display_print_error_state(struct 
drm_i915_error_state_buf *m,
}
 }
 #endif
+
+void intel_disable_cursors_and_sprites(struct drm_device *dev)
+{
+   struct drm_crtc *crtc;
+   struct drm_plane *plane;
+
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+   intel_crtc_dpms_overlay(to_intel_crtc(crtc), false);
+   intel_crtc_cursor_set(crtc, NULL, 0, 0, 0);
+   }
+
+   list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+   if (plane->fb)
+   drm_plane_force_disable(plane);
+   }
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d0a8c1a..f8e76cf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -800,5 +800,6 @@ extern bool intel_set_cpu_fifo_underrun_reporting(struct 
drm_device *dev,
 extern bool intel_set_pch_fifo_underrun_reporting(struct drm_device *dev,
 enum transcoder pch_transcoder,
 bool enable);
+extern void intel_disable_cursors_and_sprites(struct drm_device *dev);

 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 5fe525a..b34ccf3 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -293,22 +293,17 @@ void intel_fb_restore_mode(struct drm_device *dev)
 {
int ret;
drm_i915_private_t *dev_priv = dev->dev_private;
-   struct drm_mode_config *config = &dev->mode_config;
-   struct drm_plane *plane;

if (INTEL_INFO(dev)->num_pipes == 0)
return;

drm_modeset_lock_all(dev);

+   intel_disable_cursors_and_sprites(dev);
+
ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
if (ret)
DRM_DEBUG("failed to restore crtc mode\n");

-   /* Be sure to shut off any planes that may be active */
-   list_for_each_entry(plane, &config->plane_list, head)
-   if (plane->enabled)
-   plane->funcs->disable_plane(plane);
-
drm_modeset_unlock_all(dev);
 }
-- 
1.8.1.5

[PATCH v2 4/7] drm/i915: Use a custom restore_fbdev_mode hook

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Disable sprite planes and cursors when restoring the fbdev mode.

Should makes oopses more readable if they're not covered by sprites and
cursors.

v2: Rebased due to changes earlier in the series

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_fb.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index b34ccf3..e8389df 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -183,11 +183,25 @@ out:
return ret;
 }

+static bool intel_fb_restore_fbdev_mode(struct drm_fb_helper *helper)
+{
+   struct drm_device *dev = helper->dev;
+   bool ret;
+
+   intel_disable_cursors_and_sprites(dev);
+
+   ret = drm_fb_helper_restore_fbdev_mode(helper);
+   if (ret)
+   DRM_DEBUG("failed to restore crtc mode\n");
+
+   return ret;
+}
+
 static struct drm_fb_helper_funcs intel_fb_helper_funcs = {
.gamma_set = intel_crtc_fb_gamma_set,
.gamma_get = intel_crtc_fb_gamma_get,
.fb_probe = intelfb_create,
-   .restore_fbdev_mode = drm_fb_helper_restore_fbdev_mode,
+   .restore_fbdev_mode = intel_fb_restore_fbdev_mode,
 };

 static void intel_fbdev_destroy(struct drm_device *dev,
@@ -291,7 +305,6 @@ void intel_fb_output_poll_changed(struct drm_device *dev)

 void intel_fb_restore_mode(struct drm_device *dev)
 {
-   int ret;
drm_i915_private_t *dev_priv = dev->dev_private;

if (INTEL_INFO(dev)->num_pipes == 0)
@@ -299,11 +312,7 @@ void intel_fb_restore_mode(struct drm_device *dev)

drm_modeset_lock_all(dev);

-   intel_disable_cursors_and_sprites(dev);
-
-   ret = drm_fb_helper_restore_fbdev_mode(&dev_priv->fbdev->helper);
-   if (ret)
-   DRM_DEBUG("failed to restore crtc mode\n");
+   intel_fb_restore_fbdev_mode(&dev_priv->fbdev->helper);

drm_modeset_unlock_all(dev);
 }
-- 
1.8.1.5

[PATCH 5/7] drm/i915: Use container_of() in the fbdev code

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Use container_of() instead of a cast to get struct intel_fbdev
from struct drm_fb_helper.

Also populate the fb_info->par correctly with the drm_fb_helper pointer
instead of the intel_fbdev pointer.

There's no actual functional change since the drm_fb_helper happens to
be the first member inside intel_fbdev.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_fb.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index e8389df..60d0cf6 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -60,8 +60,9 @@ static struct fb_ops intelfb_ops = {
 static int intelfb_create(struct drm_fb_helper *helper,
  struct drm_fb_helper_surface_size *sizes)
 {
-   struct intel_fbdev *ifbdev = (struct intel_fbdev *)helper;
-   struct drm_device *dev = ifbdev->helper.dev;
+   struct intel_fbdev *ifbdev =
+   container_of(helper, struct intel_fbdev, helper);
+   struct drm_device *dev = helper->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct fb_info *info;
struct drm_framebuffer *fb;
@@ -108,7 +109,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
goto out_unpin;
}

-   info->par = ifbdev;
+   info->par = helper;

ret = intel_framebuffer_init(dev, &ifbdev->ifb, &mode_cmd, obj);
if (ret)
-- 
1.8.1.5

[PATCH 6/7] drm/i915: s/drm_i915_private_t/struct drm_i915_private/

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

People don't like typedefs these days. Eliminate their use from intel_fb.c.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_fb.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 60d0cf6..ae3a348 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -233,7 +233,7 @@ static void intel_fbdev_destroy(struct drm_device *dev,
 int intel_fbdev_init(struct drm_device *dev)
 {
struct intel_fbdev *ifbdev;
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
int ret;

ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
@@ -258,7 +258,7 @@ int intel_fbdev_init(struct drm_device *dev)

 void intel_fbdev_initial_config(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;

/* Due to peculiar init order wrt to hpd handling this is separate. */
drm_fb_helper_initial_config(&dev_priv->fbdev->helper, 32);
@@ -266,7 +266,7 @@ void intel_fbdev_initial_config(struct drm_device *dev)

 void intel_fbdev_fini(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
if (!dev_priv->fbdev)
return;

@@ -277,7 +277,7 @@ void intel_fbdev_fini(struct drm_device *dev)

 void intel_fbdev_set_suspend(struct drm_device *dev, int state)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_fbdev *ifbdev = dev_priv->fbdev;
struct fb_info *info;

@@ -300,13 +300,13 @@ MODULE_LICENSE("GPL and additional rights");

 void intel_fb_output_poll_changed(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;
drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
 }

 void intel_fb_restore_mode(struct drm_device *dev)
 {
-   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct drm_i915_private *dev_priv = dev->dev_private;

if (INTEL_INFO(dev)->num_pipes == 0)
return;
-- 
1.8.1.5

[PATCH v2 7/7] drm: Remove some unused stuff from drm_plane

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

There's a bunch of unused members inside drm_plane, bloating the size of
the structure needlessly. Eliminate them.

v2: Remove all of it from kernel-doc too

Reviewed-by: Laurent Pinchart 
Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_crtc.c |  2 +-
 include/drm/drm_crtc.h | 11 ---
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c65124d..bbbfb3f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1747,7 +1747,7 @@ int drm_mode_getplane(struct drm_device *dev, void *data,

plane_resp->plane_id = plane->base.id;
plane_resp->possible_crtcs = plane->possible_crtcs;
-   plane_resp->gamma_size = plane->gamma_size;
+   plane_resp->gamma_size = 0;

/*
 * This ioctl is called twice, once to determine how much space is
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index db7a885..3c14b46 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -654,11 +654,7 @@ struct drm_plane_funcs {
  * @format_count: number of formats supported
  * @crtc: currently bound CRTC
  * @fb: currently bound fb
- * @gamma_size: size of gamma table
- * @gamma_store: gamma correction table
- * @enabled: enabled flag
  * @funcs: helper functions
- * @helper_private: storage for drver layer
  * @properties: property tracking for this plane
  */
 struct drm_plane {
@@ -674,14 +670,7 @@ struct drm_plane {
struct drm_crtc *crtc;
struct drm_framebuffer *fb;

-   /* CRTC gamma size for reporting to userspace */
-   uint32_t gamma_size;
-   uint16_t *gamma_store;
-
-   bool enabled;
-
const struct drm_plane_funcs *funcs;
-   void *helper_private;

struct drm_object_properties properties;
 };
-- 
1.8.1.5

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

--- Comment #7 from Alexandre Demers  ---
(In reply to comment #5)
> Created attachment 80097 [details] [review]
> [PATCH] r600g/sb: fix broken assert
> 
> Attached patch should fix the assert. Does it fix you issues?

Yes, it does.

-- 
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/20130531/0828ab14/attachment.html>

[Bug 65193] [bisected] r600g, can't launch Gnome Shell and KDE since mesa updated to 5de41575a127eb8a6a0fe5c71a73b372f9b89f53

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65193

Vadim Girlin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Vadim Girlin  ---
Patch pushed with commit eb4c992ea5e69083d2bc705d2460ce956c5063a7

-- 
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/20130531/2476f6b7/attachment.html>

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Andy Furniss]

Daniel Vetter wrote:
> On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrjala at linux.intel.com 
> wrote:
>> From: Ville Syrj?l? 
>>
>> Having both modes can be beneficial for video playback cases. If you can
>> match the video framerate exactly, and the audio and video clocks come
>> from the same source, you should be able to avoid dropped/repeated
>> frames without expensive operations such as resampling the audio to
>> match video output rate.
>>
>> Rather than add both variants based on the CEA extension short video
>> descriptors in do_cea_modes(), add only one variant there. Once all
>> the EDID has been fully probed, do a loop over the entire probed mode
>> list, during which we add the other variants for all modes that match
>> CEA modes. This allows us to match modes that didn't come via the CEA
>> short video descriptors. For example one Samsung TV here doesn't have
>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>> timing descriptor.
>>
>> Signed-off-by: Ville Syrj?l? 
>> ---
>> A few people requested this. Originally I was a bit opposed to it, but
>> when I thought about it a bit more I figured if the audio and video
>> clocks come from the same source (or happen to be close enough w/o
>> significant drift), this could provide a better A/V sync w/o resampling
>> tricks.
>
> Yeah, I think this should be useful for a bunch of people. I've recently
> chatted with a few xbmc folks on #irc and one thing they've requested is
> mode fine-tuning. For DP we should have plenty of precision, but for HDMI
> we'd need to (slightly) frob the vtotal ever so often to compensate. With
> some runtime-tuning a la npt we should have perfect a/v sync without any
> audio resampling.

Apologies, for jumping in here, but assuming I haven't missed anything 
you've done already: do you have any plans for supporting CEA interlaced 
modes?

That's assuming they actually need any more support - I only know that 
they are slightly wrong for me testing with radeon + my TV - are they 
tested and known to work / not work on intel hw?

The symptom I get is not instantly obvious - the second half of the 
bottom line gets rendered and repeated as the top line.

For me the reason that proper support could in theory be useful, is that 
were there in future a way to sync up properly,  my TV will do a nice 
"free" deinterlace. Even on a fast quad core PC doing one as good on cpu 
is not possible for HD 50i.

[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list

[Daniel Vetter]

On Fri, May 31, 2013 at 8:56 PM, Andy Furniss  wrote:
> Daniel Vetter wrote:
>>
>> On Fri, May 31, 2013 at 03:23:41PM +0300, ville.syrjala at linux.intel.com
>> wrote:
>>>
>>> From: Ville Syrj?l? 
>>>
>>> Having both modes can be beneficial for video playback cases. If you can
>>> match the video framerate exactly, and the audio and video clocks come
>>> from the same source, you should be able to avoid dropped/repeated
>>> frames without expensive operations such as resampling the audio to
>>> match video output rate.
>>>
>>> Rather than add both variants based on the CEA extension short video
>>> descriptors in do_cea_modes(), add only one variant there. Once all
>>> the EDID has been fully probed, do a loop over the entire probed mode
>>> list, during which we add the other variants for all modes that match
>>> CEA modes. This allows us to match modes that didn't come via the CEA
>>> short video descriptors. For example one Samsung TV here doesn't have
>>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed
>>> timing descriptor.
>>>
>>> Signed-off-by: Ville Syrj?l? 
>>> ---
>>> A few people requested this. Originally I was a bit opposed to it, but
>>> when I thought about it a bit more I figured if the audio and video
>>> clocks come from the same source (or happen to be close enough w/o
>>> significant drift), this could provide a better A/V sync w/o resampling
>>> tricks.
>>
>>
>> Yeah, I think this should be useful for a bunch of people. I've recently
>> chatted with a few xbmc folks on #irc and one thing they've requested is
>> mode fine-tuning. For DP we should have plenty of precision, but for HDMI
>> we'd need to (slightly) frob the vtotal ever so often to compensate. With
>> some runtime-tuning a la npt we should have perfect a/v sync without any
>> audio resampling.
>
>
> Apologies, for jumping in here, but assuming I haven't missed anything
> you've done already: do you have any plans for supporting CEA interlaced
> modes?
>
> That's assuming they actually need any more support - I only know that they
> are slightly wrong for me testing with radeon + my TV - are they tested and
> known to work / not work on intel hw?
>
> The symptom I get is not instantly obvious - the second half of the bottom
> line gets rendered and repeated as the top line.
>
> For me the reason that proper support could in theory be useful, is that
> were there in future a way to sync up properly,  my TV will do a nice "free"
> deinterlace. Even on a fast quad core PC doing one as good on cpu is not
> possible for HD 50i.

Interlaced modes are supported on all intel platforms (except i8xx, hw
can't do it there) and we have full support for CEA modes.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 06:21:09PM +0200, Lucas Stach wrote:
> Am Freitag, den 31.05.2013, 17:29 +0200 schrieb Daniel Vetter:
> > On Fri, May 31, 2013 at 07:22:24PM +0900, ??? wrote:
> > > Hello Daniel,
> > > 
> > > Thanks for your comment.
> > > 
> > > On 2013? 05? 31? 18:14, Daniel Vetter wrote:
> > > > On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  > > > samsung.com> wrote:
> > > >> importer private data in dma-buf attachment can be used by importer to
> > > >> reimport same dma-buf.
> > > >>
> > > >> Seung-Woo Kim (2):
> > > >>   dma-buf: add importer private data to attachment
> > > >>   drm/prime: find gem object from the reimported dma-buf
> > > > 
> > > > Self-import should already work (at least with the latest refcount
> > > > fixes merged). At least the tests to check both re-import on the same
> > > > drm fd and on a different all work as expected now.
> > > 
> > > Currently, prime works well for all case including self-importing,
> > > importing, and reimporting as you describe. Just, importing dma-buf from
> > > other driver twice with different drm_fd, each import create its own gem
> > > object even two import is done for same buffer because prime_priv is in
> > > struct drm_file. This means mapping to the device is done also twice.
> > > IMHO, these duplicated creations and maps are not necessary if drm can
> > > find previous import in different prime_priv.
> > 
> > Well, that's imo a bug with the other driver. If it doesn't export
> > something really simple (e.g. contiguous memory which doesn't require any
> > mmio resources at all) it should have a cache of exported dma_buf fds so
> > that it hands out the same dma_buf every time.
> 
> I agree with the reasoning here.
> 
> Though it would be nice to have this "expected driver behavior" put down
> somewhere in the documentation. Any volunteers?

I'm not sure how much sense this makes. Imo the importer side is rather
clearly spelled out, everything else is only now shaping up. And even with
the clear interface spec we pretty much have no in-tree dma_buf user who
doesn't cut corners somewhere for one or the other reason. As long the set
of exporters is fairly limited we should be fine for now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/mgag200: Add missing write to index before accessing data register

[Christopher Harvey]

This is a bug fix for some versions of g200se cards while doing
mode-setting.

Signed-off-by: Christopher Harvey 
Tested-by: Julia Lemire 
Acked-by: Julia Lemire Julia Lemire 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index deed0bd..5b1a9e7 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1034,13 +1034,14 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
else
hi_pri_lvl = 5;

-   WREG8(0x1fde, 0x06);
-   WREG8(0x1fdf, hi_pri_lvl);
+   WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
+   WREG8(MGAREG_CRTCEXT_DATA, hi_pri_lvl);
} else {
+   WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
if (mdev->reg_1e24 >= 0x01)
-   WREG8(0x1fdf, 0x03);
+   WREG8(MGAREG_CRTCEXT_DATA, 0x03);
else
-   WREG8(0x1fdf, 0x04);
+   WREG8(MGAREG_CRTCEXT_DATA, 0x04);
}
}
return 0;
-- 
1.8.1.5

[PATCH] drm/mgag200: Add missing write to index before accessing data register

[Christopher Harvey]

On Fri, May 31 2013, Christopher Harvey  wrote:
> This is a bug fix for some versions of g200se cards while doing
> mode-setting.
>
> Signed-off-by: Christopher Harvey 
> Tested-by: Julia Lemire 
> Acked-by: Julia Lemire Julia Lemire  matrox.com>

hmmm, feel free to delete the extra "Julia Lemire "
before applying. (or I could just re-send)

thanks

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #12 from mombelli.mauro at gmail.com ---
here the error tring to compile TAG 9.1.2 with patch (but error is in a
different file).
This is with autogen.sh without any option and with option ./autogen.sh
--prefix=/usr --sysconfdir=/etc
--with-dri-driverdir=/usr/lib/xorg/modules/dri
--with-gallium-drivers=radeonsi
--with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast
--enable-gallium-llvm --enable-egl --enable-gallium-egl
--with-egl-platforms=x11,drm,wayland --enable-shared-glapi
--enable-gbm --enable-glx-tls --enable-dri --enable-glx
--enable-osmesa --enable-gles1 --enable-gles2
--enable-texture-float --enable-xa --enable-vdpau

gcc (GCC) 4.8.0 20130502 (prerelease)
with latest llvm from http://llvm.org/svn/llvm-project/llvm/trunk/


gallivm/lp_bld_debug.cpp: In member function 'virtual void
raw_debug_ostream::write_impl(const char*, size_t)':
gallivm/lp_bld_debug.cpp:106:40: warning: cast from type 'const char*' to
type 'char*' casts away qualifiers [-Wcast-qual]
   char *lastPtr = (char *)&Ptr[Size];
^
gallivm/lp_bld_debug.cpp: In function 'void lp_disassemble(const void*)':
gallivm/lp_bld_debug.cpp:206:64: error: no matching function for call to
'llvm::Target::createMCAsmInfo(std::string&) const'
OwningPtr AsmInfo(T->createMCAsmInfo(Triple));
^
gallivm/lp_bld_debug.cpp:206:64: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:37:0:
/usr/include/llvm/Support/TargetRegistry.h:298:16: note: llvm::MCAsmInfo*
llvm::Target::createMCAsmInfo(const llvm::MCRegisterInfo&, llvm::StringRef)
const
 MCAsmInfo *createMCAsmInfo(const MCRegisterInfo &MRI,
^
/usr/include/llvm/Support/TargetRegistry.h:298:16: note:   candidate
expects 2 arguments, 1 provided




2013/5/31 

>   *Comment # 11 <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c11>on bug
> 64776 <https://bugs.freedesktop.org/show_bug.cgi?id=64776> from Michel
> D?nzer  *
>
> (In reply to comment #10 
> <https://bugs.freedesktop.org/show_bug.cgi?id=64776#c10>)
> > Should I use newer tag than 1.1?
>
>
> You wrote the problem happens with 9.1.2 but not with 9.1.1, so it's probably
> best to stay within those tags for now.
>
>
> > I think strage that compiling mAster was on error for me.. Normally aren't
> > the pull self-contined?
>
>
> Can't really say anything about that without at least seeing the error.
>
>  --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130531/d2c2dca2/attachment.html>

[Bug 64776] [9.1.2]"GPU fault detected" whit "eclipse juno" crash system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64776

--- Comment #13 from Laurent carlier  ---
(In reply to comment #12)
> here the error tring to compile TAG 9.1.2 with patch (but error is in a
> different file).
> This is with autogen.sh without any option and with option ./autogen.sh
> --prefix=/usr --sysconfdir=/etc
> --with-dri-driverdir=/usr/lib/xorg/modules/dri
> --with-gallium-drivers=radeonsi
> --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast
> --enable-gallium-llvm --enable-egl --enable-gallium-egl
> --with-egl-platforms=x11,drm,wayland --enable-shared-glapi
> --enable-gbm --enable-glx-tls --enable-dri --enable-glx
> --enable-osmesa --enable-gles1 --enable-gles2
> --enable-texture-float --enable-xa --enable-vdpau
> 
> gcc (GCC) 4.8.0 20130502 (prerelease)
> with latest llvm from http://llvm.org/svn/llvm-project/llvm/trunk/
> 

For mesa-9.1.x the proper llvm is here:
http://cgit.freedesktop.org/~tstellar/llvm/

-- 
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/20130531/c486d1ae/attachment-0001.html>

[Bug 65068] vgaswitcheroo doesn't deal with powered off dGPU on resume

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=65068

--- Comment #4 from Austin Lund  ---
I'm not sure if this has anything to do with this bug, but the PCI config space
is all messed up when running on the integrated GPU:

# cat /sys/kernel/debug/vgaswitcheroo/switch 
0:IGD:+:Pwr::00:02.0
1:DIS: :Off::01:00.0
2:DIS-Audio: :Off::01:00.1
# lspci -s 01:00 -xx
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Whistler [Radeon HD 6600M/6700M/7600M Series] (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Turks/Whistler
HDMI Audio [Radeon HD 6000 Series] (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Maybe this is why suspend/resume doesn't work?  Should the apple gmuxer remove
the radeon device from the list of pci devices when in this state?  (Like
hotplugging?)

-- 
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/20130531/fe8cfd16/attachment.html>