bugzilla-daemon | 1 Feb 01:35 2012

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

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

--- Comment #11 from Alexandre Demers <alexandre.f.demers <at> gmail.com> 2012-01-31 16:35:53 PST ---
(In reply to comment #10)
> (In reply to comment #9)
> > The bugs is not visible under kernel 3.2, [...]
> 
> 3.2 lacks Radeon virtual address space support.
> 
> > I will try with a 3.3-rc2 kernel once it will be available.
> 
> That's unlikely to make a difference, this is likely a userspace bug.

Indeed and I can now confirm it. 3.3-rc2 doesn't change the problem.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Seth Forshee | 1 Feb 02:06 2012

Re: radeon issues on MacBook Pro 8,2

On Fri, Jan 20, 2012 at 05:08:31PM -0600, Seth Forshee wrote:
> > Can you track down who is calling the connector->detect() callbacks
> > during suspend and resume?
> 
> I got two different stack traces, see below.
> 
> And to slightly amend my statement above, I'm only seeing the wrong
> status returned on the suspend side of things. The status during resume
> always seems to be correct.
> 
>  Pid: 49, comm: kworker/0:2 Tainted: G         C O 3.2.0-10-generic #17-Ubuntu
>  Call Trace:
>   [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon]
>   [<ffffffffa014ac6d>] output_poll_execute+0xbd/0x1a0 [drm_kms_helper]
>   [<ffffffffa014abb0>] ? drm_helper_mode_fill_fb_struct+0x30/0x30 [drm_kms_helper]
>   [<ffffffff81083dca>] process_one_work+0x11a/0x480
>   [<ffffffff81084b74>] worker_thread+0x164/0x370
>   [<ffffffff81084a10>] ? manage_workers.isra.30+0x130/0x130
>   [<ffffffff810893cc>] kthread+0x8c/0xa0
>   [<ffffffff81660674>] kernel_thread_helper+0x4/0x10
>   [<ffffffff81089340>] ? flush_kthread_worker+0xa0/0xa0
>   [<ffffffff81660670>] ? gs_change+0x13/0x13
> 
>  Pid: 49, comm: kworker/0:2 Tainted: G         C O 3.2.0-10-generic #17-Ubuntu
>  Call Trace:
>   [<ffffffffa03f5e1e>] radeon_dp_detect+0x1de/0x230 [radeon]
>   [<ffffffffa014b6b3>] drm_helper_probe_single_connector_modes+0x2c3/0x380 [drm_kms_helper]
>   [<ffffffffa0149d42>] drm_fb_helper_hotplug_event+0xf2/0x150 [drm_kms_helper]
>   [<ffffffffa03fe8d5>] radeon_fb_output_poll_changed+0x15/0x20 [radeon]
>   [<ffffffffa03f7b65>] radeon_output_poll_changed+0x15/0x20 [radeon]
(Continue reading)

bugzilla-daemon | 1 Feb 02:36 2012

[Bug 45473] New: vdpau-r300 requires softpipe

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

             Bug #: 45473
           Summary: vdpau-r300 requires softpipe
    Classification: Unclassified
           Product: Mesa
           Version: git
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/Gallium/r300
        AssignedTo: dri-devel <at> lists.freedesktop.org
        ReportedBy: neotheuser <at> ymail.com

When compiling vdpau-r300 (libvdpau_r300.so) I get a compiling error:

No rule to make target
`../../../../src/gallium/drivers/softpipe/libsoftpipe.a', needed by
`../../../../lib/gallium/libvdpau_r300.so'.  Stop.

The solution:

Instead of ./autogen.sh --with-dri-drivers="" --with-gallium-drivers=r300
--enable-vdpau

add swrast to gallium driver

./autogen.sh --with-dri-drivers="" --with-gallium-drivers=r300,swrast
(Continue reading)

bugzilla-daemon | 1 Feb 07:25 2012

[Bug 45290] [bisected r200] fdo23670-drawpix_stencil fails and crashes

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

--- Comment #4 from Ian Romanick <idr <at> freedesktop.org> 2012-01-31 22:25:22 PST ---
(In reply to comment #2)
> Can you upgrade to a DDX from -git?
> 
> I think the fix is in there, it was allocating too small depth buffers.

I can, but it won't be until next week.  I'm currently traveling.

--

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Michel Dänzer | 1 Feb 09:39 2012
Face
Picon

Re: [PATCH] drm/radeon: Add support for userspace fence waits

On Die, 2012-01-31 at 22:08 +0100, Marek Olšák wrote: 
> 2012/1/31 Jerome Glisse <j.glisse <at> gmail.com>:
> > On Tue, Jan 31, 2012 at 06:56:01PM +0100, Michel Dänzer wrote:
> >> On Die, 2012-01-31 at 16:59 +0000, Simon Farnsworth wrote:
> >> > Userspace currently busywaits for fences to complete; on my workload, this
> >> > busywait consumes 10% of the available CPU time.
> >> >
> >> > Provide an ioctl so that userspace can wait for an EOP interrupt that
> >> > corresponds to a previous EVENT_WRITE_EOP.
> >> >
> >> > Signed-off-by: Simon Farnsworth <simon.farnsworth <at> onelan.co.uk>
> >> > ---
> >> > I've been working on top of Jerome's tiling patches, so this doesn't apply
> >> > directly on top of current upstream kernels. I can easily rebase to another
> >> > version upon request - just point me to a git tree.
> >> >
> >> > My goal is to remove the sched_yield in Mesa's r600_fence_finish given up to
> >> > date enough kernel; I hope, though, that the interface is clean enough for
> >> > other users to extend it in the future (e.g. using compute rings).
> >>
> >> I'm afraid not: Unless I'm missing something, userspace can't know which
> >> ring the kernel submitted the CS to, and the kernel can't guess which
> >> ring userspace needs to wait for.
> >
> > iirc the plan was to add a return value to cs ioctl and add an ioctl to
> > allow to wait on this return value. ie allowing userspace to wait on
> > specific submited cs.
> 
> You don't need a new API for that, r300g already does that. It adds a
> dummy relocation and later uses GEM_WAIT_IDLE to wait for it. r600g
(Continue reading)

Sascha Hauer | 1 Feb 11:38 2012
Picon

[PATCH 01/20] drm crtc: use drm_mode_destroy instead of kfree in drm_mode_remove

Modes are created using drm_mode_create which does a
drm_mode_object_get, so use drm_mode_destroy in drm_mode_remove
which does a drm_mode_object_put.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
---
 drivers/gpu/drm/drm_crtc.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5e818a8..8389fd3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
 <at>  <at>  -442,7 +442,7  <at>  <at>  void drm_mode_remove(struct drm_connector *connector,
 		     struct drm_display_mode *mode)
 {
 	list_del(&mode->head);
-	kfree(mode);
+	drm_mode_destroy(connector->dev, mode);
 }
 EXPORT_SYMBOL(drm_mode_remove);

--

-- 
1.7.8.3
Sascha Hauer | 1 Feb 11:38 2012
Picon

[PATCH 13/20] drm crtc: Fix locking comments

Several comments above functions say that the caller must hold the
mode_config lock, but the functions take the lock themselves. Fix
the comments.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
---
 drivers/gpu/drm/drm_crtc.c |   21 +++++++++++++++------
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index df6e413..322bc7b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
 <at>  <at>  -454,7 +454,7  <at>  <at>  EXPORT_SYMBOL(drm_mode_remove);
  *  <at> name: user visible name of the connector
  *
  * LOCKING:
- * Caller must hold  <at> dev's mode_config lock.
+ * Takes mode config lock.
  *
  * Initialises a preallocated connector. Connectors should be
  * subclassed as part of driver connector objects.
 <at>  <at>  -497,7 +497,7  <at>  <at>  EXPORT_SYMBOL(drm_connector_init);
  *  <at> connector: connector to cleanup
  *
  * LOCKING:
- * Caller must hold  <at> dev's mode_config lock.
+ * Takes mode config lock.
  *
  * Cleans up the connector but doesn't free the object.
(Continue reading)

Sascha Hauer | 1 Feb 11:38 2012
Picon

[PATCH 05/20] drm: add proper return value for drm_mode_crtc_set_gamma_size

drm_mode_crtc_set_gamma_size returns boolean true for success
and false for failure. This is not very kernel conform, so
change it to return 0 for success and a propert error code
otherwise. Noone checks the return value, so no users have to
be fixed.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
---
 drivers/gpu/drm/drm_crtc.c |    6 +++---
 include/drm/drm_crtc.h     |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 33ebe29..df6e413 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
 <at>  <at>  -3024,7 +3024,7  <at>  <at>  void drm_mode_connector_detach_encoder(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_detach_encoder);

-bool drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
+int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 				  int gamma_size)
 {
 	crtc->gamma_size = gamma_size;
 <at>  <at>  -3032,10 +3032,10  <at>  <at>  bool drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 	crtc->gamma_store = kzalloc(gamma_size * sizeof(uint16_t) * 3, GFP_KERNEL);
 	if (!crtc->gamma_store) {
 		crtc->gamma_size = 0;
-		return false;
(Continue reading)

Sascha Hauer | 1 Feb 11:38 2012
Picon

[PATCH 11/20] drm fb helper: add the connectors inside drm_fb_helper_initial_config

drm_fb_helper_single_add_all_connectors is always called in
conjunction with drm_fb_helper_initial_config, so call
drm_fb_helper_single_add_all_connectors inside
drm_fb_helper_initial_config and make
drm_fb_helper_single_add_all_connectors static.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
---
 drivers/gpu/drm/drm_fb_helper.c           |    5 +++--
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   13 -------------
 drivers/gpu/drm/gma500/framebuffer.c      |    1 -
 drivers/gpu/drm/i915/intel_fb.c           |    1 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   |    2 --
 drivers/gpu/drm/radeon/radeon_fb.c        |    1 -
 include/drm/drm_fb_helper.h               |    1 -
 7 files changed, 3 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 231255b..b54298f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
 <at>  <at>  -44,7 +44,7  <at>  <at>  MODULE_LICENSE("GPL and additional rights");
 static LIST_HEAD(kernel_fb_helper_list);

 /* simple single crtc case helper function */
-int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
+static int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper)
 {
 	struct drm_device *dev = fb_helper->dev;
 	struct drm_connector *connector;
(Continue reading)

Sascha Hauer | 1 Feb 11:38 2012
Picon

[PATCH 12/20] drm crtc_helper: use list_for_each_entry

list_for_each_entry_safe is for walking a list safe against removal
of entries. Here, no entries are removed, so use list_for_each_entry.

Signed-off-by: Sascha Hauer <s.hauer <at> pengutronix.de>
---
 drivers/gpu/drm/drm_crtc_helper.c |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 84a4a80..d761d12 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
 <at>  <at>  -44,12 +44,12  <at>  <at>  module_param_named(poll, drm_kms_helper_poll, bool, 0600);
 static void drm_mode_validate_flag(struct drm_connector *connector,
 				   int flags)
 {
-	struct drm_display_mode *mode, *t;
+	struct drm_display_mode *mode;

 	if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE))
 		return;

-	list_for_each_entry_safe(mode, t, &connector->modes, head) {
+	list_for_each_entry(mode, &connector->modes, head) {
 		if ((mode->flags & DRM_MODE_FLAG_INTERLACE) &&
 				!(flags & DRM_MODE_FLAG_INTERLACE))
 			mode->status = MODE_NO_INTERLACE;
 <at>  <at>  -87,7 +87,7  <at>  <at>  int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
 					    uint32_t maxX, uint32_t maxY)
 {
(Continue reading)


Gmane