Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On 12:50-20130416, Arnd Bergmann wrote: On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote: diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 8d1e2bb..73a99e4 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -36,7 +36,7 @@ #ifndef

Re: [PATCH 2/3] drm/exynos: Rework fimc clocks handling

Hi Sylwester, On 16 April 2013 23:01, Sylwester Nawrocki s.nawro...@samsung.com wrote: @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev) ret = exynos_drm_ippdrv_register(ippdrv); if (ret 0) { dev_err(dev, failed to register drm fimc

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object i915 has an imported object reference in its file priv, that isn't cleaned up properly until fd close.

[GIT PULL] exynos-drm-next

Hi Dave, This is initial pull request for Exynos. It includes a big change that it makes drm_display_mode for timings parameters to be used for exynos4 and exynos5 commonly and cleans up unnecessary codes. And also it adds device tree support for fimd to get timing values and

Re: [PATCH 4/6] char: use vma_pages() to replace (vm_end - vm_start) PAGE_SHIFT

On Mon, 15 Apr 2013, Libin wrote: diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c index e1f60f9..ed0703f 100644 --- a/drivers/char/mspec.c +++ b/drivers/char/mspec.c @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma) if (!atomic_dec_and_test(vdata-refcnt))

Re: [PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote: Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object i915 has an imported object

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #10 from Erik Faye-Lund kusmab...@gmail.com --- Another data-point: My AMD driver also does not support line continuation characters by default, although they do *after* a #version 420 line. So in conclusion, I think blindly

Re: [PATCH 2/3] drm/exynos: Rework fimc clocks handling

On 04/17/2013 06:02 AM, Sachin Kamat wrote: Hi Sylwester, On 16 April 2013 23:01, Sylwester Nawrocki s.nawro...@samsung.com wrote: @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev) ret = exynos_drm_ippdrv_register(ippdrv); if (ret 0) {

Re: [Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

We have a similar problem: A HD6570(TURKS) card with RS780E chipset. When booting, DVI output is good, but VGA output is black screen; after X started, DVI is still good and VGA blinks forever. We have tried 3.4~3.9-rc7 kernel, all kernels after the commit drm/radeon: properly handle

[PATCH v2 0/3] drm/exynos: Add device tree support for IPP driver

Hi Inki, This small patch series adds device tree support for the DRM FIMC driver. The binding documentation can be found in -next at Documentation/devicetree/ bindings/media/samsung-fimc.txt. It will make the driver dependent on OF. This patch series is needed in 3.10 to ensure simultaneous

[PATCH v2 1/3] drm/exynos: Remove redundant devm_kfree()

There is no need for explicit calls of devm_kfree(), as the allocated memory will be freed during driver's detach. Remove the redundant devm_kfree() calls from probe() and remove() callbacks. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park

[PATCH v2 2/3] drm/exynos: Rework fimc clocks handling

The clocks handling is refactored and a mux clock handling is added to account for changes in the clocks driver. After switching to the common clock framework the sclk_fimc clock is now split into two clocks: a gate and a mux clock. In order to retain the exisiting functionality two additional

[PATCH v2 3/3] drm/exynos: Add device tree support for fimc ipp driver

This patch adds OF initialization support for the FIMC driver. The binding documentation can be found at Documentation/devicetree/ bindings/media/samsung-fimc.txt. The syscon regmap interface is used to serialize access to the shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM FIMC

[Bug 63632] New: RS880 + mesa/llvm heads - segfault

https://bugs.freedesktop.org/show_bug.cgi?id=63632 Priority: medium Bug ID: 63632 Assignee: dri-devel@lists.freedesktop.org Summary: RS880 + mesa/llvm heads - segfault Severity: normal Classification: Unclassified OS: Linux

Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On Tuesday 16 April 2013, Nishanth Menon wrote: On 12:50-20130416, Arnd Bergmann wrote: On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote: diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 8d1e2bb..73a99e4 100644 --- a/include/uapi/drm/drm.h +++

Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On Wed, Apr 17, 2013 at 6:43 AM, Arnd Bergmann a...@arndb.de wrote: drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__ drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__ drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__)) drivers/staging/ced1401/machine.h:#if

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares luca...@linux.vnet.ibm.com wrote: radeon currently uses a drm function to get the speed capabilities for the bus. However, this is a non-standard method of performing this detection and this

Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection

On 04/15/2013 02:00 AM, Michael Ellerman wrote: On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote: On pseries machines the detection for max_bus_speed should be done through an OpenFirmware property. This patch adds a function to perform this detection and a hook to

Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection

On 04/15/2013 08:42 AM, Michael Ellerman wrote: On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote: On pseries machines the detection for max_bus_speed should be done through an OpenFirmware property. This patch adds a function to perform this detection and a hook to

Re: [RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On Tue, 2013-04-16 at 12:50 +0200, Arnd Bergmann wrote: On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote: diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h index 8d1e2bb..73a99e4 100644 --- a/include/uapi/drm/drm.h +++ b/include/uapi/drm/drm.h @@ -36,7 +36,7 @@

Re: [PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

On Wed, 2013-04-17 at 10:21 +0200, Daniel Vetter wrote: On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote: Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #11 from Ian Romanick i...@freedesktop.org --- (In reply to comment #9) I don't know where you have the retroactive-story from, but the specification does not mention it being retroactive, and even goes as far as to say: I have

[RFC][PATCH] drm: Insane but more fine grained locking for planes

From: Ville Syrjälä ville.syrj...@linux.intel.com Instead of locking all modeset locks during plane updates, use just a single CRTC mutex. To make that work, track the CRTC that owns the plane currently. During enable/update that means the new CRTC, and during disable it means the old CRTC.

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #12 from Erik Faye-Lund kusmab...@gmail.com --- Well, Khronos meetings don't define the spec, the specification does. And the specification is pretty clear here. -- You are receiving this mail because: You are the assignee for the

[PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes

This series attempts to make our CEA mode matching recognize both the 60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97, 30/29.97, etc.). The benefits should include: - Send the correct VIC in the AVI infoframe - Pick the correct RGB quantization range in automatic mode

[PATCH 1/4] drm: Remove explicit vrefresh initialization from DRM_MODE()

From: Ville Syrjälä ville.syrj...@linux.intel.com No need to zero initialize .vrefresh in DRM_MODE() since it's using desgignated initializers. This will also avoid some duplicate initialization warnings later. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com ---

[PATCH 2/4] drm: Add drm_mode_equal_no_clocks()

From: Ville Syrjälä ville.syrj...@linux.intel.com drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't compare the clock or vrefresh values. drm_mode_equal() is now implemented by first doing the clock checks, and then calling drm_mode_equal_no_clocks(). Signed-off-by: Ville

[PATCH 3/4] drm/edid: Populate vrefresh for CEA modes

From: Ville Syrjälä ville.syrj...@linux.intel.com Well have use for the vrefresh information of CEA modes later. Just populate the information into the table to avoid having to calculate it. I'm too lazy to check if someone relies on newly allocated CEA modes having 0 vrefresh, so just clear

[PATCH 4/4] drm/edid: Check both 60Hz and 59.94Hz when looking for a CEA mode

From: Ville Syrjälä ville.syrj...@linux.intel.com drm_match_cea_mode() should be able to match both the 60Hz version, and the 59.94Hz version of modes. We only store one pixel clock value per mode in edid_cea_modes, so the other value must be calculated. Depending on the mode, edid_cea_modes

Re: [RFC][PATCH] drm: Insane but more fine grained locking for planes

On Wed, Apr 17, 2013 at 08:04:52PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Instead of locking all modeset locks during plane updates, use just a single CRTC mutex. To make that work, track the CRTC that owns the plane currently. During

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #13 from Ian Romanick i...@freedesktop.org --- Comment on attachment 78052 -- https://bugs.freedesktop.org/attachment.cgi?id=78052 [PATCH] gallium: handle drirc disable_glsl_line_continuations option You'll probably want review

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #14 from Ian Romanick i...@freedesktop.org --- (In reply to comment #12) Well, Khronos meetings don't define the spec, the specification does. And the specification is pretty clear here. The discussion was at the time of the vote,

Re: [PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt rost...@goodmis.org wrote: On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: The thing is now that you're not expected to hold these locks for a long time - if you need to

[PATCH libdrm 2/5] modetest: Fix pitches, somewhat

From: Ville Syrjälä ville.syrj...@linux.intel.com libkms only has the xrgb format, so we're overallocating the bo by quite a lot in some cases. But we still need to get the pitch from the libkms since it's the driver that decides how to align it. Signed-off-by: Ville Syrjälä

[PATCH libdrm 4/5] modetest: Print possible_crtcs for planes

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- tests/modetest/modetest.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index c91bb9d..27cd2ce 100644

[PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- tests/modetest/buffers.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c index 5086381..6b117b4 100644

[PATCH libdrm 3/5] modetest: Add support for all 16/32 bpp RGB formats

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- tests/modetest/buffers.c | 120 +-- 1 file changed, 115 insertions(+), 5 deletions(-) diff --git a/tests/modetest/buffers.c

[PATCH libdrm 5/5] modetest: Reduce the length of the connector type string

From: Ville Syrjälä ville.syrj...@linux.intel.com Spelling out eDP or DP make for a ridicilously long string which plays havoc with formatting. Just say eDP or DP. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- tests/modetest/modetest.c | 4 ++-- 1 file changed, 2 insertions(+),

Re: [PATCH 2/4] drm: Add drm_mode_equal_no_clocks()

Hi 2013/4/17 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't compare the clock or vrefresh values. drm_mode_equal() is now implemented by first doing the clock checks, and then calling

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #15 from Erik Faye-Lund kusmab...@gmail.com --- Thanks for the clarification, but I'm still not entirely convinced. I agree that this per-spec for OpenGL ES 3.0 (although I'm a bit disappointed that the ES3-group missed that we in

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares luca...@linux.vnet.ibm.com wrote: On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares luca...@linux.vnet.ibm.com wrote: radeon currently uses a drm function to get the speed

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares luca...@linux.vnet.ibm.com wrote: On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas bhelg...@google.com wrote: On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares luca...@linux.vnet.ibm.com wrote: On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: On Thu,

Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On Wed, Apr 17, 2013 at 2:17 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas bhelg...@google.com wrote: On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares

Re: [PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes

2013/4/17 ville.syrj...@linux.intel.com: This series attempts to make our CEA mode matching recognize both the 60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97, 30/29.97, etc.). The benefits should include: - Send the correct VIC in the AVI infoframe - Pick the correct

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #16 from Ian Romanick i...@freedesktop.org --- (In reply to comment #15) Thanks for the clarification, but I'm still not entirely convinced. I agree that this per-spec for OpenGL ES 3.0 (although I'm a bit disappointed that the

[Bug 63532] Heroes of Newerth Water renders Black instead of transparent with reflections on Ultra [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63532 --- Comment #14 from Ian Romanick i...@freedesktop.org --- (In reply to comment #13) I managed to start the game and it seems there are different problems with water rendering, and I don't see framebuffer-related errors in the game. Possibly I

abuse of dumb ioctls in exynos

It appears exynos is passing the generic flags from the dumb ioctls straight into the the GEM creation code. The dumb flags are NOT driver specific, and are NOT to be used in this fashion. Please remove this use of the flags from your driver. I was going to add one new flag to the interface for

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #17 from Erik Faye-Lund kusmab...@gmail.com --- (In reply to comment #16) (In reply to comment #15) Thanks for the clarification, but I'm still not entirely convinced. I've just tested the latter. So apparently, Mesa is the

[Bug 63579] Savage 2 Edges render white [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63579 --- Comment #18 from Ian Romanick i...@freedesktop.org --- (In reply to comment #17) (In reply to comment #16) Making the support general (instead of just for preprocessor directives) simplified the code greatly. Since I'm responsible for

Re: gma500: Other things that I could work on

On Wed, Apr 17, 2013 at 7:57 PM, Kero k...@chello.nl wrote: 4) when using modules, initialization from hibernation is not good enough: my screen stays black; without using modules, the kernel boots normally, and everything is fine. 5) initialization from suspend is not good enough: my

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #33 from Benjamin Lee b...@b1c1l1.com --- Sorry, my previous patch was bogus -- TURKS mobility actually needs POWER_STATE_TYPE_PERFORMANCE. radeon_pm_get_type_index() currently fails to find the requested state

[Bug 63532] Heroes of Newerth Water renders Black instead of transparent with reflections on Ultra [r600g]

https://bugs.freedesktop.org/show_bug.cgi?id=63532 --- Comment #15 from Vadim Girlin pt...@yandex.ru --- (In reply to comment #14) #2 0x7f4485b7a63e in glBindTexture (target=0, texture=2079) That's definitely no good. 0 isn't a valid target, and 2079 (0x081F) isn't either. Weird. I

Re: mmotm 2013-04-17-16-02 uploaded (gpu/drm/qxl)

On Wed, Apr 17, 2013 at 6:44 PM, Randy Dunlap rdun...@infradead.org wrote: On 04/17/13 16:03, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ I saw this in linux-next a few days ago and forgot to

[RESEND PATCH 3/3] drm: Destroy property blobs at mode config cleanup time

Hi Daniel, On Tuesday 16 April 2013 21:06:43 Daniel Vetter wrote: > On Tue, Apr 16, 2013 at 01:12:21PM +1000, Dave Airlie wrote: > > On Mon, Apr 15, 2013 at 11:37 PM, Laurent Pinchart wrote: > > > Property blob objects need to be destroyed when cleaning up to avoid > > > memory leaks. Go through

[Bug 57567] 3.7 radeonfb broken on efivga screens

-devel/attachments/20130417/b2104e25/attachment.html>

[Bug 43751] [TTM] Out of kernel memory

https://bugzilla.kernel.org/show_bug.cgi?id=43751 John Paul Funk changed: What|Removed |Added CC||funk at funktronix.com --- Comment

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v3)

Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object i915 has an imported object reference in its file priv, that isn't cleaned up properly until fd close.

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object i915 has an imported object reference in its file priv, that isn't cleaned up properly until fd close.

[PATCH 2/3] drm/exynos: Rework fimc clocks handling

Hi Sylwester, On 16 April 2013 23:01, Sylwester Nawrocki wrote: > @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev) > ret = exynos_drm_ippdrv_register(ippdrv); > if (ret < 0) { > dev_err(dev, "failed to register drm fimc device.\n"); > -

[GIT PULL] exynos-drm-next

Hi Dave, This is initial pull request for Exynos. It includes a big change that it makes drm_display_mode for timings parameters to be used for exynos4 and exynos5 commonly and cleans up unnecessary codes. And also it adds device tree support for fimd to get timing values and

[PATCH 4/6] char: use vma_pages() to replace (vm_end - vm_start) >> PAGE_SHIFT

On Mon, 15 Apr 2013, Libin wrote: > diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c > index e1f60f9..ed0703f 100644 > --- a/drivers/char/mspec.c > +++ b/drivers/char/mspec.c > @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma) > if (!atomic_dec_and_test(>refcnt)) >

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote: > Currently we have a problem with this: > 1. i915: create gem object > 2. i915: export gem object to prime > 3. radeon: import gem object > 4. close prime fd > 5. radeon: unref object > 6. i915: unref object > > i915 has an imported

[Bug 63579] Savage 2 Edges render white [r600g]

- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/2804cbac/attachment.html>

[PATCH 2/3] drm/exynos: Rework fimc clocks handling

On 04/17/2013 06:02 AM, Sachin Kamat wrote: > Hi Sylwester, > > On 16 April 2013 23:01, Sylwester Nawrocki wrote: >> @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev) >> ret = exynos_drm_ippdrv_register(ippdrv); >> if (ret < 0) { >>

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

> dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/a75d4971/attachment.html>

[PATCH v2 0/3] drm/exynos: Add device tree support for IPP driver

Hi Inki, This small patch series adds device tree support for the DRM FIMC driver. The binding documentation can be found in -next at Documentation/devicetree/ bindings/media/samsung-fimc.txt. It will make the driver dependent on OF. This patch series is needed in 3.10 to ensure simultaneous

[PATCH v2 1/3] drm/exynos: Remove redundant devm_kfree()

There is no need for explicit calls of devm_kfree(), as the allocated memory will be freed during driver's detach. Remove the redundant devm_kfree() calls from probe() and remove() callbacks. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park ---

[PATCH v2 2/3] drm/exynos: Rework fimc clocks handling

The clocks handling is refactored and a "mux" clock handling is added to account for changes in the clocks driver. After switching to the common clock framework the sclk_fimc clock is now split into two clocks: a gate and a mux clock. In order to retain the exisiting functionality two additional

[PATCH v2 3/3] drm/exynos: Add device tree support for fimc ipp driver

This patch adds OF initialization support for the FIMC driver. The binding documentation can be found at Documentation/devicetree/ bindings/media/samsung-fimc.txt. The syscon regmap interface is used to serialize access to the shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM FIMC

[Bug 63632] New: RS880 + mesa/llvm heads - segfault

--- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/068de0ad/attachment-0001.html>

[PATCH v2] drm/nouveau: always select ACPI_VIDEO if ACPI is enabled.

On Wed, Feb 20, 2013 at 07:56:33PM +0100, Borislav Petkov wrote: > On Tue, Feb 05, 2013 at 05:22:06PM +0100, Borislav Petkov wrote: > > On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote: > > > Argh, next attempt, based on i915's Kconfig. > > > > > > It seems that not only I have

[RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On Tuesday 16 April 2013, Nishanth Menon wrote: > On 12:50-20130416, Arnd Bergmann wrote: > > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote: > > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > > > > index 8d1e2bb..73a99e4 100644 > > > > --- a/include/uapi/drm/drm.h > >

[RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On Wed, Apr 17, 2013 at 6:43 AM, Arnd Bergmann wrote: >> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__ >> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__ >> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__)) >> drivers/staging/ced1401/machine.h:#if

[PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: > On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares > wrote: >> radeon currently uses a drm function to get the speed capabilities for >> the bus. However, this is a non-standard method of performing this >> detection and this patch changes it

[PATCHv3 1/2] ppc64: perform proper max_bus_speed detection

On 04/15/2013 02:00 AM, Michael Ellerman wrote: > On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote: >> On pseries machines the detection for max_bus_speed should be done >> through an OpenFirmware property. This patch adds a function to perform this >> detection and a hook

[PATCHv3 1/2] ppc64: perform proper max_bus_speed detection

On 04/15/2013 08:42 AM, Michael Ellerman wrote: > On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote: >> On pseries machines the detection for max_bus_speed should be done >> through an OpenFirmware property. This patch adds a function to perform this >> detection and a hook

[RFC PATCH] drm.h: Fix DRM compilation with bare-metal toolchain.

On Tue, 2013-04-16 at 12:50 +0200, Arnd Bergmann wrote: > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote: > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > > > index 8d1e2bb..73a99e4 100644 > > > --- a/include/uapi/drm/drm.h > > > +++ b/include/uapi/drm/drm.h > > > @@

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v4)

On Wed, 2013-04-17 at 10:21 +0200, Daniel Vetter wrote: > On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote: > > Currently we have a problem with this: > > 1. i915: create gem object > > 2. i915: export gem object to prime > > 3. radeon: import gem object > > 4. close prime fd > > 5.

[Bug 63579] Savage 2 Edges render white [r600g]

tory from being in the Khronos meetings. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/3e318931/attachment.html>

[RFC][PATCH] drm: Insane but more fine grained locking for planes

From: Ville Syrj?l? Instead of locking all modeset locks during plane updates, use just a single CRTC mutex. To make that work, track the CRTC that "owns" the plane currently. During enable/update that means the new CRTC, and during disable it means the old CRTC.

[Bug 63579] Savage 2 Edges render white [r600g]

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/9f8cac0d/attachment.html>

[PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes

This series attempts to make our CEA mode matching recognize both the 60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97, 30/29.97, etc.). The benefits should include: - Send the correct VIC in the AVI infoframe - Pick the correct RGB quantization range in automatic mode

[PATCH 1/4] drm: Remove explicit vrefresh initialization from DRM_MODE()

From: Ville Syrj?l? No need to zero initialize .vrefresh in DRM_MODE() since it's using desgignated initializers. This will also avoid some duplicate initialization warnings later. Signed-off-by: Ville Syrj?l? --- include/drm/drm_crtc.h | 2 +- 1 file changed,

[PATCH 2/4] drm: Add drm_mode_equal_no_clocks()

From: Ville Syrj?l? drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't compare the clock or vrefresh values. drm_mode_equal() is now implemented by first doing the clock checks, and then calling drm_mode_equal_no_clocks(). Signed-off-by: Ville

[PATCH 3/4] drm/edid: Populate vrefresh for CEA modes

From: Ville Syrj?l? Well have use for the vrefresh information of CEA modes later. Just populate the information into the table to avoid having to calculate it. I'm too lazy to check if someone relies on newly allocated CEA modes having 0 vrefresh, so just clear

[PATCH 4/4] drm/edid: Check both 60Hz and 59.94Hz when looking for a CEA mode

From: Ville Syrj?l? drm_match_cea_mode() should be able to match both the 60Hz version, and the 59.94Hz version of modes. We only store one pixel clock value per mode in edid_cea_modes, so the other value must be calculated. Depending on the mode, edid_cea_modes

[RFC][PATCH] drm: Insane but more fine grained locking for planes

On Wed, Apr 17, 2013 at 08:04:52PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Instead of locking all modeset locks during plane updates, use just > a single CRTC mutex. To make that work, track the CRTC that "owns" > the plane currently. During enable/update that

[Bug 63579] Savage 2 Edges render white [r600g]

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/d26336f4/attachment.html>

[Bug 63579] Savage 2 Edges render white [r600g]

ou are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/6fee35f4/attachment.html>

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt wrote: > On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote: >> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote: >> > The thing is now that you're not expected to hold these locks for a >> > long >> > time - if you need to

[PATCH libdrm 2/5] modetest: Fix pitches, somewhat

From: Ville Syrj?l? libkms only has the xrgb format, so we're overallocating the bo by quite a lot in some cases. But we still need to get the pitch from the libkms since it's the driver that decides how to align it. Signed-off-by: Ville Syrj?l? ---

[PATCH libdrm 4/5] modetest: Print possible_crtcs for planes

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- tests/modetest/modetest.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index c91bb9d..27cd2ce 100644 ---

[PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- tests/modetest/buffers.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c index 5086381..6b117b4 100644 ---

[PATCH libdrm 3/5] modetest: Add support for all 16/32 bpp RGB formats

From: Ville Syrj?l? Signed-off-by: Ville Syrj?l? --- tests/modetest/buffers.c | 120 +-- 1 file changed, 115 insertions(+), 5 deletions(-) diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c index

[PATCH libdrm 5/5] modetest: Reduce the length of the connector type string

From: Ville Syrj?l? Spelling out eDP or DP make for a ridicilously long string which plays havoc with formatting. Just say eDP or DP. Signed-off-by: Ville Syrj?l? --- tests/modetest/modetest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 2/4] drm: Add drm_mode_equal_no_clocks()

Hi 2013/4/17 : > From: Ville Syrj?l? > > drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't > compare the clock or vrefresh values. drm_mode_equal() is now > implemented by first doing the clock checks, and then calling > drm_mode_equal_no_clocks(). > > Signed-off-by: Ville

[Bug 63579] Savage 2 Edges render white [r600g]

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/bef34017/attachment.html>

[PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares wrote: > On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: >> >> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares >> wrote: >>> >>> radeon currently uses a drm function to get the speed capabilities for >>> the bus. However, this is a

[PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds

On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher wrote: > On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares > wrote: >> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote: >>> >>> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares >>> wrote: radeon currently uses a drm function to

  1   2   >