[Patch] x86, ia64, efifb: Move boot_vga fixup from pci to vgaarb

With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret introduced a efifb vga_default_device() so that EFI systems that do not load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs attribute on the corresponding PCI device. Xorg is refusing to autodetect devices when

[PATCH 11/12] drm/i915: Accurately initialize fifo underrun state on gmch platforms

On Wed, 2014-05-14 at 20:51 +0200, Daniel Vetter wrote: > We don't have hardware based disable bits on gmch platforms, so need > to block spurious underrun reports in software. Which means that we > _must_ start out with fifo underrun reporting disabled everywhere. > > This is in big contrast to

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

Hi Rahul, Tomasz, On 14.05.2014 21:17, Rahul Sharma wrote: > From: Tomasz Stanislawski > > Add exynos-simple-phy driver to support a single register > PHY interfaces present on Exynos4 SoC. > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Rahul Sharma > > --- >

[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!

end and then resume once but after that the system does not suspend anymore. -- 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/20140514/79

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

vel/attachments/20140514/ccf1b98d/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/61d9b455/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

vel/attachments/20140514/f76e608b/attachment-0001.html>

[Bug 76231] New: radeon: DCE2 & DCE3 HDMI setup should be updated/improved (to match fglrx)

https://bugzilla.kernel.org/show_bug.cgi?id=76231 Bug ID: 76231 Summary: radeon: DCE2 & DCE3 HDMI setup should be updated/improved (to match fglrx) Product: Drivers Version: 2.5 Kernel Version: torvalds/linux.git

[PATCH 04/12] drm: Add drm_vblank_on()

On Wed, May 14, 2014 at 08:51:06PM +0200, Daniel Vetter wrote: > From: Ville Syrj?l? > > drm_vblank_off() will turn off vblank interrupts, but as long as the > refcount is elevated drm_vblank_get() will not re-enable them. This > is a problem is someone is holding a vblank reference while a

[PATCH 12/12] [RFC] drm/crtc-helper: Enforce sane vblank counter semantics

It literally took us years in i915 to track down all the vblank bogosity, which means that userspace has now code to deal with random crap like stuck vblank waits, needless counter wraps and other hilarity. To make sure that all drivers are at least somewhat sane enforce minimal standards in the

[PATCH 11/12] [RFC] drm/irq: More robustness in drm_vblank_on|off

If we want to use this functionality in generic helpers to make sure that all drivers have somewhat sane vblank handling across modesets/dpms, we need to make it work for all drivers. But some don't support interrupts and hence also not vblank waits. Just return early on such drivers. Note that

[PATCH 11/12] drm/i915: Accurately initialize fifo underrun state on gmch platforms

We don't have hardware based disable bits on gmch platforms, so need to block spurious underrun reports in software. Which means that we _must_ start out with fifo underrun reporting disabled everywhere. This is in big contrast to ilk/hsw/cpt where there's only _one_ disable bit for all platforms

[PATCH 10/12] drm/i915: rip our vblank reset hacks for runtime PM

Now that we unconditionally dtrt when disabling/enabling crtcs we don't need any hacks any longer to keep the vblank logic sane when all the registers go poof. So let's rip it all out. This essentially undoes commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6 Author: Paulo Zanoni Date: Tue Jul

[PATCH 10/12] drm/i915: Accurately initialize fifo underrun state on gmch platforms

We don't have hardware based disable bits on gmch platforms, so need to block spurious underrun reports in software. Which means that we _must_ start out with fifo underrun reporting disabled everywhere. This is in big contrast to ilk/hsw/cpt where there's only _one_ disable bit for all platforms

[PATCH 09/12] drm/irq: Lack of interrupt support in drm_vblank_on|off

If we want to use this functionality in generic helpers to make sure that all drivers have somewhat sane vblank handling across modesets/dpms, we need to make it work for all drivers. But some don't support interrupts and hence also not vblank waits. Just return early on such drivers. Note that

[PATCH 09/12] drm/i915: rip our vblank reset hacks for runtime PM

Now that we unconditionally dtrt when disabling/enabling crtcs we don't need any hacks any longer to keep the vblank logic sane when all the registers go poof. So let's rip it all out. This essentially undoes commit 9dbd8febb4dbc9199fcf340b882eb930e36b65b6 Author: Paulo Zanoni Date: Tue Jul

[PATCH 08/12] drm/irq: Add kms-native crtc interface functions

We need to start somewhere ... With this the only places left in i915 where we use pipe integers is in the interrupt handling code. And there it actually makes some amount of sense. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_irq.c| 81

[PATCH 07/12] drm/irq: kerneldoc polish

- Integrate into the drm DocBook - Disable kerneldoc for functions not exported to drivers. - Properly document the new drm_vblank_on|off and add cautious comments explaining when drm_vblank_pre|post_modesets shouldn't be used. - General polish and OCD. Signed-off-by: Daniel Vetter ---

[PATCH 06/12] drm/doc: Discourage usage of MODESET_CTL ioctl

Leftover from the old days of ums and should be used any longer. Since commit 29935554b384b1b3a7377d6f0b03b21d18a61683 Author: Laurent Pinchart Date: Wed May 30 00:58:09 2012 +0200 drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers it is a complete no-Op for kms drivers. Cc: Laurent

[PATCH 05/12] drm/i915: Remove drm_vblank_pre/post_modeset calls

Originally these functions have been for user modesetting drivers to ensure vblank processing doesn't fall over completely around modeset changes. This has been carried over ever since then. Now that Ville cleaned our vblank handling with an explicit drm_vblank_off/on braket when

[PATCH 04/12] drm: Add drm_vblank_on()

From: Ville Syrj?l? drm_vblank_off() will turn off vblank interrupts, but as long as the refcount is elevated drm_vblank_get() will not re-enable them. This is a problem is someone is holding a vblank reference while a modeset is happening, and the driver requires

[PATCH 03/12] drm: Make blocking vblank wait return when the vblank interrupts get disabled

From: Ville Syrj?l? If there's a blocking vblank wait in progress while the vblank interrupt gets disabled, the current code will just let the vblank wait time out. Instead make it return immediately when vblank interrupts get disabled. Signed-off-by: Ville

[PATCH 02/12] drm: Make the vblank disable timer per-crtc

From: Ville Syrj?l? Currently there's one per-device vblank disable timer, and it gets reset wheneven the vblank refcount for any crtc drops to zero. That means that one crtc could accidentally be keeping the vblank interrupts for other crtcs enabled even if there

[PATCH 01/12] drm: Use correct spinlock flavor in drm_vblank_get()

From: Peter Hurley The irq flags state is already established by the outer spin_lock_irqsave(); re-disabling irqs is redundant. Signed-off-by: Peter Hurley Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_irq.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH 00/12] irq vblank handling rework

Hi all, This is Ville's vblank rework series, slightly pimped. I've added kerneldoc, some polish and also some additional nasty igt testcases for these crtc on/off vs vblank issues. Seems all to hold together nicely. Now one thing I wanted to do is roll this out across all drm drivers, but that

[RFC PATCH 0/8] component helper improvements

t attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/2cd86462/attachment-0001.sig>

[PULL] topic/core-stuff

On Mon, May 5, 2014 at 11:19 AM, Daniel Vetter wrote: > Hi Dave, > > Update pull request with drm core patches. Mostly some polish for the > primary plane stuff and a pile of patches all over from Thierry. Has > survived a few days in drm-intel-nightly without causing ill. > > I've frobbed my

[RFC PATCH 0/2] drm: make drm_get_{connector, encoder}_name thread safe

On Wed, 14 May 2014, Chris Wilson wrote: > On Wed, May 14, 2014 at 04:58:18PM +0300, Jani Nikula wrote: >> Hi all - >> >> This series stores connector/encoder names in the relevant structs to >> make the name getters thread safe. >> >> What say you, is the wasted memory too high a price to pay

[PATCH] imx-drm: imx-hdmi: move memory and resource allocation into probe function

Philipp, On Wed, May 14, 2014 at 6:24 PM, Philipp Zabel wrote: > Move memory allocation and resource acquisition from the bind function into > the probe function. This calls the devres managed functions once instead of > possibly multiple times in the bind function and avoids leaking memory (as

[Intel-gfx] Design review request: DRM color manager

"atomic" color manager property since there will be a mechanism to atomically apply any number of properties. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/e728469c/attachment.sig>

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

> + /* did fence get signaled after we enabled the sw irq? */ > + if (atomic64_read(>rdev->fence_drv[fence->ring].last_seq) >= > fence->seq) { > + radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring); > + return false; > + } > + > + fence->fence_wake.flags =

[PATCH v2 4/7] drivers/base: Add interface framework

- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/2c2e9e59/attachment.sig>

[PATCH] drm/exynos: Make exynos_drm_init() call late during the bootup

exynos_drm_init() does probing of various drivers like dp_panel, hdmi, fimd, mixer, etc in an order and finally binds them together. Some of the drm devices (Eg: dp_panel) try to do regulator_get() and enable few supplies during their probe. Chances are that, these devices may get probed before

[PATCH 4/5] drm/radeon: rework page flip handling

On 05.05.2014 18:27, Michel D?nzer wrote: > On 02.05.2014 22:29, Christian K?nig wrote: >> Am 02.05.2014 09:25, schrieb Michel D?nzer: >>> >>> and asynchronous flips (not synchronized to vertical blank). >> Actually that's one of the things I've implement in 3.15 by using the >> pflip interrupt.

[RFC PATCH v1 16/16] drm/ttm: use rcu in core ttm

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/ttm/ttm_bo.c | 76 +++--- 1 file changed, 13 insertions(+), 63 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 31c4a6dd722d..6fe1f4bf37ed 100644 ---

[RFC PATCH v1 15/16] drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index 20a1a866ceeb..79e950df3018 100644 ---

[RFC PATCH v1 14/16] drm/radeon: use rcu waits in some ioctls

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/radeon/radeon_gem.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index d09650c1d720..7ba883843668 100644 ---

[RFC PATCH v1 13/16] drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep

With the conversion to the reservation api this should be safe. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_gem.c | 28 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c

[RFC PATCH v1 12/16] drm/ttm: flip the switch, and convert to dma_fence

--- drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +--- drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +--- drivers/gpu/drm/nouveau/nouveau_fence.h |2 drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++- drivers/gpu/drm/qxl/qxl_debugfs.c|6 +

[RFC PATCH v1 11/16] drm/vmwgfx: rework to new fence interface

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++ drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 - 4 files changed, 200

[RFC PATCH v1 10/16] drm/vmwgfx: get rid of different types of fence_flags entirely

Only one type was ever used. This is needed to simplify the fence support in the next commit. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 - drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 ++---

[RFC PATCH 2/2] drm: store encoder name in encoder struct

This makes drm_get_encoder_name() thread safe. Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3 at DC1-MBX-01\ .ptsecurity.ru Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_crtc.c | 31 +-- include/drm/drm_crtc.h | 2 ++ 2 files changed,

[RFC PATCH 1/2] drm: store connector name in connector struct

This makes drm_get_connector_name() thread safe. Reference: http://lkml.kernel.org/r/645ee6e22cad47d38a2b35c21c8d5fe3 at DC1-MBX-01.ptsecurity.ru Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_crtc.c | 36 include/drm/drm_crtc.h | 2 ++ 2 files

[RFC PATCH 0/2] drm: make drm_get_{connector, encoder}_name thread safe

Hi all - This series stores connector/encoder names in the relevant structs to make the name getters thread safe. What say you, is the wasted memory too high a price to pay for the thread safety and implementation simplicity of this approach? I think making drm_get_connector_name and

[RFC PATCH v1 09/16] drm/qxl: rework to new fence interface

Final driver! \o/ This is not a proper dma_fence because the hardware may never signal anything, so don't use dma-buf with qxl, ever. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/qxl/Makefile |2 drivers/gpu/drm/qxl/qxl_cmd.c |5 - drivers/gpu/drm/qxl/qxl_debugfs.c |

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/radeon/radeon.h| 15 +-- drivers/gpu/drm/radeon/radeon_device.c |1 drivers/gpu/drm/radeon/radeon_fence.c | 189 +--- 3 files changed, 153 insertions(+), 52 deletions(-) diff --git

[RFC PATCH v1 07/16] drm/nouveau: rework to new fence interface

From: Maarten Lankhorst Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/core/core/event.c |4 drivers/gpu/drm/nouveau/nouveau_bo.c |6 drivers/gpu/drm/nouveau/nouveau_display.c |4 drivers/gpu/drm/nouveau/nouveau_fence.c | 434

[RFC PATCH v1 06/16] drm/ttm: kill fence_lock

No users are left, kill it off! :D Conversion to the reservation api is next on the list, after that the functionality can be restored with rcu. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++--- drivers/gpu/drm/nouveau/nouveau_display.c |6 --

[RFC PATCH v1 05/16] drm/ttm: call ttm_bo_wait while inside a reservation

This is the last remaining function that doesn't use the reservation lock completely to fence off access to a buffer. --- drivers/gpu/drm/ttm/ttm_bo.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[RFC PATCH v1 04/16] drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence

This will ensure we always hold the required lock when calling those functions. --- drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++ drivers/gpu/drm/nouveau/nouveau_display.c | 17 + 2 files changed, 15 insertions(+), 4 deletions(-) diff --git

[RFC PATCH v1 03/16] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

Apart from some code inside ttm itself and nouveau_bo_vma_del, this is the only place where ttm_bo_wait is used without a reservation. Fix this so we can remove the fence_lock later on. After the switch to rcu the reservation lock will be removed again. Signed-off-by: Maarten Lankhorst ---

[RFC PATCH v1 02/16] drm/ttm: kill off some members to ttm_validate_buffer

This reorders the list to keep track of what buffers are reserved, so previous members are always unreserved. This gets rid of some bookkeeping that's no longer needed, while simplifying the code some. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/qxl/qxl_release.c |1

[RFC PATCH v1 01/16] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers

It seems some drivers really want this as a parameter, like vmwgfx. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/qxl/qxl_release.c|2 +- drivers/gpu/drm/radeon/radeon_object.c |2 +- drivers/gpu/drm/radeon/radeon_uvd.c |2 +- drivers/gpu/drm/radeon/radeon_vm.c

[RFC PATCH v1 00/16] Convert all ttm drivers to use the new reservation interface

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers

[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

s solution than by your prior proposal? I didn't say outright no to what you proposed earlier. What I said was that I didn't like it and that I thought we could come up with a better solution. Part of getting to a better solution is trying to understand the problems involved. You don't solve a problem by simply moving code into a different driver. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/6d0ed490/attachment.sig>

[PATCH v2 4/7] drivers/base: Add interface framework

On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote: > On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote: > > On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Some drivers, such as graphics drivers in the DRM

[PATCH v2 4/7] drivers/base: Add interface framework

On Tue, May 13, 2014 at 11:31:07PM +0200, Thierry Reding wrote: > A different solution, which seems to be fairly common for DRM drivers > for SoCs, is to instantiate a dummy device so that the DRM driver can > bind to it. This can happen in two forms: add the dummy device directly > in device tree

[PATCH] drm/panel: Add support for EDT ETM0700G0DH6 panel

The EDT ETM0700G0DH6 is a 7" 800x480 panel, which can be supported by the simple panel driver. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/panel/panel-simple.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c

[Bug 78669] [r600g with -O3] layered-rendering/clear-color-all-types 3d single_level fails

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/89ca5175/attachment.html>

[PATCH 18/18] ARM: dts: exynos5420: add dsi node

This patch adds common part of dsi node. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi

[PATCH 17/18] ARM: dts: exynos5420: add mipi-phy node

This patch adds mipi-phy node for MIPI-DSI device. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5420.dtsi |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi

[PATCH 16/18] ARM: dts: exynos5: add system register support

This patch adds sysreg device node, and sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5.dtsi |6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 15/18] ARM: dts: exynos4: add system register node

This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos4.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi

[PATCH 14/18] drm/panel: add S6E3FA0 driver

This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- drivers/gpu/drm/panel/Kconfig |7 + drivers/gpu/drm/panel/Makefile|1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 570

[PATCH 13/18] ARM: dts: s6e3fa0: add DT bindings

This patch adds DT bindings for s6e3fa0 panel. The bindings describes panel resources, display timings and cpu mode timings. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 45 1 file

[PATCH 12/18] drm/exynos: dsi: add driver data to support Exynos5420

The offset of register DSIM_PLLTMR_REG in Exynos5420 is different from the one in Exynos4 SoC. In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG, and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead. So this patch adds driver data to distinguish it.

[PATCH 11/18] ARM: dts: exynos_dsim: add exynos5420 compatible to DT bindings

This patch adds relevant to exynos5420 compatible for exynos5420 SoC support. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/exynos_dsim.txt |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH 10/18] drm/exynos: fimd: support I80 interface

To support MIPI DSI command mode interface, FIMD should do followings: - Sets LCD block configuration for I80 interface. - Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration. - Implements trigger feature which transfers image date if there is page flip request, and implements

[PATCH 09/18] drm/exynos: dsi: add TE handler to support command mode interface

To support command mode interface, the DSI host calls this handler to notify the panel tearing effect synchronization signal to the CRTC device manager to trigger to transfer video image. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park ---

[PATCH 08/18] drm/exynos: add TE handler to support MIPI DSI command mode interface

To support MIPI DSI command mode interface, the panel should generates Tearing Effect synchronization signal between MCU and FB to display video images. And the display controller should trigger to transfer video image at this signal. So the panel receives the TE IRQ, then calls this handler

[PATCH 07/18] ARM: dts: samsung-fimd: add I80 specific properties

In case of using MIPI command mode interface panel, the relevant registers should be set. So this patch adds relevant DT bindings. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt |2 ++ 1 file changed, 2

[PATCH 06/18] ARM: dts: sysreg: add exynos5 compatible to DT bindings

This patch adds relevant to exynos5 compatible for exynos5 SoCs. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/arm/samsung/sysreg.txt |1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 05/18] drm_modes: add command mode helpers

This patch adds helper functions to convert cmdmode to drm_display_mode Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- drivers/gpu/drm/drm_modes.c | 59 +++ include/drm/drm_modes.h | 12 + 2 files changed, 71

[PATCH 04/18] video: add command mode and command mode display timing

This patch is based on videomode and display_timing relevant codes. To support command mode panel, it does not need to guide its timing information to the display controller like video mode panel, but it requires signal timings to transfer video data. So this patch adds cmdmode struct,

[PATCH 03/18] ARM: dts: video: add command mode display timing DT bindings

This patch adds DT bindings for command mode display timing. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../bindings/video/cmdmode-display-timing.txt | 64 1 file changed, 64 insertions(+) create mode 100644

[PATCH 02/18] drm/exynos: use wait_event_timeout() for safety usage

There could be the case that the page flip operation isn't finished correctly with some abnormal condition such as panel reset. So this patch replaces wait_event() with wait_event_timeout() to avoid waiting for page flip completion infinitely. Signed-off-by: YoungJun Cho Acked-by: Inki Dae

[PATCH 01/18] drm/exynos: dsi: move the EoT packets configuration point

This configuration could be used in MIPI DSI command mode also. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH 00/18] drm/exynos: support MIPI DSI command mode display

Hi, This series is for the Exynos DRM driver to support MIPI DSI command mode display and based on exynos-drm-next branch. The previous patches, RFC: http://www.spinics.net/lists/dri-devel/msg58898.html Patches 1 and 2 fix trivial bugs. Patches 3 and 4 introduce command mode and command mode

[RFC PATCH 0/2] drm: make drm_get_{connector, encoder}_name thread safe

On Wed, May 14, 2014 at 04:58:18PM +0300, Jani Nikula wrote: > Hi all - > > This series stores connector/encoder names in the relevant structs to > make the name getters thread safe. > > What say you, is the wasted memory too high a price to pay for the > thread safety and implementation

[Bug 78537] no anisotropic filtering in a native Half-Life 2

filtering state setup -- 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/20140514/11dff6c2/attachment-0001.html>

CIK hangs with kernel 3.15, bisected

Crap, any chance you can narrow it down a bit more? I've just tried a piglit quick test on my Bonaire and it seems to work perfectly fine. What hw do you test on? Regards, Christian. Am 13.05.2014 23:21, schrieb Marek Ol??k: > Hi Christian, > > Even though some regressions are fixed by these

[Bug 78669] [r600g with -O3] layered-rendering/clear-color-all-types 3d single_level fails

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

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

lds/linux.git/commit/?id=277babc374f6ecab6af182554f5d9f35a7768755 -- 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/20140514/f6

[PATCH 2/2] drm/radeon: fix buffer placement under memory pressure v2

Am 13.05.2014 21:47, schrieb Marek Ol??k: > For the patch: > > Reviewed-by: Marek Ol??k > > It would be clearer if alt_domain was renamed to allowed_domains. Yeah, already had the same idea. Going to rename "domain" to "prefered_domains" and "alt_domain" to "allowed_domains" for 3.16. Thanks,

[Intel-gfx] [PATCH] drm,drm/i915: Export cmdline mode parsing

On Tue, 13 May 2014, Chris Wilson wrote: > i915.ko has a custom fbdev initialisation routine that aims to preserve > the current mode set by the BIOS, unless overruled by the user. The > user's wishes are determined by what, if any, mode is specified on the > command line (via the video=

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140514/31ca8d1c/attachment.html>

[Intel-gfx] [PATCH 09/10] i915: add DP 1.2 MST support (v0.3)

On Wed, May 14, 2014 at 08:05:11AM +0200, David Herrmann wrote: > Hi > > On Wed, May 14, 2014 at 2:03 AM, Dave Airlie wrote: > > Since any objects you get with find are only valid under mode_config.mutex, > > yes some drivers mess this up, but they should be fixed. > > Didn't know that we have

[PATCH v2 4/7] drivers/base: Add interface framework

On Wed, May 14, 2014 at 04:37:19PM +0200, Daniel Vetter wrote: > On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote: > > On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote: > > > On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote: > > > > From: Thierry Reding

[Bug 76131] Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 --- Comment #5 from Felix Homann --- OK, 3.14.x kernels will resume fine if I suspend before the screen freezes. -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 09/10] i915: add DP 1.2 MST support (v0.3)

> > So we leak all dynamically created objects? There's no > kfree(intel_connector) here and we cannot add it because > drm_mode_object_find() is not ref-counted. So we keep the connector in > the mode_group and wait until the final drm_mode_config_cleanup()? But > drm_connector_cleanup() already

[Bug 76131] Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 --- Comment #4 from Felix Homann --- I'll do (*). But bisecting will not be that easy as the R7 260x is mostly broken on 3.14.x anyway, see https://bugzilla.redhat.com/show_bug.cgi?id=1094153 and the corresponding report on freedesktop.org. The

[Intel-gfx] [PATCH] drm,drm/i915: Export cmdline mode parsing

On Wed, May 14, 2014 at 11:31:47AM +0300, Jani Nikula wrote: > On Tue, 13 May 2014, Chris Wilson wrote: > > i915.ko has a custom fbdev initialisation routine that aims to preserve > > the current mode set by the BIOS, unless overruled by the user. The > > user's wishes are determined by what, if

[Bug 76131] Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 --- Comment #3 from Christian K?nig --- Then please bisect what commit broke it for you. -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] drm: Missed clflushopt in drm_clflush_virt_range

With this commit: 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range If clflushopt is available on the system, we use it instead of clflush in drm_clflush_virt_range. There were two calls to clflush in this function, but only one was changed to clflushopt. This patch changes the other

[Bug 76131] Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 --- Comment #2 from Felix Homann --- The proposed patch https://bugzilla.kernel.org/attachment.cgi?id=135881 doesn't fix the issue on my machine. -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

Thank you for advice. I will send a fixed patch soon. > -Original Message- > From: Thierry Reding [mailto:thierry.reding at gmail.com] > Sent: Tuesday, May 13, 2014 5:45 PM > To: gioh.kim > Cc: Sumit Semwal; Randy Dunlap; linux-media at vger.kernel.org; dri-devel at >

[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions

Update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim --- Documentation/dma-buf-sharing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index

[Bug 76131] Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 Christian K?nig changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment

[Bug 76131] Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 Felix Homann changed: What|Removed |Added CC||linuxaudio at showlabor.de

[Bug 76131] New: Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi)

https://bugzilla.kernel.org/show_bug.cgi?id=76131 Bug ID: 76131 Summary: Regression: Wake up after suspend broken with Radeon R7 260x (BONAIRE, radeonsi) Product: Drivers Version: 2.5 Kernel Version: 3.15.0-rc5+ (commit

  1   2   >