dri-devel March 2014

dri-devel@lists.freedesktop.org

144 participants
926 discussions

[Bug 76659] Display does not return from DPMS off using ATI drivers
by bugzilla-daemon＠freedesktop.org 27 Mar '14

27 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=76659 Tyler Brock <tyler.brock(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 76659] Display does not return from DPMS off using ATI drivers
by bugzilla-daemon＠freedesktop.org 27 Mar '14

27 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=76659 --- Comment #2 from Tyler Brock <tyler.brock(a)gmail.com> --- I found nothing in the logs yesterday but then when I came into work today the monitor was flickering and essentially dead. I plugged in another monitor and everything works just fine. It was just the monitor dying! Thanks for taking a look Alex. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 1/2] drm/radeon: fix runtime suspend breaking secondary GPUs
by Dave Airlie 27 Mar '14

27 Mar '14

From: Dave Airlie <airlied(a)redhat.com> Same fix as for nouveau, when we fail with EINVAL, subsequent gets fail hard, causing the device not to open. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/radeon/radeon_drv.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 84a1bbb7..f633c27 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -403,11 +403,15 @@ static int radeon_pmops_runtime_suspend(struct device *dev) struct drm_device *drm_dev = pci_get_drvdata(pdev); int ret; - if (radeon_runtime_pm == 0) - return -EINVAL; + if (radeon_runtime_pm == 0) { + pm_runtime_forbid(dev); + return -EBUSY; + } - if (radeon_runtime_pm == -1 && !radeon_is_px()) - return -EINVAL; + if (radeon_runtime_pm == -1 && !radeon_is_px()) { + pm_runtime_forbid(dev); + return -EBUSY; + } drm_dev->switch_power_state = DRM_SWITCH_POWER_CHANGING; drm_kms_helper_poll_disable(drm_dev); @@ -456,12 +460,15 @@ static int radeon_pmops_runtime_idle(struct device *dev) struct drm_device *drm_dev = pci_get_drvdata(pdev); struct drm_crtc *crtc; - if (radeon_runtime_pm == 0) + if (radeon_runtime_pm == 0) { + pm_runtime_forbid(dev); return -EBUSY; + } /* are we PX enabled? */ if (radeon_runtime_pm == -1 && !radeon_is_px()) { DRM_DEBUG_DRIVER("failing to power off - not px\n"); + pm_runtime_forbid(dev); return -EBUSY; } -- 1.8.5.3

1 1

Hiding a monitor from all apps except one
by Ilya Faenson 27 Mar '14

27 Mar '14

Dear DRM Experts, My assignment is to make sure the more or less standard HDMI-connected monitor is visible and accessible to a single (our own) OpenGL application only. That monitor is part of the larger device so it does not make sense for anybody else to interfere with its use. The solution should work with any graphics adapter. I see a few virtual monitor implementations available like VirtualGL, vcrtcm, various VNC flavors but we rather need to hide an existing monitor rather than create a virtual one. I guess we could try creating a virtual monitor, mapping it into the physical one, but the hiding it from almost everybody at the upper edge of the DRM might be tricky. The background: I'm a very experienced driver developer but I'm new to Linux graphics internals. All ideas would be much appreciated! Ilya Faenson Rockville, MD USA

2 4

[PATCH 00/16] Atomic/nuclear modeset/pageflip
by Rob Clark 26 Mar '14

26 Mar '14

Previous revision of series: http://lists.freedesktop.org/archives/dri-devel/2013-November/049594.html And if you prefer, in git form: http://cgit.freedesktop.org/~robclark/linux/log/?h=cold-fusion git://people.freedesktop.org/~robclark/linux cold-fusion Compared to previous revision: * rebased on primary-plane RFC series. As a result, nearly none of the drivers actually compile at the moment :-P But it is in the end a good thing... it reduces some code paths (now only having to care about fbs on planes, and it avoids exposing an intermediate ABI state to userspace so avoids the need for some compat glue later). * state objects now carry their own ref to fbs. This cleaned up most of the refcnt'ing issues, so I'm pretty happy how that turned out. With that plus all the other major hacks cleaned up, I'm happy enough to drop the "RFC" tag. There are, I think, two remaining issues to solve: * we either need to add an event ptr param to plane->update_plane() or come up with another way to handle events on planes. * I kinda would still like to add to the atomic ioctl some way to indicate ok/error on a bit finer granularity than per-ioctl. Ie. perhaps an array where userspace can ask for results per KMS object (crtc/plane)? Something along these lines would give the kernel a bit more flexibility to deal with some of the edge cases which come up when you gang crtcs for ultra high resolution displays. In short, it would let the driver "steal" some of the planes if needed from userspace. This would also, conveniently, be pretty similar to how (AFAIU) hw compositor and ADF work on android. Which seems like it would be useful to eventually enable android devices to use an upstream display driver. For this we could pretty easily just throw in a placeholder that we could replace later with an optional ptr to __user array. I think that would be fine for an initial version, but I just wanted to throw this idea out there, because I think it will become important. Note that this series is really only the beginning of atomic. Once this is merged, there are some various vague thoughts about next steps: * finish converting remaining callers of drm_mode_set_config_internal() to use atomic * replace driver usage of plane->fb with plane->state->fb.. drop plane->fb, somewhere along the way deprecate/drop ->page_flip() and possibly current incarnation of ->update_plane().. * perhaps some more fine grained event notification or other such extensions. * I know there are a few things I plan on ripping out / simplifying in drm/msm as a result of atomic, but just waiting until this is merge to avoid carrying such ....... So, that all said, I am a bit curious about how we might eventually land this series some day. Especially once we include changes to update all points in various drivers that access crtc->fb to crtc->primary->fb it will be one big hairy merge-conflict-prone branch. Not the sort of thing that I'd really like to have to rebase for the next five kernel cycles if at all avoidable. We certainly could merge everything but the new ioctl, or hide the ioctl behind an experimental module param for now. I'm less concerned about that (either option would be pretty easy), and more about merging the infrastructure changes. Rob Clark (13): drm: fix typo drm: add atomic fxns drm: convert crtc to ww_mutex drm: add object property type drm: add signed-range property type drm: helpers to find mode objects drm: split propvals out and blob property support drm: allow FB's in drm_mode_object_find drm: convert plane to properties/state drm: convert crtc to properties/state drm: push locking down into restore_fbdev_mode drm/msm: add atomic support drm: spiff out FB refcnting traces Ville Syrjälä (3): drm: Allow drm_mode_object_find() to look up an object of any type drm: Refactor object property check code drm: Atomic modeset ioctl drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/armada/armada_crtc.c | 15 +- drivers/gpu/drm/armada/armada_fbdev.c | 4 +- drivers/gpu/drm/armada/armada_output.c | 3 +- drivers/gpu/drm/armada/armada_overlay.c | 15 +- drivers/gpu/drm/ast/ast_drv.c | 6 + drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/cirrus/cirrus_drv.c | 6 + drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + drivers/gpu/drm/drm_atomic.c | 702 +++++++++++ drivers/gpu/drm/drm_crtc.c | 1667 +++++++++++++++++++-------- drivers/gpu/drm/drm_crtc_helper.c | 2 +- drivers/gpu/drm/drm_drv.c | 1 + drivers/gpu/drm/drm_fb_cma_helper.c | 9 +- drivers/gpu/drm/drm_fb_helper.c | 28 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 11 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 1 + drivers/gpu/drm/gma500/cdv_intel_dp.c | 7 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 7 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 +- drivers/gpu/drm/gma500/psb_drv.c | 11 +- drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/gpu/drm/gma500/psb_intel_display.c | 1 + drivers/gpu/drm/gma500/psb_intel_drv.h | 4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 10 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 23 +- drivers/gpu/drm/i2c/ch7006_drv.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 8 + drivers/gpu/drm/i915/intel_crt.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 16 +- drivers/gpu/drm/i915/intel_dp.c | 7 +- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_fbdev.c | 6 +- drivers/gpu/drm/i915/intel_hdmi.c | 7 +- drivers/gpu/drm/i915/intel_lvds.c | 4 +- drivers/gpu/drm/i915/intel_sdvo.c | 23 +- drivers/gpu/drm/i915/intel_sprite.c | 1 + drivers/gpu/drm/i915/intel_tv.c | 11 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 7 + drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 69 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 6 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 15 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 66 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 6 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 2 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 15 +- drivers/gpu/drm/msm/msm_atomic.c | 141 +++ drivers/gpu/drm/msm/msm_drv.c | 33 +- drivers/gpu/drm/msm/msm_drv.h | 8 + drivers/gpu/drm/msm/msm_gem.c | 24 +- drivers/gpu/drm/msm/msm_gem.h | 13 + drivers/gpu/drm/msm/msm_kms.h | 1 + drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1 + drivers/gpu/drm/nouveau/dispnv04/overlay.c | 14 +- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 3 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 7 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 + drivers/gpu/drm/nouveau/nouveau_drm.h | 1 + drivers/gpu/drm/nouveau/nv50_display.c | 1 + drivers/gpu/drm/omapdrm/omap_crtc.c | 27 +- drivers/gpu/drm/omapdrm/omap_drv.c | 16 +- drivers/gpu/drm/omapdrm/omap_drv.h | 5 +- drivers/gpu/drm/omapdrm/omap_plane.c | 11 +- drivers/gpu/drm/qxl/qxl_display.c | 6 +- drivers/gpu/drm/qxl/qxl_drv.c | 9 + drivers/gpu/drm/radeon/radeon_connectors.c | 9 +- drivers/gpu/drm/radeon/radeon_display.c | 2 + drivers/gpu/drm/radeon/radeon_drv.c | 9 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 7 + drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 3 +- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 12 +- drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 3 +- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 6 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 7 + drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 + drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 + drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 + drivers/gpu/drm/tilcdc/tilcdc_slave.c | 3 +- drivers/gpu/drm/udl/udl_connector.c | 6 +- drivers/gpu/drm/udl/udl_drv.c | 8 + drivers/gpu/drm/udl/udl_modeset.c | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 + include/drm/drmP.h | 88 +- include/drm/drm_atomic.h | 172 +++ include/drm/drm_crtc.h | 379 +++++- include/drm/drm_fb_helper.h | 3 +- include/uapi/drm/drm.h | 12 + include/uapi/drm/drm_mode.h | 38 + 106 files changed, 3214 insertions(+), 792 deletions(-) create mode 100644 drivers/gpu/drm/drm_atomic.c create mode 100644 drivers/gpu/drm/msm/msm_atomic.c create mode 100644 include/drm/drm_atomic.h -- 1.8.5.3

3 25

[Bug 76659] Display does not return from DPMS off using ATI drivers
by bugzilla-daemon＠freedesktop.org 26 Mar '14

26 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=76659 Alex Deucher <agd5f(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|xorg-driver-ati(a)lists.x.org |dri-devel(a)lists.freedesktop | |.org QA Contact|xorg-team(a)lists.x.org | Product|xorg |DRI Version|7.3 (2007.09) |unspecified Component|Driver/Radeon |DRM/Radeon --- Comment #1 from Alex Deucher <agd5f(a)yahoo.com> --- Please attach your dmesg output from after the display does not come back. Is this a regression? If so, can you bisect the kernel? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 76320] New: libpciaccess seems to require xorg-macros for no reason
by bugzilla-daemon＠freedesktop.org 26 Mar '14

26 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=76320 Priority: medium Bug ID: 76320 Assignee: dri-devel(a)lists.freedesktop.org Summary: libpciaccess seems to require xorg-macros for no reason Severity: normal Classification: Unclassified OS: All Reporter: kallisti5(a)unixzen.com Hardware: Other Status: NEW Version: XOrg CVS Component: libdrm Product: DRI Looking at libpciaccess, the configure.ac seems to require xorg-macros when it is not needed in any way shape or form. Removing the xorg-macros still results in a functioning build. I did have to disable the man pages, this may not be related though: make[2]: Entering directory `/home/e1529750/Code/libpciaccess-0.13.2/man' /bin/sed < scanpci.man > scanpci. Usage: /bin/sed [OPTION]... {script-only-if-no-other-script} [input-file]... -n, --quiet, --silent suppress automatic printing of pattern space Mentioning this as libdrm is supposed to not rely on xorg to function, but it relies on libpciaccess which requires xorg-macros. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 75494] Kabini [Radeon HD 8240] Xorg segfault on resume from suspend with glamor and radeonsi
by bugzilla-daemon＠freedesktop.org 26 Mar '14

26 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=75494 --- Comment #8 from Jarno Leppänen <jarno.leppanen(a)iki.fi> --- Works now also on linux stable 3.13.7 -- You are receiving this mail because: You are the assignee for the bug.

1 0

exynos-drm HDMI PHY configuration values
by Daniel Drake 26 Mar '14

26 Mar '14

Hi Sean, In your commit "drm/exynos: hdmi: support extra resolutions using drm_display_mode timings" you added several more HDMI PHY configs to exynos-drm. Thanks for that. Can you explain where these magic numbers came from? I'm interested in adding 85.5MHz for 1366x768 support. Thanks, Daniel

2 1

[PATCH] drm/radeon: clear needs_reset flag if IB test fails
by Christian König 26 Mar '14

26 Mar '14

From: Christian König <christian.koenig(a)amd.com> If the IB test fails we don't want to reset the card over and over again, just accept that it isn't working. Signed-off-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_ring.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_ring.c b/drivers/gpu/drm/radeon/radeon_ring.c index 15e44a7..8391fca 100644 --- a/drivers/gpu/drm/radeon/radeon_ring.c +++ b/drivers/gpu/drm/radeon/radeon_ring.c @@ -257,6 +257,7 @@ int radeon_ib_ring_tests(struct radeon_device *rdev) r = radeon_ib_test(rdev, i, ring); if (r) { ring->ready = false; + rdev->needs_reset = false; if (i == RADEON_RING_TYPE_GFX_INDEX) { /* oh, oh, that's really bad */ -- 1.9.1

2 3

← Newer
1
...
65
66
67
68
69
70
71
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2014