dri-devel May 2013

dri-devel@lists.freedesktop.org

116 participants
705 discussions

[PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410
by Tomasz Figa 10 Jun '13

10 Jun '13

Much of the code in Exynos DRM subsystem is generic enough to use it for older (non-Exynos) Samsung SoCs as well, after minor modifications. This series starts adding support for previous SoCs to Exynos DRM by introducing S3C64xx support to exynos_drm_fimd driver. Adding support for remaining SoCs between S3C64xx and Exynos4 (S5PC100, S5P64x0 and S5PV210) should be rather straightforward, but at the moment I can test only on S3C6410, so I limited my changes only to this SoC. On Tiny6410 (Mini6410-compatible) board based on Samsung S3C6410 SoC, using my to-be-resubmitted patches for Device Tree support: Tested-by: Tomasz Figa <tomasz.figa(a)gmail.com> Tomasz Figa (4): drm/exynos: fimd: Hold pointer to driver data in context struct drm/exynos: fimd: Add support for FIMD versions without SHADOWCON register drm/exynos: fimd: Add support for FIMD variants with clock selection drm/exynos: fimd: Add support for S3C64xx SoCs drivers/gpu/drm/exynos/exynos_drm_fimd.c | 90 ++++++++++++++++++++++++-------- 1 file changed, 68 insertions(+), 22 deletions(-) -- 1.8.2.1

3 8

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting
by Seung-Woo Kim 10 Jun '13

10 Jun '13

importer private data in dma-buf attachment can be used by importer to reimport same dma-buf. Seung-Woo Kim (2): dma-buf: add importer private data to attachment drm/prime: find gem object from the reimported dma-buf drivers/base/dma-buf.c | 31 ++++++++++++++++++++++++++++ drivers/gpu/drm/drm_prime.c | 19 ++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 + drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 + drivers/gpu/drm/udl/udl_gem.c | 1 + include/linux/dma-buf.h | 4 +++ 6 files changed, 52 insertions(+), 5 deletions(-) -- 1.7.4.1

6 15

[Bug 36602] New: Hierarchical Z support for R600
by bugzilla-daemon＠freedesktop.org 08 Jun '13

08 Jun '13

https://bugs.freedesktop.org/show_bug.cgi?id=36602 Summary: Hierarchical Z support for R600 Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: pelloux(a)gmail.com Add Hierarchical Z (HiZ) support for r600g driver. I'm attaching my work-in-progress patchs to this bug report to keep track of comments. This patch adds 3 new env vars : - R600_EARLYZ : controls whether EarlyZ functionnality is used (DB_SHADER_CONTROL register) - R600_HIZ : HiZ enabled/disabled - R600_HIZ_READ_HACK : this one is a quick hack for debugging HiZ data buffer. If set, data will be read from HiZ bo instead of depth buffer bo when calling glReadPixels( ... GL_DEPTH_COMPONENT ...) General notes on HiZ on r600 : (all testing done using : ATI Technologies Inc RV770 [Radeon HD 4850]) * HiZ buffer is made of DWORD entries. Each DWORD represents one tile (4x4 or 8x8 pixels depending DB_HTILE_SURFACE register fields) * HiZ buffer does not need to be manually cleared by the driver * DB_RENDER_CONTROL:RESUMMARIZE_ENABLE bit is not necessary to get it working - but if enabled it slows things down * application performance are roughly the same using R600_EARLYZ or R600_HIZ Know problems : * Hierarchical Stencil has not been tested * HiZ buffer data layout is still unclear. As an example : using 640x640 window and 8x8 tiles. HiZ buffer should contain (640/8)*(640/8) = 6400 entries. When reading it back using the above hack, it contains 6400 entries but spread on the 7680 first dwords of the buffer. Therefore HiZ bo if largely oversized for now (ie = depth buffer size) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 55

Introduce a new helper framework for buffer synchronization
by Inki Dae 07 Jun '13

07 Jun '13

Hi all, This post introduces a new helper framework based on dma fence. And the purpose of this post is to collect other opinions and advices before RFC posting. First of all, this helper framework, called fence helper, is in progress yet so might not have enough comments in codes and also might need to be more cleaned up. Moreover, we might be missing some parts of the dma fence. However, I'd like to say that all things mentioned below has been tested with Linux platform and worked well. The below link is fence helper codes, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/… And fence helper is based on the below patches, http://lists.freedesktop.org/archives/dri-devel/2013-January/033430.html Fence helper includes easy-to-use user and kernel interfaces for applying a buffer synchronization mechanism into device driver and user space. And the below link is example codes for device drivers, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/… And also the below link is user interface relevant codes for user process, https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/… The dma fence framework[1] had already been posted by Maarten and Rob. And the dma fence is used with reservation framework. Simple mechanism of the dma fence is as the followings, 1. one dmabuf has one reservation object when one buffer is exported into a dmabuf. 2. a thread creates its own fence object and sets the fence object to a reservation object of a dmabuf: a dmabuf is a buffer a thread wants accessing. 3. dma fence provides fence_default_wait() to block a thread and fence_signal() to wake up a thread: a thread is blocked once trying to access a shared buffer if another fence object had already been set to a reservation object of a shared buffer. And then a blocked thread is waked up by a owner when the owner- the owner is a thread accessing the shared buffer - signals the shared buffer. PS. Know that all buffers to be shared should be exported into dmabuf fd. However, dma fence just provides basic interfaces for buffer synchronization between DMA and DMA. Therefore developers should consider how interfaces of the dma fence should be called and also the resources of the dma fence should be managed. Thus, it might not be easy to apply the dma fence framework into their device drivers. Moreover, we need user interfaces for buffer synchronization between CPU and DMA. For example, we cannot aware of when and how CPU tries to access a shared buffer. So user applications need to notify the fact to dma fence framework so that the dma fence framework can synchronize the shared buffer between CPU and DMA. Fence helper includes the following features and interfaces. Features. 1. provide optimized buffer synchronization method - we need to check if a thread tried to access buffer with READ or WRITE, and if a thread tries to access same buffer with READ or WRITE. The reason is that we can avoid unnecessary read-lock by buffer synchronization and perform proper cache operation. 2. provide buffer synchronization to READ, WRITE and DMA access - Fence helper has three access types: READ, WRITE, and DMA. And these types can be compounded like below, READ, WRITE, READ | DMA or WRITE | DMA. 3. provide user interfaces for buffer synchronization between CPU and DMA - Fence helper provides user interfaces and the user interfaces has been implemented in dma-buf framework. User application can call these interfaces before and after cpu access. 4. provide cache control method - Fence helper performs proper cache operation looking before and after of CPU and DMA access. Actual cache operation is done just before committing a fence after memory access by CPU or DMA was completed. For cache operation, dma-buf interfaces, dma_buf_begin_cpu_access() and dma_buf_end_cpu_access(), are used. 5. provide easy-to-use user and kernel interfaces - Fence helper has four exported interfaces: these can be called by device driver and user application like below, Interfaces. fence_helper_init() - this function creates a new fence helper object internally and returns the fence helper object. fence_helper_init_reserve() - this function sets up a shard buffer into the fence helper object. And mutiple shared buffers can be set to there. fence_helper_commit_reserve() - this function synchronizes a shared buffer checking fence helper objects already committeds and commits a fence helper object to a shared buffer. The checking means that a caller waits for all threads, which committed their fence helper objects, signal the shared buffer. And the commit means that the caller is using a shared buffer so the shared buffer access by another thread isn't permitted: any thread trying to access the shared buffer will be blocked until a owner signals the shared buffer. fence_helper_signal() - this function signals a shared buffer. This means that the shared buffer access by a caller has been completed so other threads can access the shared buffer. at this moment, if there are blocked threads, they are waked up and then they commit their fences to the same shared buffer: they was blocked at fence_helper_commit_reserve() so are waked up at there. And tutorial. when setting up dma relevant registers struct fence_helper *fh; fh = fence_helper_init(NULL, NULL); fence_helper_init_reserve(fh, dmabuf, WRITE or READ or DMA); just before dma start fence_helper_commit_reserve(fh); after the completion of dma operation fence_helper_signal(fh); User interfaces. DMA_BUF_GET_FENCE - this ioctl command performs the above 1-3 steps of interfaces. a fence helper object is created by fence_helper_init() and a pointer of the fence helper object is passed to user. DMA_BUF_PUT_FENCE - this ioctl command performs the above 4 step of interfaces. the pointer made of step 1 is passed into kernel through this ioctl command. And tutorial for user process. just before cpu access struct dma_buf_fence *df; df->type = DMA_BUF_ACCESS_READ or DMA_BUF_ACCESS_WRITE; ioctl(fd, DMA_BUF_GET_FENCE, &df); after memset or memcpy ioctl(fd, DMA_BUF_PUT_FENCE, &df); Resource management. Basically, a fence helper object is created and released internally; created at fence_helper_init() and released at fence_helper_signal(). And also this can be done case by case like below, - If there was any thread blocked, its own resource is released at fence_helper_commit_reserve() after the thread was waked up. - If a blocked thread was timed out without fence_helper_singal() call; anyone hasn't signaled a shared buffer, its own resource is released at fence_helper_commit_reserve(). - if a shared buffer access by a thread was completed without blocked, its own resource is released at fence_helper_signal(). References. [1] http://lists.freedesktop.org/archives/dri-devel/2013-January/033436.html [2] http://lists.freedesktop.org/archives/dri-devel/2013-January/033434.html Thanks, Inki Dae

5 39

[PATCH] drm/exynos: fimd: Get signal polarities from device tree
by Tomasz Figa 07 Jun '13

07 Jun '13

This patch modifies the driver to perform two stage parsing of video timings from device tree, to get timing information as struct videomode, which contains more data than struct fb_videomode. Thanks to this change, information about polarity of control signals (VSYNC, HSYNC, VDEN, VCLK) can be retrieved, in addition to standard video timings. Signed-off-by: Tomasz Figa <tomasz.figa(a)gmail.com> --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index a1669d4..9023efa 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -21,7 +21,9 @@ #include <linux/pm_runtime.h> #include <video/of_display_timing.h> +#include <video/of_videomode.h> #include <video/samsung_fimd.h> +#include <video/videomode.h> #include <drm/exynos_drm.h> #include "exynos_drm_drv.h" @@ -928,18 +930,30 @@ static int fimd_probe(struct platform_device *pdev) DRM_DEBUG_KMS("%s\n", __FILE__); if (pdev->dev.of_node) { + struct videomode vm; + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); if (!pdata) { DRM_ERROR("memory allocation for pdata failed\n"); return -ENOMEM; } - ret = of_get_fb_videomode(dev->of_node, &pdata->panel.timing, - OF_USE_NATIVE_MODE); + ret = of_get_videomode(dev->of_node, &vm, OF_USE_NATIVE_MODE); if (ret) { DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret); return ret; } + + fb_videomode_from_videomode(&vm, &pdata->panel.timing); + + if (vm.flags & DISPLAY_FLAGS_VSYNC_LOW) + pdata->vidcon1 |= VIDCON1_INV_VSYNC; + if (vm.flags & DISPLAY_FLAGS_HSYNC_LOW) + pdata->vidcon1 |= VIDCON1_INV_HSYNC; + if (vm.flags & DISPLAY_FLAGS_DE_LOW) + pdata->vidcon1 |= VIDCON1_INV_VDEN; + if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE) + pdata->vidcon1 |= VIDCON1_INV_VCLK; } else { pdata = pdev->dev.platform_data; if (!pdata) { -- 1.8.2.1

3 6

[PATCH 1/3] drm/gma500: Unpin framebuffer when destroying it
by Patrik Jakobsson 05 Jun '13

05 Jun '13

A framebuffer is pinned when it's set as pipe base, so we also need to unpin it when it's destroyed. Some framebuffers are never used as scanout (no mode set on them) so if the pin count is less than one, no unpinning is needed. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=889511 Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=812113 Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> --- drivers/gpu/drm/gma500/framebuffer.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 8b1b6d9..1a11b69 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -668,6 +668,11 @@ static void psb_user_framebuffer_destroy(struct drm_framebuffer *fb) /* Let DRM do its clean up */ drm_framebuffer_cleanup(fb); + + /* Unpin any psb_intel_pipe_set_base() pinning */ + if (r->in_gart > 0) + psb_gtt_unpin(r); + /* We are no longer using the resource in GEM */ drm_gem_object_unreference_unlocked(&r->gem); kfree(fb); -- 1.8.1.2

2 4

[REGRESSION] nouveau: Memory corruption using nva3 engine for 0xaf
by Henrik Rydberg 04 Jun '13

04 Jun '13

Hi Ben, Dave, Since 3.5-rc0, I have been experiencing occasional screen corruption on my MacBookAir3,1, using a GeForce 320M (nv50, 0xaf). The X driver version is xf86-video-nouvea-1.0.1-1 (arch). I do not know what the root problem is, but I have been able to isolate the symptoms to the usage of nva3_copy.c. The patch below is the least intrusive way I could find which kills the symptoms. Hopefully this will sched some light on the true problem, such that a fix can be found for 3.5. Thanks, Henrik The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. --- drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 19706f0..b466937 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/drm/nouveau/nouveau_state.c @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) case 0xa3: case 0xa5: case 0xa8: - case 0xaf: nva3_copy_create(dev); break; }

4 7

[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"
by Maarten Maathuis 04 Jun '13

04 Jun '13

My NV96 does not resume from suspend to ram (the screen stays black, magic sysrq keys do work) with the current linus git kernel, i bisected it to the following commit. drm/nv50/fifo: prevent races between clients updating playlists b5096566f6e1ee2b88324772f020ae9bc0cfa9a0 It's not obvious to me how this causes problems, but reverting this commit does solve my problem. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say.

4 4

[PATCH] video: display_timing: make parameter const
by Lucas Stach 04 Jun '13

04 Jun '13

From: Steffen Trumtrar <s.trumtrar(a)pengutronix.de> As the device_node pointer is not changed in of_get_display_timing and parse_timing_property it can be a const pointer. Signed-off-by: Steffen Trumtrar <s.trumtrar(a)pengutronix.de> --- drivers/video/of_display_timing.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c index 56009bc..85c1a41 100644 --- a/drivers/video/of_display_timing.c +++ b/drivers/video/of_display_timing.c @@ -23,7 +23,7 @@ * Every display_timing can be specified with either just the typical value or * a range consisting of min/typ/max. This function helps handling this **/ -static int parse_timing_property(struct device_node *np, const char *name, +static int parse_timing_property(const struct device_node *np, const char *name, struct timing_entry *result) { struct property *prop; @@ -56,7 +56,8 @@ static int parse_timing_property(struct device_node *np, const char *name, * of_get_display_timing - parse display_timing entry from device_node * @np: device_node with the properties **/ -static struct display_timing *of_get_display_timing(struct device_node *np) +static struct display_timing *of_get_display_timing(const struct device_node + *np) { struct display_timing *dt; u32 val = 0; -- 1.7.10.4

2 1

[i915] Backlight brighter since 3.9.0
by Jan Hinnerk Stosch 03 Jun '13

03 Jun '13

Hallo, I hope this is the right place to ask, because I actually don't know whether it is a bug or a feature that I'm experiencing since linux 3.9: When I boot my system the backlight gets extremely bright compared to older kernel versions. It is most obvious when I leave X (more a yellow than a black background), but I have the impression, that the colors in X are brighter than usual, too. I used my spare time this afternoon to do a kernel bisect and learned that the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I don't have insight or understanding of the code: Is this behaviour intended and how could I change it to the old state or is it a bug and should I report it somewhere? My system is as follows: Intel i5-3570k with Intel HD 4000 my monitor is connected via HDMI. If you need any more information just tell me. Thanks in advance, jhs

5 9

← Newer
1
...
46
47
48
49
50
51
52
...
71
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2013