Daniel Drake | 15 Sep 20:52 2014

[PATCH] drm/exynos: fix plane-framebuffer linkage

Pageflipping currently causes some inconsistencies that lead to
crashes. Just run an app that causes a CRTC pageflip in a raw X session
and check that it exits cleanly and can be restarted - you'll see
crashes like:
 Unable to handle kernel NULL pointer dereference at virtual address 00000334
 PC is at exynos_drm_crtc_plane_commit+0x20/0x40
 LR is at exynos_drm_crtc_plane_commit+0x20/0x40
 [<c03749b4>] (exynos_drm_crtc_plane_commit) from [<c03741bc>] (exynos_drm_crtc_commit+0x44/0x70)
 [<c03741bc>] (exynos_drm_crtc_commit) from [<c03743a0>] (exynos_drm_crtc_mode_set_commit.isra.2+0xb4/0xc4)
 [<c03743a0>] (exynos_drm_crtc_mode_set_commit.isra.2) from [<c03744f4>] (exynos_drm_crtc_page_flip+0x140/0x1a8)
 [<c03744f4>] (exynos_drm_crtc_page_flip) from [<c036b20c>] (drm_mode_page_flip_ioctl+0x224/0x2dc)
 [<c036b20c>] (drm_mode_page_flip_ioctl) from [<c035c324>] (drm_ioctl+0x338/0x4fc)

These crashes happen because drm_plane_force_disable has previously set
plane->crtc to NULL.

When drm_mode_page_flip_ioctl() is used to flip another framebuffer
onto the primary plane, crtc->primary->fb is correctly updated (this is
a virtual plane created by plane_helper), but plane->fb is not (this
plane is the real one, created by exynos_drm_crtc_create).

We then come to handle rmfb of the backbuffer, which the "real" primary
plane is incorrectly pointing at. So drm_framebuffer_remove() decides that
the buffer is actually active on a plane and force-disables the plane.

Ensuring that plane->fb is kept up-to-date solves that issue, but
exposes a reference counting problem. Now we see crashes when rmfb is
called on the front-buffer, because the rmfb code expects to drop 3
references here, and there are only 2.

(Continue reading)

Daniel Vetter | 15 Sep 14:35 2014
Picon

[PATCH 00/11] Spinlock use clarification in i915

Hi all,

So I've tried to figure out a way how to clear up our irq setup mess, but
instead only managed to get sidetracked on a spinlock usage review.

Review highly welcome.

Cheers, Daniel

Daniel Vetter (11):
  drm/i915: Clarify event_lock locking, process context
  drm/i915: Clarify event_lock locking, irq&mixed context
  drm/i915: Clarify gpu_error.lock locking
  drm/i915: Clarify irq_lock locking, intel_tv_detect
  drm/i915: Clarify irq_lock locking, work functions
  drm/i915: Clarify irq_lock locking, interrupt install/uninstall
  drm/i915: Clarify irq_lock locking, irq handlers
  drm/i915: Clarify irq_lock locking, special cases
  drm/i915: Convert backlight_lock to a mutex
  drm/i915: Clarify uncore.lock locking
  drm/i915: Clarify mmio_flip_lock locking

 drivers/gpu/drm/i915/i915_debugfs.c   |   5 +-
 drivers/gpu/drm/i915/i915_dma.c       |   2 +-
 drivers/gpu/drm/i915/i915_drv.c       |   5 +-
 drivers/gpu/drm/i915/i915_drv.h       |   2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  10 ++--
 drivers/gpu/drm/i915/i915_irq.c       | 101 ++++++++++++++--------------------
 drivers/gpu/drm/i915/intel_display.c  |  67 +++++++++++-----------
 drivers/gpu/drm/i915/intel_panel.c    |  30 ++++------
(Continue reading)

Daniel Vetter | 15 Sep 13:44 2014
Picon

[PATCH] drm: Fixup locking for universal cursor planes

Bunch of things amiss:
- Updating crtc->cursor_x/y was done without any locking. Spotted by
  David Herrmann.
- Dereferencing crtc->cursor->fb was using the wrong lock, should take
  the crtc lock.
- Grabbing _all_ modeset locks torpedoes the reason why we added
  fine-grained locks originally: Cursor updates shouldn't stall on
  background stuff like probing outputs.

Best is to just grab the crtc lock around everything and drop all the
other locking. The only issue is that we can't switch planes between
crtcs with that, so make sure that never happens when someone uses
universal plane helpers. This shouldn't be a possible regression ever
since legacy ioctls also only grabbed the crtc lock, so switching
crtcs was never possible for the underlying plane object. And i915
(the only user of universal cursors thus far) has fixed cursor->crtc
links.

Cc: David Herrmann <dh.herrmann <at> gmail.com>
Cc: Pallavi G<pallavi.g <at> intel.com>
Cc: Matt Roper <matthew.d.roper <at> intel.com>
Reviewed-by: Matt Roper <matthew.d.roper <at> intel.com>
Tested-by: Matt Roper <matthew.d.roper <at> intel.com>
Reviewed-by: David Herrmann <dh.herrmann <at> gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter <at> intel.com>
---
 drivers/gpu/drm/drm_crtc.c | 51 ++++++++++++++++++++++++++++++----------------
 1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
(Continue reading)

Sergey Korshunoff | 15 Sep 12:09 2014
Picon

PATCH: radeondrm x86_64 and android32

Android-x86 4.0-r1 (32 bit) have problems with x86_64 kernel when he
trying to use a radeon kms. The following change correct a problem:

drivers/gpu/drm/radeon_kms.c (function radeon_info_ioctl):

- value_ptr = (uint32_t *)((unsigned long)info->value);
+ value_ptr = (uint32_t *)((unsigned)info->value);

Looks like a userspace data in android running under x86_64 is located
above 4 Gb. I don't think so. But after this change android run fine.
Laurent Pinchart | 15 Sep 11:31 2014

[GIT PULL FOR v3.18] DRM core change

Hi Dave,

The following changes since commit 98faa78ce7f1f986e11e7805d31b409782a6d2d4:

  Merge tag 'topic/drm-header-rework-2014-09-12' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2014-09-13 07:01:49 
+1000)

are available in the git repository at:

  git://linuxtv.org/pinchartl/fbdev.git drm/next/core

for you to fetch changes up to 41e58cca2f8d99fe3d5cf60ad1a59cf94b00cf7a:

  drm/gem: Fix kerneldoc typo (2014-09-15 12:30:21 +0300)

----------------------------------------------------------------
Laurent Pinchart (1):
      drm/gem: Fix kerneldoc typo

 drivers/gpu/drm/drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--

-- 
Regards,

Laurent Pinchart
Daniel Vetter | 15 Sep 10:58 2014
Picon

[PULL] topic/core-stuff

Hi Dave,

Here's the updated topic/core-stuff pull request with the two patches
already merged into drm-fixes dropped.

Cheers, Daniel

The following changes since commit edbaae5a5cab89de0e64b8c03ebd9a8d5d266550:

  Merge tag 'topic/vblank-rework-2014-09-12' of git://anongit.freedesktop.org/drm-intel into
drm-next (2014-09-12 19:04:53 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-09-15

for you to fetch changes up to d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21:

  drm: Drop modeset locking from crtc init function (2014-09-15 08:56:30 +0200)

----------------------------------------------------------------
Chris Wilson (1):
      drm: Include task->name and master status in debugfs clients info

Clint Taylor (2):
      drm/edid: Reduce horizontal timings for pixel replicated modes
      drm/i915/hdmi: Enable pipe pixel replication for SD interlaced modes

Daniel Vetter (1):
      drm: Drop modeset locking from crtc init function
(Continue reading)

Maarten Lankhorst | 15 Sep 09:44 2014

[PATCH] nouveau: bump driver patchlevel to 1.2.1

Allows userspace to detect shared fences are supported.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst <at> canonical.com>
---
 drivers/gpu/drm/nouveau/nouveau_drm.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Dave, can you include this in drm-next? It should allow me to optimize nouveau's vdpau decoding a bit.

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.h b/drivers/gpu/drm/nouveau/nouveau_drm.h
index b02b02452c85..8ae36f265fb8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.h
 <at>  <at>  -10,7 +10,7  <at>  <at> 

 #define DRIVER_MAJOR		1
 #define DRIVER_MINOR		2
-#define DRIVER_PATCHLEVEL	0
+#define DRIVER_PATCHLEVEL	1

 /*
  * 1.1.1:
 <at>  <at>  -26,6 +26,8  <at>  <at> 
  * 1.2.0:
  * 	- object api exposed to userspace
  * 	- fermi,kepler,maxwell zbc
+ * 1.2.1:
+ *      - allow concurrent access to bo's mapped read/write.
  */

(Continue reading)

bugzilla-daemon | 15 Sep 04:08 2014

[Bug 83835] Multi Stream Transport (MST) 1.2 Support

changed bug 83835
What Removed Added
Severity normal enhancement
Assignee xorg-driver-ati <at> lists.x.org dri-devel <at> lists.freedesktop.org
QA Contact xorg-team <at> lists.x.org  
Product xorg DRI
Component Driver/Radeon DRM/Radeon

Comment # 1 on bug 83835 from MST support is not implemented yet. Dave started hacking on it, but as far as I know, it's not working yet: http://cgit.freedesktop.org/~airlied/linux/log/?h=radeon-mst-hacks
You are receiving this mail because:
  • You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
bugzilla-daemon | 14 Sep 16:22 2014

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

Comment # 35 on bug 73338 from (In reply to comment #31) > A quick update - I was finally able to retrieve all needed data from fglrx > (via some ADL SDK overdrive6 tinkering). It seems there is a lot of work > (e.g. there is a feature for setting series of pairs > temperature<->fanspeed), but at least I figured out the purpose of used > registers and data values (I hope). Those are called trip points ;) Well done! > > So I'll try to come up with basic functionality and hwmon interface this > week. Have fun ;)
You are receiving this mail because:
  • You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
bugzilla-daemon | 14 Sep 15:13 2014

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

Comment # 34 on bug 73338 from Created attachment 106260 [details] mmiotrace dump for radeon 7850 Here is mmiotrace dump for my radeon 7850, in single-CPU mode.
You are receiving this mail because:
  • You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
bugzilla-daemon | 13 Sep 23:16 2014

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

Comment # 33 on bug 73338 from (In reply to comment #32) > Hi, Oleg. Do you require dumps for PITCAIRN chips Yes, I need as much dumps as possible. I hope overdrive v6 works for all SI chips, so I've made simple example program for testing >SI asics, it lays here https://github.com/Adonai/radeon-fancontrol. You can check if it works while in X session with fglrx driver. So you should do the following: 1) install fglrx and configure it 2) switch to text console and stop any X being used 3) rmmod fglrx 4) now start mmiotrace (kernel has pretty nice doc here https://www.kernel.org/doc/Documentation/trace/mmiotrace.txt) 5) modprobe fglrx 6) start X && export DISPLAY=:0 7) now begin to collect data from mmiotrace (via cat trace_pipe &), you can put some marks here 8) start above mentioned program. There should be some noize from GPU fan for 6 seconds, it's normal 9) after it exits (in 10 seconds) collect its output and piped mmiotrace logs and post the results here Thanks!
You are receiving this mail because:
  • You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Gmane