[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 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 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 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 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 ---

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

orry that you don't think the maintainability of a multimillion line code base is an appealing argument. -- 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/

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

ests non-continuation behavior, we can add the browsers to > the workaround list. Fair enough. At least when considered in isolation. -- 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/cbc87b40/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

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

> > #3 0x7f4467bb1f85 in ?? () from /home/vg/HoN/vid_gl2-x86_64.so -- 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/78194a18/attachment.html>

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

for a > direction that just leads to even more fragmentation and pain. -- 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/eb3ee167/attachment.html>

[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

[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 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 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 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

[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]

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

gma500: Other things that I could work on

> > 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 Asus stays in > >some text mode (80x25?), but

[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

[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.

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

On Wed, Apr 17, 2013 at 6:44 PM, Randy Dunlap wrote: > On 04/17/13 16:03, akpm at 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 post it.

[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>

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

On 04/17/13 16:03, akpm at 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 post it. When CONFIG_DEBUG_FS is not enabled:

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

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

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

2013/4/17 : > 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

[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>

[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>

Standalone DRM application

David, I'm developing a small application that uses libdrm (DRM ioctls) to change the resolution of a single graphics display and show a framebuffer. I've run into two problems with this implementation that I'm hoping you can address. 1. Each application is its own process, which is designed to

[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>

[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

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

On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas wrote: > 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

[RFC 10/10] ARM: vexpress: Add CLCD Device Tree properties

Signed-off-by: Pawel Moll --- arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 17 + arch/arm/boot/dts/vexpress-v2m.dtsi | 17 + arch/arm/boot/dts/vexpress-v2p-ca9.dts |5 + 3 files changed, 31 insertions(+), 8 deletions(-) diff --git

[RFC 09/10] video: Versatile Express DVI mode driver

Versatile Express DVI output is driven by a Sii9022 chip. It can be controller to a limited extend by the Motherboard Config Controller, and that's what the driver is doing now. It is a temporary measure till there's a full I2C driver for the chip. Signed-off-by: Pawel Moll ---

[RFC 08/10] video: Versatile Express MUXFPGA driver

Versatile Express' DVI video output can be connected to one the three sources - motherboard's CLCD controller or a video signal generated by one of the daughterboards. This driver provides a Common Display Framework driver for the muxer FPGA, which acts as a switch selecting one of the video data

[RFC 07/10] mfd: vexpress: Allow external drivers to parse site ids

... by providing a function translating the MASTER value into the currently valid site number and a _LAST constant providing all possible site id values. Signed-off-by: Pawel Moll --- drivers/mfd/vexpress-sysreg.c |5 + include/linux/vexpress.h |2 ++ 2 files changed, 7

[RFC 06/10] video: ARM CLCD: Add DT & CDF support

This patch adds basic DT bindings for the PL11x CLCD cells and make their fbdev driver use them, together with the Common Display Framework. The DT provides information about the hardware configuration and limitations (eg. the largest supported resolution) but the video modes come exclusively

[RFC 05/10] fbmon: Add extra video helper

This function converts the fb_var_screeninfo to the videomode structure, to be used in fbdev drivers working with the Common Display Framework. Signed-off-by: Pawel Moll --- drivers/video/fbmon.c | 29 + include/linux/fb.h|3 +++ 2 files changed, 32

[RFC 04/10] video: display: Add generic TFT display type

TFT panels may be interfaced via a simple parallel interface carrying RGB data, pixel clock and synchronisation signals. >From the video generator point of view the width of the data channels (number of bits per R/G/B components) may be an important factor in setting up the display model. Above

[RFC 03/10] video: display: Add Device Tree bindings

Modelled after the common clock solution, the bindings are based on the idea of display entity "providers" and "consumers". Signed-off-by: Pawel Moll --- .../devicetree/bindings/video/display-bindings.txt | 75 + drivers/video/display/display-core.c | 84

[RFC 02/10] video: display: Update the display with the video mode data

The display entity (sink) may need to know about the mode being changed, eg. to update timings. Alternatively there could be a separate set_mode() operation... Signed-off-by: Pawel Moll --- drivers/video/display/display-core.c |5 +++-- include/video/display.h |6 -- 2

[RFC 01/10] video: Add generic display entity core

From: Laurent Pinchart Signed-off-by: Laurent Pinchart --- drivers/video/Kconfig|1 + drivers/video/Makefile |1 + drivers/video/display/Kconfig|4 + drivers/video/display/Makefile |1 +

[RFC 00/10] Versatile Express CLCD DVI output support

Hello All, This series implements support for the Versatile Express video output pipeline, which is not the simplest one available... It is meant as a RFC only and I'm hoping to attract all possible feedback (*including* naming ;-). The VE's "MultiMedia Bus" [1] comprises three video signal

[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

[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

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

On Wed, Apr 17, 2013 at 2:17 PM, Alex Deucher wrote: > On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas wrote: >> 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:

[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

[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.

[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 > >

[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 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 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

[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 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 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 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) { >>

[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 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>

[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

[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 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

[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"); > -

[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>

[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

[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 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

[Bug 57567] 3.7 radeonfb broken on efivga screens

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

[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)) >

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,

  1   2   >