dri-devel July 2013

dri-devel@lists.freedesktop.org

142 participants
850 discussions

[PATCH] drm/nva3/disp: Fix HDMI audio regression
by Ilia Mirkin 03 Jul '13

03 Jul '13

This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix HDMI audio regression). The regression happened as a result of refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into core). Reported-and-tested-by: Max Baldwin <archerseven(a)gmail.com> Signed-off-by: Ilia Mirkin <imirkin(a)alum.mit.edu> --- The actual testing was done on a NVCF card (550 Ti). Prior to this, AC3/DTS audio passthrough worked, but regular audio did not. With this change, regular audio started to work too. This should probably be sent to stable as well. drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c index f065fc2..db8c6fd 100644 --- a/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c +++ b/drivers/gpu/drm/nouveau/core/engine/disp/hdminva3.c @@ -55,6 +55,10 @@ nva3_hdmi_ctrl(struct nv50_disp_priv *priv, int head, int or, u32 data) nv_wr32(priv, 0x61c510 + soff, 0x00000000); nv_mask(priv, 0x61c500 + soff, 0x00000001, 0x00000001); + nv_mask(priv, 0x61c5d0 + soff, 0x00070001, 0x00010001); /* SPARE, HW_CTS */ + nv_mask(priv, 0x61c568 + soff, 0x00010101, 0x00000000); /* ACR_CTRL, ?? */ + nv_mask(priv, 0x61c578 + soff, 0x80000000, 0x80000000); /* ACR_0441_ENABLE */ + /* ??? */ nv_mask(priv, 0x61733c, 0x00100000, 0x00100000); /* RESETF */ nv_mask(priv, 0x61733c, 0x10000000, 0x10000000); /* LOOKUP_EN */ -- 1.8.1.5

1 0

[PATCH] drm/exynos: add error check routine in exynos_drm_open
by Seung-Woo Kim 03 Jul '13

03 Jul '13

From: YoungJun Cho <yj44.cho(a)samsung.com> When the exynos_drm_subdrv_open() returns error, the file_priv should be released and file->driver_priv set to NULL. Signed-off-by: YoungJun Cho <yj44.cho(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 2762373..ca2729a 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -155,6 +155,7 @@ static int exynos_drm_unload(struct drm_device *dev) static int exynos_drm_open(struct drm_device *dev, struct drm_file *file) { struct drm_exynos_file_private *file_priv; + int ret; file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL); if (!file_priv) @@ -162,7 +163,13 @@ static int exynos_drm_open(struct drm_device *dev, struct drm_file *file) file->driver_priv = file_priv; - return exynos_drm_subdrv_open(dev, file); + ret = exynos_drm_subdrv_open(dev, file); + if (ret) { + kfree(file_priv); + file->driver_priv = NULL; + } + + return ret; } static void exynos_drm_preclose(struct drm_device *dev, -- 1.7.9.5

2 1

[PATCH 2/2] drm/exynos: initialize the buf_num in vp_video_buffer
by Seung-Woo Kim 03 Jul '13

03 Jul '13

From: YoungJun Cho <yj44.cho(a)samsung.com> The buf_num in vp_video_buffer() should be 1 or 2, but it is not initialized, and only set to 2 in NV12M or NV12MT cases. So this patch initializes the buf_num with 1 as default. Signed-off-by: YoungJun Cho <yj44.cho(a)samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index b1280b4..42ffb71 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -379,7 +379,7 @@ static void vp_video_buffer(struct mixer_context *ctx, int win) unsigned long flags; struct hdmi_win_data *win_data; unsigned int x_ratio, y_ratio; - unsigned int buf_num; + unsigned int buf_num = 1; dma_addr_t luma_addr[2], chroma_addr[2]; bool tiled_mode = false; bool crcb_mode = false; -- 1.7.9.5

2 1

[PATCH 1/2] drm/exynos: remove dead code in vidi_power_on
by Seung-Woo Kim 03 Jul '13

03 Jul '13

From: YoungJun Cho <yj44.cho(a)samsung.com> The type of input parameter enable is bool, so it does not need to check whether true or false. Signed-off-by: YoungJun Cho <yj44.cho(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index 784bbce..41cc74d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -413,9 +413,6 @@ static int vidi_power_on(struct vidi_context *ctx, bool enable) struct exynos_drm_subdrv *subdrv = &ctx->subdrv; struct device *dev = subdrv->dev; - if (enable != false && enable != true) - return -EINVAL; - if (enable) { ctx->suspended = false; -- 1.7.9.5

2 1

[PATCH] drm/exynos: fix not to remain exynos_gem_obj as a leak
by Seung-Woo Kim 03 Jul '13

03 Jul '13

From: YoungJun Cho <yj44.cho(a)samsung.com> The exynos_drm_gem_create() only calls drm_gem_object_release() when exynos_drm_alloc_buf() is failed, and exynos_gem_obj remains as a leak, which is allocated in exynos_drm_gem_init(). So this patch fixes it not to remain as a leak. Signed-off-by: YoungJun Cho <yj44.cho(a)samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- This patch is based on exynos-drm-next branch. drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index c3f15e7..24c22a8 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -246,13 +246,14 @@ struct exynos_drm_gem_obj *exynos_drm_gem_create(struct drm_device *dev, exynos_gem_obj->flags = flags; ret = exynos_drm_alloc_buf(dev, buf, flags); - if (ret < 0) { - drm_gem_object_release(&exynos_gem_obj->base); - goto err_fini_buf; - } + if (ret < 0) + goto err_gem_fini; return exynos_gem_obj; +err_gem_fini: + drm_gem_object_release(&exynos_gem_obj->base); + kfree(exynos_gem_obj); err_fini_buf: exynos_drm_fini_buf(dev, buf); return ERR_PTR(ret); -- 1.7.9.5

2 1

[PATCH 0/6] DRM: Unified VMA Offset Manager
by David Herrmann 02 Jul '13

02 Jul '13

Hi I picked up the initial work from Dave [1], fixed several bugs, rewrote the drm_mm node handling and adjusted the different drivers. The series tries to replace the VMA-offset managers from GEM and TTM with a single unified implementation. It uses the TTM RBTree idea to allow sub-mappings (which wouldn't be feasible with hashtables). Changes to Dave's v1: * Fixed a ref-count bug in TTM during object lookup * Use embedded drm_mm_node objects to avoid allocations * Document drm_vma_* API * Reviewed TTM locking * Fixed all new drivers * Use node->vm_pages instead of obj->size for GEM size calculations Notes: * Tested on nouveau only! I will try to test i915 this week. However, the gem changes seem pretty trivial. * I couldn't even compile-test the ARM drivers. However, the omapdrm diffs are the only changes that are non-trivial. Is there any ongoing work to remove the arch-deps in DRM drivers? * _DRM_GEM is no longer used, but I guess we need to keep it for backwards compat? * If we replace node_list in drm_mm with an rbtree, we can drop it from drm_vma_offset_manager completely. However, I wanted to avoid heavy drm_mm changes and left this for follow up patches. * This is currently based on linux-3.10 from today. Next series will be rebased on drm-next/linux-next, but the current -next trees continously break my machines.. But the only changes should be to fix additional drivers. I didn't see any other things to fix for drm-next. Another series, which I will send later, adds "struct file" lists for each drm-vma-offset so we can get access control over gem objects. Also, I have an experimental series to remove the allocation helpers in drm_mm and let drivers embed drm_mm_node instead. Lets see how that works out. Comments welcome! Cheers David [1]: http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-vma-manager David Herrmann (6): drm: make drm_mm_init() return void drm: mm: add drm_mm_node_linked() helper drm: add unified vma offset manager drm: gem: convert to new unified vma manager drm: ttm: convert to unified vma offset manager drm: provide generic drm_vma_node_unmap() helper drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/cirrus/cirrus_main.c | 2 +- drivers/gpu/drm/drm_gem.c | 93 ++---------- drivers/gpu/drm/drm_gem_cma_helper.c | 9 +- drivers/gpu/drm/drm_mm.c | 5 +- drivers/gpu/drm/drm_vma_manager.c | 224 +++++++++++++++++++++++++++++ drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +- drivers/gpu/drm/gma500/gem.c | 8 +- drivers/gpu/drm/i915/i915_gem.c | 13 +- drivers/gpu/drm/mgag200/mgag200_main.c | 2 +- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 11 +- drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 49 +------ drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 5 +- drivers/gpu/drm/ttm/ttm_bo.c | 82 ++--------- drivers/gpu/drm/ttm/ttm_bo_manager.c | 8 +- drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 81 ++++------- drivers/gpu/drm/udl/udl_gem.c | 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +- include/drm/drmP.h | 7 +- include/drm/drm_mm.h | 11 +- include/drm/drm_vma_manager.h | 122 ++++++++++++++++ include/drm/ttm/ttm_bo_api.h | 15 +- include/drm/ttm/ttm_bo_driver.h | 7 +- include/uapi/drm/drm.h | 2 +- 30 files changed, 464 insertions(+), 324 deletions(-) create mode 100644 drivers/gpu/drm/drm_vma_manager.c create mode 100644 include/drm/drm_vma_manager.h -- 1.8.3.2

5 16

Re: [PATCH] drm/radeon/dpm: Add #include <linux/seq_file.h> to *_dpm.c files
by Mike Lothian 02 Jul '13

02 Jul '13

Hi I sent this to the wrong mailing list and it had the wrong patch format Fixed thanks to glisse Cheers Mike On 2 July 2013 21:34, Mike Lothian <mike(a)fireburn.co.uk> wrote: > Hi > > This patch allows me to compile using GCC 4.7.3 system when using ld.bfd - > it doesn't seem to be required on my GCC 4.8.1 system using ld.gold - I'm > not sure why > > Cheers > > Mike >

1 0

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
by Justin Piszcz 02 Jul '13

02 Jul '13

Hello, I use an ATI graphics card (PCI-e x1) for a server: Card: [AMD/ATI] Park [Mobility Radeon HD 5430] I upgraded my kernel from 3.9.x to 3.10, after rebooting I found the driver now wants a new firmware: radeon 0000:05:00.0: radeon_uvd: Can't load firmware "radeon/CYPRESS_uvd.bin" I pulled the latest firmware down (and also updated the others) and rebooted: CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin radeon/CYPRESS_uvd.bin" Then have this issue: [drm] radeon: irq initialized. [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). The screen goes black for ~5 seconds and then come back on. Not sure if this has been reported or not (w/CEDAR chipset) but FYI. Kernel config: http://home.comcast.net/~jpiszcz/20130702/config-3.10-4.txt Full dmesg: http://home.comcast.net/~jpiszcz/20130702/full-dmesg.txt Possibly related: http://lists.opensuse.org/opensuse-bugs/2013-06/msg00053.html https://bugzilla.novell.com/show_bug.cgi?id=822777 https://bugzilla.novell.com/show_bug.cgi?id=822777#c0 http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg38066.html https://bugs.freedesktop.org/show_bug.cgi?id=63935 Snippet: [ 2.033535] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 3.053742] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 4.073985] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 5.094192] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 6.114405] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 7.134611] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 8.154824] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 9.175044] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 10.195251] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.215464] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.235537] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 11.235607] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). Justin.

2 3

[PATCH RFC v4 0/3] Armada DRM driver
by Russell King - ARM Linux 02 Jul '13

02 Jul '13

Quite a number of things has changed since the last revision in the core code - notably the move to use drm_plane for overlay, and the limited and restricted use of dma_buf so that gem objects can be passed to the GALCORE code and libbmm contiguous video frames can be imported into DRM. As I thought, this does require quite a number of new system calls, but the case which I care more about (vlc) doesn't pass rendered frames directly to the X server by physical address, it's not something I'm particularly concerned about - for vlc and the "normal" Xv protocol we can cache four DRM gem objects with their framebuffers pre-prepared meaning we just copy the frame and call the DRM set_plane function. What the loss of the create_phys() interface does mean is that the modified gstreamer gstbmmxvimagesink plugin will not work; it will need to be updated. I do *not* intend to support the hacky bidirectional Xv SHM hack which Marvell came up with there! I've left out the TDA998x changes and the final patch which depends on those changes which add the HDMI output for the cubox, so this series will be lacking the final parts of connector support. It is probable that the patch from the previous series can be trivially applied to this (or easily adapted if not.) Other changes: - the crtc exports a few attributes now for setting the colour transform mode. (CCIR601/709 to Computer vs "Studio" RGB). An automatic mode for these settings provided depending on selected resolution. - overlay has working brightness/contrast/saturation settings, but not hue - not worked that bit out yet. - hardware ARGB cursor support only in this version. - backend ops are now called variants, because the structure started to contain other stuff other than just function pointers. Armada510 backend moved to a separate file. - features requiring the SPU_ADV_REG (only present on Armada 510) can be disabled by the variant structure - such as interlace and ARGB cursor. - use of page_alloc() reduced down to 8K, enough to store the hardware cursor. This is all that that allocation was really used for anyway. - now uses a common kfifo queue to free used framebuffers at the appropriate time, both from the crtc code and the drm_plane code, rather than having this logic in several places. kfifo is a weird API and there's a note in the driver about that. - framebuffers now carry their configuration with them, to save having the pixel format decode scattered in several places in the driver. - power down FIFOs and RAMs not being used, and keep them powered down where possible. - minimum framebuffer size added, moved out from the X server driver. - maximum horizontal resolution dropped to 1920 to avoid a potential problem with V scaling (the RAM is apparantly 1920 pixels by 3 lines.) - protection preventing various gem objects being used in unexpected ways added - eg, you can't create a framebuffer from a cursor gem object or an imported object which is non-contiguous. - full range of colorkey modes for video supported (hey, it's just drm plane properties!) - loads of smaller cleanups, and a number of checkpatch fixes. Things left to do, in no particular order: - Creation of planar YUV formatted framebuffers - I suspect the planar YUV formats are not supported for graphic framebuffers even though Marvell document the register settings. (Where do you program the base addresses of the U and V planes?) Not a high priority as Vmeta produces UYVY encoded frames and it's more efficient to keep the native format. - Gamma support if anyone cares. Again, not high priority. - Resolution of the clocking conundrum. - Resolution of the DT specification conundrum (super-device?) - Specification of DRM connectors (DT but how?), their configuration, what they're connected to and what fixed format(s) they support. - CMA or no CMA - I've added a comment pointing out additional concerns about how to get the physical address from CMA. I think for most platforms this driver will be used on, the device address and physical address will be the same, but _conceptually_ they have never been the same in the kernel. - DCON support... I have no use for this, and the information in my documentation is pretty damned poor, so much so that I'm reluctant to try prodding around with it, especially as some of it is self-contradictory. Anyone who really cares about this can look at the issues there. Stuff omitted: - the DRM refcounting bug fix which breaks the i915 driver (but without it, booting with this driver results in a leaked refcount on the framebuffer thanks what I consider to be a bug in the DRM crtc code.) So don't boot this without something reporting itself as being connected with a valid mode.

7 24

PCI device IDs for device needing the i915 invert_brightness quirk
by Pedro Ângelo 02 Jul '13

02 Jul '13

Dear all, Recently I've come across this article about a probable fix for my laptop's black screen on boot: http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_dea… I've tried the fix and it works perfectly so I'm contacting you as directed in the above article to send the PCI device IDs of the integrated graphics card of the laptop in question for future inclusion in the driver. The laptop is an HP Envy 14 2020, the output of lspci -vvnn for the graphics card is: ---- 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device [103c:3385] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 52 Region 0: Memory at c8000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at b0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 4000 [size=64] Expansion ROM at <unassigned> [disabled]T Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: feeff00c Data: 41c1 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 ---- Best regards, Pedro Ângelo

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2013