dri-devel June 2015

dri-devel@lists.freedesktop.org

188 participants
1140 discussions

[Bug 64891] [snd_hda_codec] BUG: soft lockup - CPU#0 stuck for 22s (when using vgaswitcheroo)
by bugzilla-daemon＠bugzilla.kernel.org 30 Jun '15

30 Jun '15

https://bugzilla.kernel.org/show_bug.cgi?id=64891 Tommaso Falchi Delitala <volalto86(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |volalto86(a)gmail.com --- Comment #46 from Tommaso Falchi Delitala <volalto86(a)gmail.com> --- Created attachment 181501 --> https://bugzilla.kernel.org/attachment.cgi?id=181501&action=edit dmesg showing lockpuos (radeon off) I still experience lockups related to audio with discrete card disabled via vgaswitcheroo. Moreover the systems hangs at shutdown. Kernel 4.0.6-1-ARCH AMD Mobility Radeon HD5470 + intel integrated. # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr:0000:00:02.0 1:DIS: :DynOff:0000:01:00.0 2:DIS-Audio: :Off:0000:01:00.1 Interesting dmesg print: snd_hda_intel 0000:01:00.1: Disabling via VGA-switcheroo snd_hda_intel 0000:01:00.1: Cannot lock devices! INFO: task kworker/u16:0:6 blocked for more than 120 seconds. Tainted: G W 4.0.6-1-ARCH #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u16:0 D ffff880132fd7ca8 0 6 2 0x00000000 Workqueue: hd-audio1 hdmi_repoll_eld [snd_hda_codec_hdmi] See complete dmesg in attachment. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 89420] DELL U2415 monitor detection issue
by bugzilla-daemon＠freedesktop.org 30 Jun '15

30 Jun '15

https://bugs.freedesktop.org/show_bug.cgi?id=89420 --- Comment #3 from Michiel Janssens <bugs.freedesktop(a)nexigon.net> --- Just an update. At the moment I'm running a newer kernel. 4.1.1-040101-generic Behaviour has changed. I don't have to use the extra kernel parameter drm_kms_helper.edid_firmware. Without it the monitor seems to be detected properly. So resolution is as it should be 1920X1200, at boot time, and also when logging in. However the power save issue still remains. - when the system tell the monitors to go to sleep, they both do, but when wakingg the screens, the U2415 offten won't come out of power save mode, the system is very sluggish at that moment. I'm not able to trigger the monitor to come out of standby. Not by calling xrandr in terminal, switching between VT's, or powering down the monitor. After plugging out the displayport of the U2415, the system becomes responsive again. - after a system suspend to ram the same as above happens. With a reboot everything seems normal again, and in the event the U2415 has gone into power save mode during login, switching between VT's will normally get it out off power save. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/tilcdc: Implement dma-buf support for tilcdc
by Jyri Sarha 30 Jun '15

30 Jun '15

There is nothing special about tilcdc HW when the video memory is concerned. Just using the standard drm helpers for implementation is enough. Signed-off-by: Jyri Sarha <jsarha(a)ti.com> --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c index 0f283a3..4908c1f 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c @@ -553,7 +553,8 @@ static const struct file_operations fops = { }; static struct drm_driver tilcdc_driver = { - .driver_features = DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET, + .driver_features = (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET | + DRIVER_PRIME), .load = tilcdc_load, .unload = tilcdc_unload, .preclose = tilcdc_preclose, @@ -571,6 +572,16 @@ static struct drm_driver tilcdc_driver = { .dumb_create = drm_gem_cma_dumb_create, .dumb_map_offset = drm_gem_cma_dumb_map_offset, .dumb_destroy = drm_gem_dumb_destroy, + + .prime_handle_to_fd = drm_gem_prime_handle_to_fd, + .prime_fd_to_handle = drm_gem_prime_fd_to_handle, + .gem_prime_import = drm_gem_prime_import, + .gem_prime_export = drm_gem_prime_export, + .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, + .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, + .gem_prime_vmap = drm_gem_cma_prime_vmap, + .gem_prime_vunmap = drm_gem_cma_prime_vunmap, + .gem_prime_mmap = drm_gem_cma_prime_mmap, #ifdef CONFIG_DEBUG_FS .debugfs_init = tilcdc_debugfs_init, .debugfs_cleanup = tilcdc_debugfs_cleanup, -- 1.9.1

2 1

[PATCH 0/2] I915 GEM context updates
by David Weinehall 30 Jun '15

30 Jun '15

This patch contains a few minor updates related to I915 GEM context. David Weinehall (2): intel: Add get/set context parameter helpers Add the I915_CONTEXT_PARAM_NO_ZEROMAP parameter include/drm/i915_drm.h | 1 + intel/intel_bufmgr.h | 4 ++++ intel/intel_bufmgr_gem.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+) -- 2.1.4

2 3

[PATCH] drm: omapdrm: Use destroy helper in plane reset handler
by Laurent Pinchart 30 Jun '15

30 Jun '15

Call __drm_atomic_helper_plane_destroy_state() in the plane reset handler instead of open-coding it. This will avoid changes to the driver if plane state later gets more fields that need to be reset. Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> --- drivers/gpu/drm/omapdrm/omap_plane.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index cfa8276c4deb..ddcc74a6059d 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -165,8 +165,7 @@ static void omap_plane_reset(struct drm_plane *plane) struct omap_plane *omap_plane = to_omap_plane(plane); struct omap_plane_state *omap_state; - if (plane->state && plane->state->fb) - drm_framebuffer_unreference(plane->state->fb); + __drm_atomic_helper_plane_destroy_state(plane, plane->state); kfree(plane->state); plane->state = NULL; -- Regards, Laurent Pinchart

1 0

[PATCH] drm/radeon: fix adding all VAs to the freed list on remove v2
by Christian König 30 Jun '15

30 Jun '15

From: Christian König <christian.koenig(a)amd.com> We only should do so when the BO_VA was actually mapped. Otherwise we get a nice error message on the next CS. v2: It actually doesn't matter if it was invalidated or not, if it was mapped we need to clear the area where it was mapped. Signed-off-by: Christian König <christian.koenig(a)amd.com> Tested-by: Michel Dänzer <michel.daenzer(a)amd.com> (v1) --- drivers/gpu/drm/radeon/radeon_vm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c index 3662157..ec10533 100644 --- a/drivers/gpu/drm/radeon/radeon_vm.c +++ b/drivers/gpu/drm/radeon/radeon_vm.c @@ -1129,12 +1129,12 @@ void radeon_vm_bo_rmv(struct radeon_device *rdev, interval_tree_remove(&bo_va->it, &vm->va); spin_lock(&vm->status_lock); - if (list_empty(&bo_va->vm_status)) { + list_del(&bo_va->vm_status); + if (bo_va->it.start || bo_va->it.last) { bo_va->bo = radeon_bo_ref(bo_va->bo); list_add(&bo_va->vm_status, &vm->freed); } else { radeon_fence_unref(&bo_va->last_pt_update); - list_del(&bo_va->vm_status); kfree(bo_va); } spin_unlock(&vm->status_lock); -- 1.9.1

3 2

Color management in DRM framework
by Sharma, Shashank 30 Jun '15

30 Jun '15

Hi Rob, Alex, Ben, All :) I am Shashank Sharma, from Linux display team Intel, Bangalore. We are planning to add a color management extension in the existing I915 driver, for Intel HWs. Plan was to provide a color correction and enhancement interface for any Linux based userspace, based on various HW capabilities. We are now thinking that if we can generalize this implementation, in such a way that other drivers can also utilize this, this idea can act as an extension to the DRM framework itself. Based on that thought, We have prepared a design for the same, and a rough implementation based on this design. Would you all be kind enough to have a look at this design, and give us some feedback, so that we can implement this in a way best suitable to most of the drivers ? We have gone through few rounds of design discussions internally (design contributors, reviewers in CC), and we all are moreover agree on the design (few comments still in progress). The highlights of the design: 1. The color correction capabilities of a HW are being registered as a DRM property of a CRTC / Plane (depending on a HW) 2. Properties will be of blob type. 3. New data structures will be added in DRM layer, to encoder and decode color correction and enhancement data. 4. The color correction DRM properties would look like : a. Palette correction / programming based color properties (like gamma correction). This can support various coefficients counts and correction values, based on the underneath HW. b. Color transformation matrix based color correction (CSC, wide and narrow gamut mapping) c. Plane level corrections like gamma correction, hue, saturation, contrast and brightness. d. One blob type property to showcase the color correction capabilities to the userspace, superset of all other color correction properties. 5. The driver's init function can create the superset color property, and show its color capabilities to the userspace. 6. Userspace can query the current color correction Or apply a new color correction using a set/get property interface. Please find the detailed design, in this shared google document: https://docs.google.com/document/d/1jyfNSAStKHEpmIUZd_1Gd68cPuyiyr8wmJXThSD… Please feel free to add more people in the design discussion, once we have some basic agreement on the design, we will share the patches in dri-devel level. Regards Shashank

3 5

[ANNOUNCE] libdrm 2.4.62
by Emil Velikov 29 Jun '15

29 Jun '15

This release introduces the atomic and blob APIs, adds support for new devices (AMD Bonaire) and a new flag for coherent BOs in nouveau. Alex Deucher (1): radeon: add new bonaire pci id Alexandre Courbot (1): nouveau: add coherent BO attribute Boris BREZILLON (2): modetest: add atmel-hlcdc driver support tests/kmstest: support atmel-hlcdc Damien Lespiau (1): intel: Add the Broxton PCI IDs Daniel Stone (1): Add blob property create/destroy ioctl wrappers Emil Velikov (7): modetest: explicitly zero the newly allocated memory modetest: replace malloc + memset with calloc xf86drm: simplify drmMalloc/drmFree Revert "Add device enumeration interface (v4)" xf86drmMode: remove unused valgrind(VG) macros xf86drmMode: include config.h before anything else configure.ac: bump version to 2.4.62 for release Guillaume Desmottes (1): drmPrime*: initialize output args to 0 Ilia Mirkin (1): nouveau: add asserts to make sure krefs are there Jammy Zhou (1): Fix one warning (v2) Matt Turner (1): configure: Add flag to disable valgrind support. Tobias Jakobi (11): modetest: make middle SMPTE colors transparent modetest: only select plane with matching format exynos: fimg2d: fix return codes tests/exynos: replace return by break exynos/fimg2d: simplify g2d_fini() tests/exynos: clean struct connector tests/exynos: remove unused define tests/exynos: remove struct fimg2d_test_case tests/exynos: simplify drm_set_crtc tests/exynos: remove connector_find_plane tests/exynos: handle G2D_IMGBUF_COLOR in switch statements Ville Syrjälä (1): Support atomic modesetting ioctl frank (1): Add device enumeration interface (v4) git tag: libdrm-2.4.62 http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.bz2 MD5: c9291bae0e5ca65d1483821d3698d3ab libdrm-2.4.62.tar.bz2 SHA1: 882b59a372508a301aabd6ba8f8bd124f3a69a16 libdrm-2.4.62.tar.bz2 SHA256: 906c294bdbe1c94c3ca084305d61a6e5a8367f3b4986e6cc13b1e9b3f75931dc libdrm-2.4.62.tar.bz2 PGP: http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.bz2.sig http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.gz MD5: e94fd03ad36b4154b8e10e8f6854f863 libdrm-2.4.62.tar.gz SHA1: 270d8f3f03d605a08af7749e3762d508a3cef7b5 libdrm-2.4.62.tar.gz SHA256: f7df6b73c8d787cdde7e49eae6e761313f606b784051004b1cb2e81bf2d490fa libdrm-2.4.62.tar.gz PGP: http://dri.freedesktop.org/libdrm/libdrm-2.4.62.tar.gz.sig

1 0

drm: imx: multi-display support questions
by Gary Bisson 29 Jun '15

29 Jun '15

Hi all, After a few days of experimentation on multi-display support on i.MX6, I have some questions regarding the status of the imx-drm driver. Here is description of my testing setup: - Nitrogen6x (a SabreLite would work the same) - Mainline kernel 4.1-rc2 + a few patches for display support (some are pending, other are scheduled for 4.2) https://patchwork.kernel.org/project/linux-arm-kernel/list/?submitter=132811 https://patchwork.kernel.org/patch/6439221/ https://patchwork.kernel.org/patch/6439231/ https://patchwork.kernel.org/patch/6212451/ - Available displays: - 1 LVDS 10" Hannstar HSD100PXN1 display - 1 LCD 7" Okaya display - 1 HDMI 1080p TV - U-boot script used to boot the mainline kernel properly: https://github.com/boundarydevices/u-boot-imx6/blob/staging/board/boundary/… - Basic Buildroot filesystem with libdrm and its test binaries First of all, using the standard imx_v6_v7_defconfig, everything runs fine with a single-display setup, no matter if it is using LVDS, RGB or HDMI interface. But in multi-display setup, the first observation is that CONFIG_DRM_IMX_FB_HELPER seems to be problematic. When this option is set, only one display can be used either using the /dev/fb0 or 'modetest -s' from libdrm test binaries. As soon as the option is removed, every display can be used properly with the following commands: # modetest -M imx-drm -s 32:800x480 # modetest -M imx-drm -s 34:1920x1080 # modetest -M imx-drm -s 36:1024x768 Is this option only meant for single-display setup? Has it been tested in multi-display? It seems limited to fb0 creation, would it be possible to make the driver create as many fbs as the number of monitors? Also, when trying to display different patterns on each and every display at once, I have been using the example provided by David Herrmann: https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c This shows a clocking issue when using both DRM_IMX_PARALLEL_DISPLAY and DRM_IMX_LDB at the same time. Although the driver is smart enough to connect ipu1_di0 to the RGB interface and ipu1_di1 to the LVDS interface, the clock set by the LDB driver (65MHz) is overwritten when the parallel interface is enabled as they both share pll5_video. Has anyone successfully tried using both drivers, LVDS and parallel, at the same time? Then I've run into Steve's series that seems to address some clocking issues. http://lists.freedesktop.org/archives/dri-devel/2014-October/070996.html Is there the equivalent series for the driver since it has moved from staging? Hope the above description is sufficient, if needed I can provide modeprint/modetest/clk_summary outputs. Regards, Gary

4 15

[Bug 90728] dvd playback with vlc and vdpau causes segmentation fault
by bugzilla-daemon＠freedesktop.org 29 Jun '15

29 Jun '15

https://bugs.freedesktop.org/show_bug.cgi?id=90728 --- Comment #21 from Christian König <deathsimple(a)vodafone.de> --- (In reply to mehmet.giritli from comment #19) > One question: If you commit this, what is the earliest release which will > contain this fix? I have marked it as "CC: mesa-stable...", so it should show up in the next stable release. But I honestly don't know of hand which release that will be. > Marking this as fixed. As Michel already noted please don't do so. The workflow is that I mark it as fixes as soon as the patch is pushed and you can close it after that acknowledging that the problem is really fixed. Apart from that thanks for the help, that was a really long outstanding issue. -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2015