[PATCH] drm/nouveau/platform: fix compilation if !CONFIG_IOMMU

On Wed, May 20, 2015 at 9:01 PM, Arnd Bergmann wrote: > On Wednesday 20 May 2015 13:32:33 Thierry Reding wrote: >> >> Since these are all static functions, perhaps an "if (IS_ENABLED(...))" >> would work here? That way you'd get compile coverage of the code in all >> cases. > > I had the same

[PATCH v3] drm/exynos: calculate vrefresh instead of use a fixed value

Gustavo Padovan wrote: > From: Gustavo Padovan > > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh > for us so we can get the correct value instead of relying on fixed value > defined in a macro. But if vrefresh is still zero we should fail the > update. > >

[PATCH 00/11] Add H/W Debugger module support to amdkfd

This patch-set adds the H/W debugger module support to amdkfd. The H/W debugger module support enables a userspace debugger, e.g gdb, to debug GPU kernels running in HSA mode. The available operations in this patch-set are setting watchpoints in the GPU kernel and controlling wave-fronts. It

[PATCH 01/11] drm/radeon: Add H/W debugger kfd->kgd functions

From: Yair Shachar This patch adds new interface functions to the kfd2kgd interface file. The new functions allow to perform H/W debugger operations by writing to GPU registers. Signed-off-by: Yair Shachar Signed-off-by: Oded Gabbay ---

[PATCH 02/11] drm/amdkfd: add H/W debugger IOCTL set definitions

From: Yair Shachar This patch adds four new IOCTLs to amdkfd. These IOCTLs expose a H/W debugger functionality to the userspace. The IOCTLs are: - AMDKFD_IOC_DBG_REGISTER: The purpose of this IOCTL is to notify amdkfd that a process wants to use GPU debugging facilities

[PATCH 03/11] drm/amdkfd: Add static user-mode queues support

From: Yair Shachar This patch adds support for static user-mode queues in QCM. Queues which are designated as static can NOT be preempted by the CP microcode when it is executing its scheduling algorithm. This is needed for supporting the debugger feature, because we can't

[PATCH 04/11] drm/amdkfd: Add skeleton H/W debugger module support

From: Yair Shachar This patch adds the skeleton H/W debugger module support. This code enables registration and unregistration of a single HSA process at a time. The module saves the process's pasid and use it to verify that only the registered process is allowed to

[PATCH 05/11] drm/amdkfd: Add wave control operation to debugger

From: Yair Shachar The wave control operation supports several command types executed upon existing wave fronts that belong to the currently debugged process. The available commands are: HALT - Freeze wave front(s) execution RESUME - Resume freezed wave front(s)

[PATCH 06/11] drm/amdkfd: Add address watch operation to debugger

From: Yair Shachar The address watch operation gives the ability to specify watch points which will generate a shader breakpoint, based on a specified single address or range of addresses. There is support for read/write/any access modes. Signed-off-by: Yair Shachar

[PATCH 07/11] drm/amdkfd: Implement (un)register debugger IOCTLs

From: Yair Shachar Signed-off-by: Yair Shachar Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 72 +++- 1 file changed, 70 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

[PATCH 09/11] drm/amdkfd: Implement address watch debugger IOCTL

From: Yair Shachar Signed-off-by: Yair Shachar Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 104 ++- 1 file changed, 103 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

[PATCH 10/11] drm/radeon: Add ATC VMID<-->PASID functions to kfd->kgd

From: Alexey Skidanov This patch adds three new interfaces to kfd2kgd interface file of radeon. The interfaces are: - Check if a specific VMID has a valid PASID mapping - Retrieve the PASID which is mapped to a specific VMID - Issue a VMID invalidation request to the

[PATCH 08/11] drm/amdkfd: Implement wave control debugger IOCTL

From: Yair Shachar Signed-off-by: Yair Shachar Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 88 +++- 1 file changed, 87 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

[PATCH 11/11] drm/amdkfd: Enforce kill all waves on process termination

From: Ben Goz This commit makes sure that on process termination, after we're destroying all the active queues, we're killing all the existing wave front of the current process. By doing this we're making sure that if any of the CUs were blocked by infinite loop we're enforcing

[PATCH v3] drm/exynos: calculate vrefresh instead of use a fixed value

Gustavo Padovan wrote: > From: Gustavo Padovan > > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh > for us so we can get the correct value instead of relying on fixed value > defined in a macro. But if vrefresh is still zero we should fail the > update. This works

[Nouveau] [PATCH] ram/gf100-: error out if a ridiculous amount of vram is detected

Any idea on how to solve the problem. other than just reporting it? But for now this adds a helpful error message... you may add my R-b. On 20.05.2015 22:01, Ilia Mirkin wrote: > Some newer chips have trouble coming up, and we get bad MMIO reads from > them, like 0xbadf100. This ends up

[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

On Tue, May 19, 2015 at 3:53 PM, Peter Zijlstra wrote: > On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote: >> On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra >> wrote: >> > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote: >> > >> >> I've changed the uapi for configuring

[PATCH] dma-buf: Minor coding style fixes

- WARNING: Missing a blank line after declarations - WARNING: line over 80 characters - WARNING: please, no space before tabs Signed-off-by: Jagan Teki Cc: Sumit Semwal --- drivers/dma-buf/dma-buf.c | 9 +++-- drivers/dma-buf/reservation.c | 9 ++--- drivers/dma-buf/seqno-fence.c |

[Bug 90534] integrated LVDS displays stays dark (firmware-linux-nonfree-0.43)

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150521/97495a39/attachment.html>

[Bug 90537] radeonsi bo/va conflict on RADEON_GEM_VA (rscreen->ws->buffer_from_handle returns NULL)

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

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

TML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150521/ace3a7b5/attachment.html>

[Nouveau] [PATCH] ram/gf100-: error out if a ridiculous amount of vram is detected

On 21 May 2015 at 06:01, Ilia Mirkin wrote: > Some newer chips have trouble coming up, and we get bad MMIO reads from > them, like 0xbadf100. This ends up translating into crazy amounts of > VRAM, which destroys all sorts of other logic down the line. Instead, > fail device init. Hrm, I'm not

[PATCH 1/2] drm/nouveau: add staging module option

On 20 May 2015 at 15:56, Alexandre Courbot wrote: > Add a module option allowing to enable staging/unstable APIs. This will > allow us to experiment freely with experimental APIs for a while before > setting them in stone. > > Signed-off-by: Alexandre Courbot > --- > drm/nouveau/nouveau_drm.c

[PATCH v4 1/2] drm: bridge: Allow daisy chaining of bridges

Allow drm_bridge objects to link to each other in order to form an encoder chain. The requirement for creating a chain of bridges comes because the MSM drm driver uses up its encoder and bridge objects for blocks within the SoC itself. There isn't anything left to use if the SoC display output is

[PATCH v4 2/2] drm/DocBook: Add more drm_bridge documentation

Add DOC sections giving an overview of drm_bridge and how to fill up the drm_bridge_funcs ops. Add these to drm.tpml in DocBook. Add headerdocs for funcs in drm_bridge.c that don't have them yet. Signed-off-by: Archit Taneja --- Documentation/DocBook/drm.tmpl | 12 ++

[PATCH 1/2] drm/nouveau: add staging module option

On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote: > On 20 May 2015 at 15:56, Alexandre Courbot wrote: >> Add a module option allowing to enable staging/unstable APIs. This will >> allow us to experiment freely with experimental APIs for a while before >> setting them in stone. >> >>

[PATCH 1/2] drm/nouveau: add staging module option

On 21 May 2015 at 15:49, Alexandre Courbot wrote: > On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote: >> On 20 May 2015 at 15:56, Alexandre Courbot wrote: >>> Add a module option allowing to enable staging/unstable APIs. This will >>> allow us to experiment freely with experimental APIs for a

[PATCH 1/2] drm/nouveau: add staging module option

On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote: > On 21 May 2015 at 15:49, Alexandre Courbot wrote: >> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote: >>> On 20 May 2015 at 15:56, Alexandre Courbot wrote: Add a module option allowing to enable staging/unstable APIs. This will

[PATCH] dma-buf: Minor coding style fixes

Hi Jagan, On 21 May 2015 at 01:09, Jagan Teki wrote: > - WARNING: Missing a blank line after declarations > - WARNING: line over 80 characters > - WARNING: please, no space before tabs > > Signed-off-by: Jagan Teki > Cc: Sumit Semwal Thanks for the patch; I've queued it up in for-next. Best

[PATCH v2] nouveau: add coherent BO attribute

Add a flag allowing Nouveau to specify that an object should be coherent at allocation time. This is required for some class of objects like fences which are randomly-accessed by both the CPU and GPU. This flag instructs the kernel driver to make sure the object remains coherent even on

[PATCH] nouveau: add coherent BO attribute

On Wed, May 20, 2015 at 3:53 PM, Martin Peres wrote: > On 20/05/15 08:11, Alexandre Courbot wrote: >> >> On Fri, May 15, 2015 at 8:39 PM, Maarten Lankhorst >> wrote: >>> >>> Op 15-05-15 om 09:11 schreef Alexandre Courbot: Re-pinging Marteen on an email address that still exists :P

[Bug 87856] Driver load fails with no error on ppc64 host

stof -- 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/20150521/2e373de2/attachment-0001.html>

[PATCH v4 2/2] drm/DocBook: Add more drm_bridge documentation

On Thu, May 21, 2015 at 11:03:17AM +0530, Archit Taneja wrote: > Add DOC sections giving an overview of drm_bridge and how to fill up the > drm_bridge_funcs ops. Add these to drm.tpml in DocBook. > > Add headerdocs for funcs in drm_bridge.c that don't have them yet. > > Signed-off-by: Archit

[Intel-gfx] [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

On Thu, May 21, 2015 at 12:17:48AM +0100, Robert Bragg wrote: > On Tue, May 19, 2015 at 3:53 PM, Peter Zijlstra > wrote: > > On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote: > >> On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra > >> wrote: > >> > On Thu, May 07, 2015 at 03:15:43PM

[Intel-gfx] [PATCH] drm/edid: Fix DDC probe for passive DP dongles

On Thu, 21 May 2015, Todd Previte wrote: > Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they > do not have a sink device in them to respond to any AUX traffic. When > probing these dongles over the DDC, sometimes they will NAK the first attempt > even though the

drm/atomic: add commit_planes_on_crtc helper

On Wed, May 20, 2015 at 10:43:55PM +0300, Dan Carpenter wrote: > Hello Maarten Lankhorst, > > This is a semi-automatic email about new static checker warnings. > > The patch 32975e952e85: "drm/atomic: add commit_planes_on_crtc > helper" from May 19, 2015, leads to the following Smatch

[PATCH 1/2] drm/nouveau: add staging module option

On 21 May 2015 at 16:04, Alexandre Courbot wrote: > On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote: >> On 21 May 2015 at 15:49, Alexandre Courbot wrote: >>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote: On 20 May 2015 at 15:56, Alexandre Courbot wrote: > Add a module option

[Nouveau] [PATCH v2] nouveau: add coherent BO attribute

On 21 May 2015 at 16:08, Alexandre Courbot wrote: > Add a flag allowing Nouveau to specify that an object should be coherent > at allocation time. This is required for some class of objects like > fences which are randomly-accessed by both the CPU and GPU. This flag > instructs the kernel driver

[PATCH] drm/vgem: implement virtual GEM

On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote: > On 11/25/2014 02:08 AM, Zachary Reizner wrote: > > After looking into removing platform_device, I found that using > > dma_buf_attach with a NULL device always returns an error, thereby > > preventing me from using VGEM for import

[Bug 90534] integrated LVDS displays stays dark (firmware-linux-nonfree-0.43)

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

[PATCH v4 2/2] drm/DocBook: Add more drm_bridge documentation

On Thu, May 21, 2015 at 10:03:38AM +0200, Daniel Vetter wrote: > On Thu, May 21, 2015 at 11:03:17AM +0530, Archit Taneja wrote: > > Add DOC sections giving an overview of drm_bridge and how to fill up the > > drm_bridge_funcs ops. Add these to drm.tpml in DocBook. > > > > Add headerdocs for funcs

[Intel-gfx] [PATCH] drm/edid: Fix DDC probe for passive DP dongles

On Thu, May 21, 2015 at 11:28:48AM +0300, Jani Nikula wrote: > On Thu, 21 May 2015, Todd Previte wrote: > > Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they > > do not have a sink device in them to respond to any AUX traffic. When > > probing these dongles over the DDC,

[PULL] drm-intel-fixes

Hi Dave, one fix for screen flickering. There's a stable backport from Ander [1] that combines this and a few other commits to fix the flickering on v4.0, reported in [2] among others. Having this upstream is obviously a requirement for stable. BR, Jani. [1]

[Bug 87856] Driver load fails with no error on ppc64 host

-- 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/20150521/38872d93/attachment.html>

[PATCH libdrm] tegra: Add VIC clear test

This patch adds a simple test for testing Video-Image-Compositor engine on Tegra124 SoC. The test case opens a channel and performs a surface clear. Signed-off-by: Arto Merilainen --- tests/tegra/Makefile.am | 3 +- tests/tegra/host1x.h | 52 ++ tests/tegra/submit_vic.c | 315

[PATCH 0/4] Add VIC support for Tegra124

This series adds Video-Image-Compositor (VIC) support for Tegra124. The unit replaced gr2d engine on T124 and it is effectively used for similar operations: making simple surface copy and fill operations. The series consists of four patches: The first patch fixes an issue in the host1x submit

[PATCH 1/4] host1x: Store device address to all bufs

Currently job pinning is optimized to handle only the first buffer using a certain host1x_bo object and all subsequent buffers using the same host1x_bo are considered done. In most cases this is correct, however, in case the same host1x_bo is used in multiple gathers inside the same job, we skip

[PATCH 2/4] host1x: Pass register value in firewall

In gr2d and gr3d units the register offset was sufficient for determining if the register in interest is used for storing a register value. However, in VIC this is not the case. The operations are passed through two registers, METHOD0 and METHOD1. Depending on content of METHOD0, METHOD1 can be

[PATCH 3/4] drm/tegra: Add VIC support

This patch adds support for Video Image Compositor engine which can be used for 2d operations. The engine has a microcontroller (Falcon) that acts as a frontend for the rest of the unit. In order to properly utilize the engine, the frontend must be booted before pushing any commands.

[PATCH 4/4] ARM: tegra: Add VIC for Tegra124

This patch adds VIC device tree node for Video Image Compositor. Signed-off-by: Arto Merilainen --- arch/arm/boot/dts/tegra124.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi index 13cc7ca5e031..626355693a41

[PATCH] drm/vgem: implement virtual GEM

On 05/21/2015 11:13 AM, Daniel Vetter wrote: > On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote: >> On 11/25/2014 02:08 AM, Zachary Reizner wrote: >>> After looking into removing platform_device, I found that using >>> dma_buf_attach with a NULL device always returns an error,

[PATCH v3] drm/exynos: calculate vrefresh instead of use a fixed value

Hi Tobias, 2015-05-21 Tobias Jakobi : > Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh > > for us so we can get the correct value instead of relying on fixed value > > defined in a macro. But if vrefresh is

[Intel-gfx] [PATCH] drm/plane-helper: Adapt cursor hack to transitional helpers

On 05/20/2015 10:36 AM, Daniel Vetter wrote: > In > > commit f02ad907cd9e7fe3a6405d2d005840912f1ed258 > Author: Daniel Vetter > Date: Thu Jan 22 16:36:23 2015 +0100 > > drm/atomic-helpers: Recover full cursor plane behaviour > > we've added a hack to atomic helpers to never to vblank waits

[PATCH] drm/vgem: implement virtual GEM

On Thu, May 21, 2015 at 9:49 AM, Thomas Hellstrom wrote: > On 05/21/2015 11:13 AM, Daniel Vetter wrote: >> On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote: >>> On 11/25/2014 02:08 AM, Zachary Reizner wrote: After looking into removing platform_device, I found that using

[PATCH] drm/vgem: implement virtual GEM

On 05/21/2015 04:19 PM, Rob Clark wrote: > On Thu, May 21, 2015 at 9:49 AM, Thomas Hellstrom > wrote: >> On 05/21/2015 11:13 AM, Daniel Vetter wrote: >>> On Thu, Apr 02, 2015 at 10:30:53AM +0200, Thomas Hellstrom wrote: On 11/25/2014 02:08 AM, Zachary Reizner wrote: > After looking into

[PATCH] Revert "drm/vgem: implement virtual GEM"

This reverts commit 502e95c6678505474f1056480310cd9382bacbac. Originally vgem was just to have a drm driver for software-only renders like llvmpipe so that they integrate more nicely with the existing compositor protocols like DRI2/3. Later on Ben extended it to serve as a dma-buf import/export

[PATCH] Revert "drm/vgem: implement virtual GEM"

Acked-by: Thomas Hellstrom On 05/21/2015 04:34 PM, Daniel Vetter wrote: > This reverts commit 502e95c6678505474f1056480310cd9382bacbac. > > Originally vgem was just to have a drm driver for software-only > renders like llvmpipe so that they integrate more nicely with the > existing compositor

[PATCH] drm/vgem: drop DRIVER_PRIME

For actual sharing of buffers with other drivers (ie. actual hardware) we'll need to pimp things out a bit better to deal w/ caching, multiple memory domains, etc. See thread: http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html But for the llvmpipe use-case this isn't a

[PATCH libdrm] tegra: Add VIC clear test

Hi Arto, On 21 May 2015 at 14:18, Arto Merilainen wrote: > This patch adds a simple test for testing Video-Image-Compositor > engine on Tegra124 SoC. The test case opens a channel and performs > a surface clear. > > Signed-off-by: Arto Merilainen > --- > tests/tegra/Makefile.am | 3 +- >

[PATCH v5 00/12] drm/exynos: atomic modesetting support

From: Gustavo Padovan Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. v2: fixes comments by Joonyoung - remove unused var in patch 09 - use ->disable instead of

[PATCH v5 01/12] drm/exynos: atomic phase 1: use drm_plane_helper_update()

From: Gustavo Padovan Rip out the check from exynos_update_plane() and create exynos_check_plane() for the check phase enabling use to use the atomic helpers to call our check and update phases when updating planes. Update all users of exynos_update_plane()

[PATCH] drm/exynos: use drm_atomic_state directly

From: Gustavo Padovan Instead of use duplicated information stored on struct exynos_drm_plane use the atomic state directly to have a more clear understanding and clean code. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 49

[PATCH v5 02/12] drm/exynos: atomic phase 1: use drm_plane_helper_disable()

From: Gustavo Padovan The atomic helper to disable planes also uses the optional .atomic_disable() helper. The unique operation it does is calling .win_disable() exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer. Signed-off-by: Gustavo

[PATCH v5 03/12] drm/exynos: atomic phase 1: add .mode_set_nofb() callback

From: Gustavo Padovan The new atomic infrastructure needs the .mode_set_nofb() callback to update CRTC timings before setting any plane. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +--- 1 file

[PATCH v5 04/12] drm/exynos: atomic phase 2: wire up state reset(), duplicate() and destroy()

From: Gustavo Padovan Set CRTC, planes and connectors to use the default implementations from the atomic helper library. The helpers will work to keep track of state for each DRM object. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/bridge/ps8622.c

[PATCH v5 05/12] drm/exynos: atomic phase 2: keep track of framebuffer pointer

From: Gustavo Padovan Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep track of the framebuffer pointer and reference. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH v5 06/12] drm/exynos: atomic phase 3: atomic updates of planes

From: Gustavo Padovan Now that phase 1 and 2 are complete we can switch the update/disable_plane callbacks to their atomic version. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++ drivers/gpu/drm/exynos/exynos_drm_plane.c

[PATCH v5 07/12] drm/exynos: atomic phase 3: use atomic .set_config helper

From: Gustavo Padovan Now that phase 1 and 2 are complete switch .set_config helper to use the atomic one. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v5 08/12] drm/exynos: atomic phase 3: convert page flips

From: Gustavo Padovan PageFlips now use the atomic helper to work through the atomic modesetting API. Async page flips are not supported yet. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +---

[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

From: Gustavo Padovan Now that no one is using the functions exported by exynos_drm_plane due to the atomic conversion we can make remove some of the them or make them static. v2: remove unused exynos_drm_crtc Signed-off-by: Gustavo Padovan ---

[PATCH v5 10/12] drm/exynos: don't disable unused functions at init

From: Gustavo Padovan Everything starts disabled so we don't really need to disable anything. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH v5 11/12] drm/exynos: atomic dpms support

From: Gustavo Padovan Run dpms operations through the atomic intefaces. This basically removes the .dpms() callback from econders and crtcs and use .disable() and .enable() to turn the crtc on and off. v2: Address comments by Joonyoung: - make hdmi code

[PATCH v5 12/12] drm/exynos: remove unnecessary calls to disable_plane()

From: Gustavo Padovan The planes are already disabled by the drm_atomic_helper_commit() code so we don't need to disable the in these two places. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 11 ---

[PATCH] drm/vgem: drop DRIVER_PRIME

Hi, Rob! On 05/21/2015 04:53 PM, Rob Clark wrote: > For actual sharing of buffers with other drivers (ie. actual hardware) > we'll need to pimp things out a bit better to deal w/ caching, multiple > memory domains, etc. See thread: > > >

[Bug 90378] GPU lockups in Left 4 Dead 2

ML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150521/55d34ebc/attachment.html>

[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

|2 |lockups in Left 4 Dead 2 -- 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/20150521/9c632

[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

Hi, like I said before, this clashes with my commit 'drm/exynos: plane: honor buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58), which is currently sitting in airlied's drm-fixes. With best wishes, Tobias On 2015-05-21 17:02, Gustavo Padovan wrote: > From: Gustavo

[PATCH v3] drm/exynos: calculate vrefresh instead of use a fixed value

Hey, On 2015-05-21 16:06, Gustavo Padovan wrote: > Hi Tobias, > > 2015-05-21 Tobias Jakobi : > >> Gustavo Padovan wrote: >> > From: Gustavo Padovan >> > >> > When mode's vrefresh is zero we should ask DRM core to calculate vrefresh >> > for us so we can get the correct value instead of relying

[PATCH 3/4] drm/tegra: Add VIC support

Thank you Mikko for your comments! Please see my answers inline. - Arto On 05/21/2015 05:40 PM, Mikko Perttunen wrote: > Hi, very good patch! > > Here are a few small comments. Aside those, you should also add a > section to > Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt in a

[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

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

[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

|| -- 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/20150521/864b9b7b/attachment.html>

[PATCH libdrm] tegra: Add VIC clear test

Thank you Emil for your feedback, On 05/21/2015 05:58 PM, Emil Velikov wrote: > Hi Arto, > > On 21 May 2015 at 14:18, Arto Merilainen wrote: >> This patch adds a simple test for testing Video-Image-Compositor >> engine on Tegra124 SoC. The test case opens a channel and performs >> a surface

[Bug 90378] [radeonsi][bisected] GPU lockups in Left 4 Dead 2

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150521/4fc73666/attachment.html>

[Bug 89228] Regression with left for dead 2

at least confirm if we are seeing the same issue. -- 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/20150521/8d23fd0f/attachment.html>

[PATCH] drm/vgem: drop DRIVER_PRIME

On Thu, May 21, 2015 at 05:03:58PM +0200, Thomas Hellstrom wrote: > Hi, Rob! > > On 05/21/2015 04:53 PM, Rob Clark wrote: > > For actual sharing of buffers with other drivers (ie. actual hardware) > > we'll need to pimp things out a bit better to deal w/ caching, multiple > > memory domains, etc.

[PATCH] drm/vgem: drop DRIVER_PRIME

On Thu, May 21, 2015 at 11:03 AM, Thomas Hellstrom wrote: > Hi, Rob! > > On 05/21/2015 04:53 PM, Rob Clark wrote: >> For actual sharing of buffers with other drivers (ie. actual hardware) >> we'll need to pimp things out a bit better to deal w/ caching, multiple >> memory domains, etc. See

[RESEND PATCH 2/2] modetest: only select plane with matching format

Hi Tobias On 12 May 2015 at 21:17, Tobias Jakobi wrote: > Don't assume that a plane supports any kind of pixelformat > but do a check first. > > v2: Simplify the format check. > Signed-off-by: Tobias Jakobi Nice catch ! I will push the tomorrow, unless we hear any objections against it. Patch

[PATCH v2] drm: Only create a cmdline mode if no probed modes match

On Mon, Apr 20, 2015 at 03:41:48PM +0200, Radek Dostál wrote: > On 04/20/2015 03:28 PM, Chris Wilson wrote: > > The intention of using video=: is primarily to select > > the user's preferred resolution at startup. Currently we always create a > > new mode irrespective of whether the monitor has a

[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

For actual sharing of buffers with other drivers (ie. actual hardware) we'll need to pimp things out a bit better to deal w/ caching, multiple memory domains, etc. See thread: http://lists.freedesktop.org/archives/dri-devel/2015-May/083160.html But for the llvmpipe use-case this isn't a

4.1-rc4 display-port on radeon not working

- MalteSch at gmx.de -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150521/6f5eb24f/attachment-0001.sig>

[PATCH] drm: atmel_hlcdc: Add support for get_timings

drm_panel supports querying timing ranges. If the supplied mode does not work with the hlcdc we query the panel and try to find a suitable mode. Signed-off-by: David Dueck --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 118 +++ 1 file changed, 98 insertions(+), 20

[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Tobias Jakobi : > Hi, > > like I said before, this clashes with my commit 'drm/exynos: plane: honor > buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58), > which is currently sitting in airlied's drm-fixes. Inki has to merge his -fixes tree into exynos-drm-next to

[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver

Hi Dave, Can you help me review this patch please? Thanks. Jianwei > -Original Message- > From: Wang Jianwei-B52261 > Sent: Thursday, May 07, 2015 2:29 PM > To: Wang Jianwei-B52261; airlied at linux.ie; daniel.vetter at intel.com; > stefan at agner.ch; Wood Scott-B07421; dri-devel at

[PATCH] ARM: dts: exynos4412-trats2: set display clock correctly

On 05/20/15 09:12, Krzysztof Kozlowski wrote: > 2015-02-07 19:49 GMT+09:00 Inki Dae : >> This patch sets display clock correctly. >> >> If Display clock isn't set correctly then you would find below messages >> and Display controller doesn't work correctly since a patch[1] >> >>exynos-drm: No

[PATCH 3/4] drm/tegra: Add VIC support

On 05/21/2015 06:10 PM, Arto Merilainen wrote: > ... >>> + >>> +vic->rst = devm_reset_control_get(dev, "vic03"); >> >> I might prefer just "vic" as the clock/reset name. The name is often >> used as a sort of "role" for the clock/reset for the device, not >> necessarily the raw name of the

[PATCH] drm/exynos: use drm_atomic_state directly

Just ignore this one. The patch file was by mistake in the same folder as the atomic ones. It is part of a patchset that will come out later. Gustavo 2015-05-21 Gustavo Padovan : > From: Gustavo Padovan > > Instead of use duplicated information stored on struct exynos_drm_plane > use the

[PATCH 3/4] drm/tegra: Add VIC support

Hi, very good patch! Here are a few small comments. Aside those, you should also add a section to Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt in a separate patch. Thanks, Mikko. On 05/21/2015 04:20 PM, Arto Merilainen wrote: > This patch adds support for Video Image

[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote: > For actual sharing of buffers with other drivers (ie. actual hardware) > we'll need to pimp things out a bit better to deal w/ caching, multiple > memory domains, etc. See thread: > >

[PATCH] drm/vgem: drop DRIVER_PRIME (v2)

On Thu, May 21, 2015 at 06:07:30PM +0200, Daniel Vetter wrote: > On Thu, May 21, 2015 at 11:58:30AM -0400, Rob Clark wrote: > > For actual sharing of buffers with other drivers (ie. actual hardware) > > we'll need to pimp things out a bit better to deal w/ caching, multiple > > memory domains,

[PATCH v5 09/12] drm/exynos: remove exported functions from exynos_drm_plane

2015-05-21 Gustavo Padovan : > 2015-05-21 Tobias Jakobi : > > > Hi, > > > > like I said before, this clashes with my commit 'drm/exynos: plane: honor > > buffer offset for dma_addr' (5d878bdb51bd7915ba3def8b531238c67624aa58), > > which is currently sitting in airlied's drm-fixes. > > Inki has

  1   2   >