dri-devel February 2013

dri-devel@lists.freedesktop.org

130 participants
696 discussions

gl.h: Version mumbo-jumbo and Copyright?
by Sedat Dilek 14 Feb '13

14 Feb '13

Hi, noticed when polishing up my build-scripts fot libdrm | mesa | xf86-video-intel (last one requires gl.h). /* * Mesa 3-D graphics library * Version: 7.6 <--- ??? * * Copyright (C) 1999-2006 Brian Paul All Rights Reserved. <--- ??? * Copyright (C) 2009 VMware, Inc. All Rights Reserved. ... Regards, - Sedat - http://cgit.freedesktop.org/mesa/mesa/tree/include/GL/gl.h#n3

3 3

[Bug 60073] New: [bisected] Bad rendering in Path of Exile
by bugzilla-daemon＠freedesktop.org 14 Feb '13

14 Feb '13

https://bugs.freedesktop.org/show_bug.cgi?id=60073 Priority: medium Bug ID: 60073 Assignee: dri-devel(a)lists.freedesktop.org Summary: [bisected] Bad rendering in Path of Exile Severity: normal Classification: Unclassified OS: Linux (All) Reporter: nissarin(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Hardware: Radeon 6850 Software: 64bit Gentoo, game running via Wine (32bit), git versions of libdrm, xf86-video-ati, kernel version 3.7(ish) and latest 3.8 rc + drm-next branch The issue is affecting light effects, spell effects, etc. (see screenshots). Bisecting leads to this commit: commit 3b51d71c8544ee198008bbf3545bf3def6e9e77f Author: Jordan Justen <jordan.l.justen(a)intel.com> Date: Fri Dec 28 11:00:50 2012 -0800 copyteximage: check that sRGB usage is valid for GLES3 / GL Reviewed-by: Ian Romanick <ian.d.romanick(a)intel.com> Signed-off-by: Jordan Justen <jordan.l.justen(a)intel.com> There is already one bug report mentioning this commit [1], not sure if it's the same issue. Besides PoE, I also encontered similar problem in StarCraft2, I didn't checked if it's the same problem, text/fonts on the loading screen shows the same "corruption", however the game also hangs the GPU, so bisecting it might be a bit problematic. [1] https://bugs.freedesktop.org/show_bug.cgi?id=59690 -- You are receiving this mail because: You are the assignee for the bug.

1 8

[PATCH v2 1/2] [media] s5p-g2d: Add DT based discovery support
by Sachin Kamat 14 Feb '13

14 Feb '13

This patch adds device tree based discovery support to G2D driver Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- Based on for_v3.9 branch of below tree: git://linuxtv.org/snawrocki/samsung.git Changes since v1: * Addressed review comments from Sylwester <s.nawrocki(a)samsung.com>. * Modified the compatible string as per the discussions at [1]. [1] https://patchwork1.kernel.org/patch/2045821/ --- drivers/media/platform/s5p-g2d/g2d.c | 31 +++++++++++++++++++++++++++++-- 1 files changed, 29 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-g2d/g2d.c b/drivers/media/platform/s5p-g2d/g2d.c index 7e41529..6923be2 100644 --- a/drivers/media/platform/s5p-g2d/g2d.c +++ b/drivers/media/platform/s5p-g2d/g2d.c @@ -18,6 +18,7 @@ #include <linux/slab.h> #include <linux/clk.h> #include <linux/interrupt.h> +#include <linux/of.h> #include <linux/platform_device.h> #include <media/v4l2-mem2mem.h> @@ -695,11 +696,14 @@ static struct v4l2_m2m_ops g2d_m2m_ops = { .unlock = g2d_unlock, }; +static const struct of_device_id exynos_g2d_match[]; + static int g2d_probe(struct platform_device *pdev) { struct g2d_dev *dev; struct video_device *vfd; struct resource *res; + const struct of_device_id *of_id; int ret = 0; dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); @@ -796,7 +800,17 @@ static int g2d_probe(struct platform_device *pdev) } def_frame.stride = (def_frame.width * def_frame.fmt->depth) >> 3; - dev->variant = g2d_get_drv_data(pdev); + + if (!pdev->dev.of_node) { + dev->variant = g2d_get_drv_data(pdev); + } else { + of_id = of_match_node(exynos_g2d_match, pdev->dev.of_node); + if (!of_id) { + ret = -ENODEV; + goto unreg_video_dev; + } + dev->variant = (struct g2d_variant *)of_id->data; + } return 0; @@ -837,13 +851,25 @@ static int g2d_remove(struct platform_device *pdev) } static struct g2d_variant g2d_drvdata_v3x = { - .hw_rev = TYPE_G2D_3X, + .hw_rev = TYPE_G2D_3X, /* Revision 3.0 for S5PV210 and Exynos4210 */ }; static struct g2d_variant g2d_drvdata_v4x = { .hw_rev = TYPE_G2D_4X, /* Revision 4.1 for Exynos4X12 and Exynos5 */ }; +static const struct of_device_id exynos_g2d_match[] = { + { + .compatible = "samsung,s5pv210-g2d", + .data = &g2d_drvdata_v3x, + }, { + .compatible = "samsung,exynos4212-g2d", + .data = &g2d_drvdata_v4x, + }, + {}, +}; +MODULE_DEVICE_TABLE(of, exynos_g2d_match); + static struct platform_device_id g2d_driver_ids[] = { { .name = "s5p-g2d", @@ -863,6 +889,7 @@ static struct platform_driver g2d_pdrv = { .driver = { .name = G2D_NAME, .owner = THIS_MODULE, + .of_match_table = exynos_g2d_match, }, }; -- 1.7.4.1

5 15

[PATCH 1/3] arch: make __mutex_fastpath_lock_retval return whether fastpath succeeded or not.
by Maarten Lankhorst 14 Feb '13

14 Feb '13

This will allow me to call functions that have multiple arguments if fastpath fails. This is required to support ticket mutexes, because they need to be able to pass an extra argument to the fail function. Originally I duplicated the functions, by adding __mutex_fastpath_lock_retval_arg. This ended up being just a duplication of the existing function, so a way to test if fastpath was called ended up being better. This also cleaned up the reservation mutex patch some by being able to call an atomic_set instead of atomic_xchg, and making it easier to detect if the wrong unlock function was previously used. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- arch/ia64/include/asm/mutex.h | 10 ++++------ arch/powerpc/include/asm/mutex.h | 10 ++++------ arch/sh/include/asm/mutex-llsc.h | 4 ++-- arch/x86/include/asm/mutex_32.h | 11 ++++------- arch/x86/include/asm/mutex_64.h | 11 ++++------- include/asm-generic/mutex-dec.h | 10 ++++------ include/asm-generic/mutex-null.h | 2 +- include/asm-generic/mutex-xchg.h | 10 ++++------ kernel/mutex.c | 32 ++++++++++++++------------------ 9 files changed, 41 insertions(+), 59 deletions(-) diff --git a/arch/ia64/include/asm/mutex.h b/arch/ia64/include/asm/mutex.h index bed73a6..f41e66d 100644 --- a/arch/ia64/include/asm/mutex.h +++ b/arch/ia64/include/asm/mutex.h @@ -29,17 +29,15 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns. + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(ia64_fetchadd4_acq(count, -1) != 1)) - return fail_fn(count); + return -1; return 0; } diff --git a/arch/powerpc/include/asm/mutex.h b/arch/powerpc/include/asm/mutex.h index 5399f7e..127ab23 100644 --- a/arch/powerpc/include/asm/mutex.h +++ b/arch/powerpc/include/asm/mutex.h @@ -82,17 +82,15 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns. + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(__mutex_dec_return_lock(count) < 0)) - return fail_fn(count); + return -1; return 0; } diff --git a/arch/sh/include/asm/mutex-llsc.h b/arch/sh/include/asm/mutex-llsc.h index 090358a..dad29b6 100644 --- a/arch/sh/include/asm/mutex-llsc.h +++ b/arch/sh/include/asm/mutex-llsc.h @@ -37,7 +37,7 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) } static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { int __done, __res; @@ -51,7 +51,7 @@ __mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) : "t"); if (unlikely(!__done || __res != 0)) - __res = fail_fn(count); + __res = -1; return __res; } diff --git a/arch/x86/include/asm/mutex_32.h b/arch/x86/include/asm/mutex_32.h index 03f90c8..b7f6b34 100644 --- a/arch/x86/include/asm/mutex_32.h +++ b/arch/x86/include/asm/mutex_32.h @@ -42,17 +42,14 @@ do { \ * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if it - * wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or 1 otherwise. */ -static inline int __mutex_fastpath_lock_retval(atomic_t *count, - int (*fail_fn)(atomic_t *)) +static inline int __mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_dec_return(count) < 0)) - return fail_fn(count); + return -1; else return 0; } diff --git a/arch/x86/include/asm/mutex_64.h b/arch/x86/include/asm/mutex_64.h index 68a87b0..2c543ff 100644 --- a/arch/x86/include/asm/mutex_64.h +++ b/arch/x86/include/asm/mutex_64.h @@ -37,17 +37,14 @@ do { \ * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ -static inline int __mutex_fastpath_lock_retval(atomic_t *count, - int (*fail_fn)(atomic_t *)) +static inline int __mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_dec_return(count) < 0)) - return fail_fn(count); + return -1; else return 0; } diff --git a/include/asm-generic/mutex-dec.h b/include/asm-generic/mutex-dec.h index f104af7..d4f9fb4 100644 --- a/include/asm-generic/mutex-dec.h +++ b/include/asm-generic/mutex-dec.h @@ -28,17 +28,15 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if - * it wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns. + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_dec_return(count) < 0)) - return fail_fn(count); + return -1; return 0; } diff --git a/include/asm-generic/mutex-null.h b/include/asm-generic/mutex-null.h index e1bbbc7..efd6206 100644 --- a/include/asm-generic/mutex-null.h +++ b/include/asm-generic/mutex-null.h @@ -11,7 +11,7 @@ #define _ASM_GENERIC_MUTEX_NULL_H #define __mutex_fastpath_lock(count, fail_fn) fail_fn(count) -#define __mutex_fastpath_lock_retval(count, fail_fn) fail_fn(count) +#define __mutex_fastpath_lock_retval(count, fail_fn) (-1) #define __mutex_fastpath_unlock(count, fail_fn) fail_fn(count) #define __mutex_fastpath_trylock(count, fail_fn) fail_fn(count) #define __mutex_slowpath_needs_to_unlock() 1 diff --git a/include/asm-generic/mutex-xchg.h b/include/asm-generic/mutex-xchg.h index c04e0db..f169ec0 100644 --- a/include/asm-generic/mutex-xchg.h +++ b/include/asm-generic/mutex-xchg.h @@ -39,18 +39,16 @@ __mutex_fastpath_lock(atomic_t *count, void (*fail_fn)(atomic_t *)) * __mutex_fastpath_lock_retval - try to take the lock by moving the count * from 1 to a 0 value * @count: pointer of type atomic_t - * @fail_fn: function to call if the original value was not 1 * - * Change the count from 1 to a value lower than 1, and call <fail_fn> if it - * wasn't 1 originally. This function returns 0 if the fastpath succeeds, - * or anything the slow path function returns + * Change the count from 1 to a value lower than 1. This function returns 0 + * if the fastpath succeeds, or -1 otherwise. */ static inline int -__mutex_fastpath_lock_retval(atomic_t *count, int (*fail_fn)(atomic_t *)) +__mutex_fastpath_lock_retval(atomic_t *count) { if (unlikely(atomic_xchg(count, 0) != 1)) if (likely(atomic_xchg(count, -1) != 1)) - return fail_fn(count); + return -1; return 0; } diff --git a/kernel/mutex.c b/kernel/mutex.c index a307cc9..5ac4522 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -350,10 +350,10 @@ __mutex_unlock_slowpath(atomic_t *lock_count) * mutex_lock_interruptible() and mutex_trylock(). */ static noinline int __sched -__mutex_lock_killable_slowpath(atomic_t *lock_count); +__mutex_lock_killable_slowpath(struct mutex *lock); static noinline int __sched -__mutex_lock_interruptible_slowpath(atomic_t *lock_count); +__mutex_lock_interruptible_slowpath(struct mutex *lock); /** * mutex_lock_interruptible - acquire the mutex, interruptible @@ -371,12 +371,12 @@ int __sched mutex_lock_interruptible(struct mutex *lock) int ret; might_sleep(); - ret = __mutex_fastpath_lock_retval - (&lock->count, __mutex_lock_interruptible_slowpath); - if (!ret) + ret = __mutex_fastpath_lock_retval(&lock->count); + if (likely(!ret)) { mutex_set_owner(lock); - - return ret; + return 0; + } else + return __mutex_lock_interruptible_slowpath(lock); } EXPORT_SYMBOL(mutex_lock_interruptible); @@ -386,12 +386,12 @@ int __sched mutex_lock_killable(struct mutex *lock) int ret; might_sleep(); - ret = __mutex_fastpath_lock_retval - (&lock->count, __mutex_lock_killable_slowpath); - if (!ret) + ret = __mutex_fastpath_lock_retval(&lock->count); + if (likely(!ret)) { mutex_set_owner(lock); - - return ret; + return 0; + } else + return __mutex_lock_killable_slowpath(lock); } EXPORT_SYMBOL(mutex_lock_killable); @@ -404,18 +404,14 @@ __mutex_lock_slowpath(atomic_t *lock_count) } static noinline int __sched -__mutex_lock_killable_slowpath(atomic_t *lock_count) +__mutex_lock_killable_slowpath(struct mutex *lock) { - struct mutex *lock = container_of(lock_count, struct mutex, count); - return __mutex_lock_common(lock, TASK_KILLABLE, 0, NULL, _RET_IP_); } static noinline int __sched -__mutex_lock_interruptible_slowpath(atomic_t *lock_count) +__mutex_lock_interruptible_slowpath(struct mutex *lock) { - struct mutex *lock = container_of(lock_count, struct mutex, count); - return __mutex_lock_common(lock, TASK_INTERRUPTIBLE, 0, NULL, _RET_IP_); } #endif

3 5

[PATCH] drm/exynos: modify condition in mixer and hdmi resume
by Rahul Sharma 14 Feb '13

14 Feb '13

From: Prathyush K <prathyush.k(a)samsung.com> If mixer is runtime suspended (by DPMS OFF), mixer_suspend does not call mixer_poweroff and just returns. Similarily the mixer_resume should not resume the mixer if mixer is runtime_suspended. It should be done through DPMS ON. The existing check is stopping the resume. This issue is fixed by reversing the condiftion. It also holds good for hdmi driver. Inline with http://lists.freedesktop.org/archives/dri-devel/2013-January/032920.html. Signed-off-by: Prathyush K <prathyush.k(a)samsung.com> Signed-off-by: Rahul Sharma <rahul.sharma(a)samsung.com> --- It is based on exynos-drm-next-todo branch at git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/exynos/exynos_mixer.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index 9e3c2ad..273a6ea 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2386,7 +2386,7 @@ static int hdmi_resume(struct device *dev) enable_irq(hdata->external_irq); enable_irq(hdata->internal_irq); - if (!pm_runtime_suspended(dev)) { + if (pm_runtime_suspended(dev)) { DRM_DEBUG_KMS("%s : Already resumed\n", __func__); return 0; } diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 5139a43..6404f7e4 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1265,7 +1265,7 @@ static int mixer_resume(struct device *dev) DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__); - if (!pm_runtime_suspended(dev)) { + if (pm_runtime_suspended(dev)) { DRM_DEBUG_KMS("%s : Already resumed\n", __func__); return 0; } -- 1.8.0

1 0

[RFC v2 0/3] Support Common Display Framework on Exynos5 SoC
by Vikas Sajjan 14 Feb '13

14 Feb '13

changes since v1: Since v1 was not tested when I posted it, now that I have the s6e8aa0 panel, I tested the same on Exynos5 SoC. Needed to make below mentioned changes to make it work. In exynos mipi driver: 1> added "enable_hs" as part of "dsi_video_source_ops", as this function needs to be called from the s6e8aa0 panel probe after LCD "power_on". 2> moved the call exynos_mipi_dsi_set_hs_enable() out of the exynos_mipi_update_cfg() function as it needs to be called only after the LCD "power_on". hence in s6e8aa0 probe added call "enable_hs" after "power_on". otherwise DSI COMMAND TIME OUT error occurs, after sending WRITE COMMAND. Prior to CDF changes, things used to work fine, as the panel used to register with MIPI DSIM driver and in the MIPI DSI probe used to call LCD "power_on" first and then "exynos_mipi_dsi_set_hs_enable". Since the CDF support is introduced, the both panel and mipi dsi probe happens independently and DSI COMMAND TIME OUT error used to occurs, after sending WRITE COMMAND. by making above mentioned changes it started working. In s6e8ax0 driver: 1> added call "enable_hs" in probe after "power_on", to over come above mentioned error. 2> addd init_lcd(), the missing sequence to initialise the lcd. This patch series contains 3 patches with the following changes is based on CDF-T proposed by Tomi Valkeinen <tomi.valkeinen(a)ti.com> http://lwn.net/Articles/529489/ [PATCH 1/3] video: display: Adding frame related ops to MIPI DSI video source struct Adds the frame related ops to the MIPI DSI video source struct [PATCH 2/3] video: exynos: mipi dsi: Making Exynos MIPI Compliant with CDF Makes the Exynos MIPI DSI driver compliant with CDF. [PATCH 3/3] video: exynos: Making s6e8ax0 panel driver compliant with CDF Makes the Exynos s6e8ax0 panel driver compliant with CDF. Have made necessary changes in s6e8ax0 panel driver, made an effort to remove dependency on backlight and lcd framework, but its NOT fully done. s6e8ax0_get_brightness() and s6e8ax0_set_brightness() functionalities have NOT been modified. as backlight support in CDF are _NOT_ implemented yet. Thought of adding these "get and set" as part of display_entity_control_ops(), but didn't modify as of now. Any thoughts on the same will be helpful. removed the lcd_ops "set_power and get_power" and added as part of panel_set_state. Testing: Tested on Exynos5 SoC with s6e8aa0 panel connected, by applying some of the dependent patches Could see the linux logo and ran "modetest" application and saw the test pattern on display panel. Vikas Sajjan (3): video: display: Adding frame related ops to MIPI DSI video source struct video: exynos: mipi dsi: Making Exynos MIPI Compliant with CDF video: exynos: Making s6e8ax0 panel driver compliant with CDF drivers/video/exynos/exynos_mipi_dsi.c | 197 ++---- drivers/video/exynos/exynos_mipi_dsi_common.c | 22 +- drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +- drivers/video/exynos/s6e8ax0.c | 848 +++++++++++++------------ include/video/display.h | 6 + include/video/exynos_mipi_dsim.h | 5 +- 6 files changed, 519 insertions(+), 571 deletions(-) -- 1.7.9.5

2 5

CDF meeting @FOSDEM report
by Laurent Pinchart 14 Feb '13

14 Feb '13

Hello, We've hosted a CDF meeting at the FOSDEM on Sunday morning. Here's a summary of the discussions. I would like to start with a big thank to UrLab, the ULB university hacker space, for providing us with a meeting room. The meeting would of course not have been successful without the wide range of participants, so I also want to thank all the people who woke up on Sunday morning to attend the meeting :-) (The CC list is pretty long, please let me know - by private e-mail in order not to spam the list - if you would like not to receive future CDF-related e- mails directly) 0. Abbreviations ---------------- DBI - Display Bus Interface, a parallel video control and data bus that transmits data using parallel data, read/write, chip select and address signals, similarly to 8051-style microcontroller parallel busses. This is a mixed video control and data bus. DPI - Display Pixel Interface, a parallel video data bus that transmits data using parallel data, h/v sync and clock signals. This is a video data bus only. DSI - Display Serial Interface, a serial video control and data bus that transmits data using one or more differential serial lines. This is a mixed video control and data bus. DT - Device Tree, a representation of a hardware system as a tree of physical devices with associated properties. SFI - Simple Firmware Interface, a lightweight method for firmware to export static tables to the operating system. Those tables can contain display device topology information. VBT - Video BIOS Table, a block of data residing in the video BIOS that can contain display device topology information. 1. Goals -------- The meeting started with a brief discussion about the CDF goals. Tomi Valkeinin and Tomasz Figa have sent RFC patches to show their views of what CDF could/should be. Many others have provided very valuable feedback. Given the early development stage propositions were sometimes contradictory, and focused on different areas of interest. We have thus started the meeting with a discussion about what CDF should try to achieve, and what it shouldn't. CDF has two main purposes. The original goal was to support display panels in a platform- and subsystem-independent way. While mostly useful for embedded systems, the emergence of platforms such as Intel Medfield and ARM-based PCs that blends the embedded and PC worlds makes panel support useful for the PC world as well. The second purpose is to provide a cross-subsystem interface to support video encoders. The idea originally came from a generalisation of the original RFC that supported panels only. While encoder support is considered as lower priority than display panel support by developers focussed on display controller driver (Intel, Renesas, ST Ericsson, TI), companies that produce video encoders (Analog Devices, and likely others) don't share that point of view and would like to provide a single encoder driver that can be used in both KMS and V4L2 drivers. Both display panels and encoders are thus the target of a lot of attention, depending on the audience. As long as none of them is forgotten in CDF, the overall agreement was that focussing on panels first is acceptable. Care shall be taken in that case to avoid any architecture that would make encoders support difficult or impossible. 2. Subsystems ------------- Display panels are used in conjunction with FBDEV and KMS drivers. There was to the audience knowledge no V4L2 driver that needs to explicitly handle display panels. Even though at least one V4L2 output drivers (omap_vout) can output video to a display panel, it does so in conjunction with the KMS and/or FBDEV APIs that handle panel configuration. Panels are thus not exposed to V4L2 drivers. Encoders, on the other hand, are widely used in the V4L2 subsystem. Many V4L2 devices output video in either analog (Composite, S-Video, VGA) or digital (DVI, HDMI) way. Display panel drivers don't need to be shared with the V4L2 subsystem. Furthermore, as the general opinion during the meeting was that the FBDEV subsystem should be considered as legacy and deprecate in the future, restricting panel support to KMS hasn't been considered by anyone as an issue. KMS will thus be the main target of display panel support in CDF, and FBDEV will be supported if that doesn't bring any drawback from an architecture point of view. Encoder drivers need to be shared with the V4L2 subsystem. Similarly to panel drivers, excluding FBDEV support from CDF isn't considered as an issue. 3. KMS Extensions ----------------- The usefulness of V4L2 for output devices was questioned, and the possibility of using KMS for complex video devices usually associated with V4L2 was raised. The TI DaVinci 8xxx family is an example of chips that could benefit from KMS support. The KMS API is lacking support for deep-pipelining ("framebuffers" that are sourced from a data stream instead of a memory buffer) today. Extending the KMS API with deep-pipelining support was considered as a sensible goal that would mostly require the creation of a new KMS source object. Exposing the topology of the whole device would then be handled by the Media Controller API. Given that no evidence of this KMS extension being ready in a reasonable time frame exists, sharing encoder drivers with the V4L2 subsystem hasn't been seriously questioned. 4. Discovery and Initialization ------------------------------- As CDF will split support for complete display devices across different drivers, the question of physical devices discovery and initialization caused concern among the audience. Topology and connectivity information can come from a wide variety of sources. Embedded platforms typically provide that information in platform data supplied by board code or through the device tree. PC platforms usually store the information in the firmware exposed through ACPI, SFI, VBT or other interfaces. Pluggable devices (PCI being the most common case) can also store the information on an on-board non-volatile memory or hardcode it in drivers. When using the device tree display entity information are bundled with the display entity device DT node. The associated driver shall thus extract itself information from the DT node. In all other cases the display entity driver shall not parse data from the information source directly, but shall instead received a platform data structure filled with data parsed by the display controller driver. In the most complex case a machine driver, similar to ASoC machine drivers, might be needed, in which case platform data could be provided by that machine driver. Display entity drivers are encouraged to internally fill a platform data structure from their DT node to reuse the same code path for both platform data- and DT-based initialization. 5. Bus Model ------------ Display panels are connected to a video bus that transmits video data and optionally to a control bus. Those two busses can be separate physical interfaces or combined into a single physical interface. The Linux device model represents the system as a tree of devices (not to be confused by the device tree, abreviated as DT). The tree is organized around control busses, with every device being a child of its control bus master. For instance an I2C device will be a child of its I2C controller device, which can itself be a child of its parent PCI device. Display panels will be represented as Linux devices. They will have a single parent from the Linux device model point of view, but will be potentially connected to multiple physical busses. CDF thus needs to define what bus to select as the Linux parent bus. In theory any physical bus that the device is attached to can be selected as the parent bus. However, selecting a video data bus would depart from the traditional Linux device model that uses control busses only. This caused concern among several people who argued that not presenting the device to the kernel as attached to its control bus would bring issues in embedded system. Unlike on PC systems where the control bus master is usually the same physical device as the data bus master, embedded systems are made of a potentially complex assembly of completely unrelated devices. Not representing an I2C- controlled panel as a child of its I2C master in DT was thus frown upon, even though no clear agreement was reached on the subject. Panels can be divided in three categories based on their bus model. - No control bus Many panels don't offer any control interface. They are usually referred to as 'dumb panels' as they directly display the data received on their video bus without any configurable option. Panels in this category often use DPI is their video bus, but other options such as DSI (using the DSI video mode only) are possible. Panels with no control bus can be represented in the device model as platform devices, or as being attached to their video bus. In the later case we would need Linux busses for pure video data interfaces such as DPI or VGA. Nobody was particularly enthousiastic about this idea. Dumb panels will thus likely be represented as platform devices. - Separate video and control busses The typical case is a panel connected to an I2C or SPI bus that receives data through a DPI video interface or DSI video mode interface. Using a mixed control and video bus (such as DSI and DBI) for control only with a different bus for video data is possible in theory but very unlikely in practice (although the creativity of hardware developers should never be underestimated). Display panels that use a control bus supported by the Linux kernel should likely be represented as children of their control bus master. Other options are possible as mentioned above but were received without enthousiasm by most embedded kernel developers. When the control bus isn't supported by the kernel, a new bus type can be developed, or the panel can be represented as a platform device. The right option will likely very depending on the control bus. - Combined video and control busses When the two busses are combined in a single physical bus the panel device will obviously be represented as a child of that single physical bus. In such cases the control bus could expose video bus control methods. This would remove the need for a video source as proposed by Tomi Valkeinen in his CDF model. However, if the bus can be used for video data transfer in combination with a different control bus, a video source corresponding to the data bus will be needed. No decision has been taken on whether to use a video source in addition to the control bus in the combined busses case. Experimentation will be needed, and the right solution might depend on the bus type. - Multiple control busses One panel was mentioned as being connected to a DSI bus and an I2C bus. The DSI bus is used for both control and video, and the I2C bus for control only. configuring the panel requires sending commands through both DSI and I2C. The opinion on such panels was a large *sigh* followed by a "this should be handled by the device core, let's ask Greg KH". 6. Miscellaneous ---------------- - If the OMAP3 DSS driver is used as a model for the DSI support implementation, Daniel Vetter requested the DSI bus lock semaphore to be killed as it prevents lockdep from working correctly (reference needed ;-)). - Do we need to support chaining several encoders ? We can come up with several theoretical use cases, some of them probably exist in real hardware, but the details are still a bit fuzzy. 7. Actions ---------- I will post a third CDF RFC that will target DPI panels only, with support for a concept similar to the video source as proposed by Tomi Valkeinen. Marcus Lorentzon will then try to implement support for DSI panel using a single bus without a video source. Rob Clark will test DPI support with the OMAP DSS driver on a OMAP3 platform. -- Regards, Laurent Pinchart

7 9

[pull] fb helper cleanups
by Daniel Vetter 14 Feb '13

14 Feb '13

Hi Dave, [Andrew: Pull contains the patch "drm/fb-helper: don't sleep for screen unblank when an oopps is in progress" which is also in your tree, hence the cc.] I've figured a pull request is easier to handle ;-) This is the drm fb helper cleanup, mostly motivated by strange things I've seen in my locking rework and the i915 modeset revamp. Compared to the original submission I've reinstated the setup flexibility you'd like to retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark reviewed the code changes. Quick overview of the changes: - Cleaned-up library interface for drivers using the fb helper, also simplified the fb allocation callback since no driver supported reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers to the old mapping around anyway, so reallocating backing storage will be much more work. - No longer call the crtc helper "disable everything" function at init time, but allow drivers to do so. Motivated by i915's fastboot effort and allows us to drop a bunch of noop dummy functions just to avoid calling NULL function pointers from i915.ko. - Properly clear old state when doing modeset calls, the fb helper left some old modes in there and unconditionally set an fb (even when disabling a crtc). The crtc helpers didn't care, but i915 modeset code can now drop a few special cases. - Full kerneldoc for the fb helper. Yay! - My version of the "don't sleep in panic ->unblank calls". The patch is already in -mm, I guess Andrew can drop it as soon as this pull lands in drm-next. Imo the fb helper looks now rather nice, and there's only a few pieces left to fix up further: - Removing the duplicated gamma handling. - Reviewing the locking in the panic/sysrq/kgdb handlers some more. - Maybe move some function pointers only used by the fb helper from the crtc helper structs to the fb helper structs. Currently those vtable misplacements are the last thing tying fb/crtc helpers together. - Locking around init/teardown still looks a bit fishy. But that ties into the console_lock madness, so I'm not volunteering ;-) Cheers, Daniel The following changes since commit b9e5071386007729110e86fd2c55c687085624e3: Merge branch 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux into drm-next (2013-02-08 14:02:32 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm drm-fb-helper for you to fetch changes up to a065b46a01b25d7d364e01e75f7ec2bd9ed5d9cb: drm/fb-helper: remove unused members of struct drm_fb_helper (2013-02-14 00:08:41 +0100) ---------------------------------------------------------------- Daniel Vetter (14): drm: review locking for drm_fb_helper_restore_fbdev_mode drm/fb-helper: kill drm_fb_helper_restore drm/fb-helper: unexport drm_fb_helper_panic drm/fb-helper: unexport drm_fb_helper_single_fb_probe drm/tegra: don't set up initial fbcon config twice drm/fb-helper: don't disable everything in initial_config drm/i915: rip out helper->disable noop functions drm/fb-helper: fixup set_config semantics drm/fb-helper: directly call set_par from the hotplug handler drm/fb-helper: streamline drm_fb_helper_single_fb_probe drm/<drivers>: simplify ->fb_probe callback drm/fb-helper: improve kerneldoc drm/fb-helper: don't sleep for screen unblank when an oopps is in progress drm/fb-helper: remove unused members of struct drm_fb_helper Documentation/DocBook/drm.tmpl | 1 + drivers/gpu/drm/ast/ast_fb.c | 26 +-- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 26 +-- drivers/gpu/drm/drm_crtc.c | 16 +- drivers/gpu/drm/drm_fb_cma_helper.c | 22 +-- drivers/gpu/drm/drm_fb_helper.c | 251 +++++++++++++++++++++++------ drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 35 +--- drivers/gpu/drm/gma500/framebuffer.c | 14 +- drivers/gpu/drm/i915/intel_crt.c | 1 - drivers/gpu/drm/i915/intel_ddi.c | 1 - drivers/gpu/drm/i915/intel_display.c | 20 +-- drivers/gpu/drm/i915/intel_dp.c | 1 - drivers/gpu/drm/i915/intel_drv.h | 1 - drivers/gpu/drm/i915/intel_dvo.c | 1 - drivers/gpu/drm/i915/intel_fb.c | 21 +-- drivers/gpu/drm/i915/intel_hdmi.c | 1 - drivers/gpu/drm/i915/intel_lvds.c | 1 - drivers/gpu/drm/i915/intel_sdvo.c | 1 - drivers/gpu/drm/i915/intel_tv.c | 1 - drivers/gpu/drm/mgag200/mgag200_fb.c | 27 +--- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 25 +-- drivers/gpu/drm/radeon/radeon_fb.c | 25 +-- drivers/gpu/drm/tegra/fb.c | 4 - drivers/gpu/drm/udl/udl_fb.c | 26 +-- drivers/staging/omapdrm/omap_fbdev.c | 21 +-- include/drm/drm_crtc.h | 1 + include/drm/drm_fb_helper.h | 18 ++- 27 files changed, 298 insertions(+), 290 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

1 0

[PATCH 0/3] R-Car Display Unit DRM driver
by Laurent Pinchart 14 Feb '13

14 Feb '13

Hello, Here's a new DRM driver for the Renesas R-Car Display Unit (DU). The DU features two superposition processors (modeled as CRTCs) and eight planes that can be shared between the superposition processors. The driver supports the superposition processors (currently in pure overlay mode without alpha blending), all eight planes and all hardware supported formats except 8-bit indexed color more and 32-bit RGB666 mode (that would be [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian, not supported by DRM at the moment). On the output side only sync master non-interlaced modes are currently supported. Only the VGA output has been tested, as I lack an LVDS panel for the development board. The second CRTC hasn't been tested for the same reason. Platform data are subject to change with the common display framework. This is why I haven't implemented DT bindings yet. Laurent Pinchart (2): drm: Renesas R-Car Display Unit DRM driver ARM: shmobile: marzen: Add Display Unit support Phil Edworthy (1): r8a7779: Add Display Unit clock support arch/arm/mach-shmobile/board-marzen.c | 65 +++++ arch/arm/mach-shmobile/clock-r8a7779.c | 4 +- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/rcar-du/Kconfig | 11 + drivers/gpu/drm/rcar-du/Makefile | 8 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 471 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 47 ++++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 265 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_drv.h | 56 ++++ drivers/gpu/drm/rcar-du/rcar_du_kms.c | 163 +++++++++++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 34 +++ drivers/gpu/drm/rcar-du/rcar_du_lvds.c | 247 +++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_lvds.h | 25 ++ drivers/gpu/drm/rcar-du/rcar_du_plane.c | 299 ++++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_plane.h | 58 ++++ drivers/gpu/drm/rcar-du/rcar_du_regs.h | 439 +++++++++++++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_vga.c | 193 +++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_vga.h | 24 ++ include/linux/platform_data/rcar-du.h | 51 ++++ 20 files changed, 2462 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/rcar-du/Kconfig create mode 100644 drivers/gpu/drm/rcar-du/Makefile create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_regs.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.h create mode 100644 include/linux/platform_data/rcar-du.h -- Regards, Laurent Pinchart

4 21

[PATCH 0/2] drm: Fix 8bpp fbcon on i915
by ville.syrjala＠linux.intel.com 13 Feb '13

13 Feb '13

Looks like I accidentally broke 8bpp support in i915. This series fixes the regression, as verified in the bug report: https://bugs.freedesktop.org/show_bug.cgi?id=59572#c18 There should be no negative effect on other drivers since they either don't support 8bpp, or they don't bother with checking the pixel format.

3 6

← Newer
1
...
55
56
57
58
59
60
61
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2013