[PATCH 0/5] drm/exynos: rework layer blending setup

Gentle reminder that I still haven't heard anything about the series by the Samsung guys ;) With best wishes, Tobias Tobias Jakobi wrote: > Hello, > > this is a rework of the layer blending setup in the Exynos DRM mixer. The > current setup is static and spread out through the mixer code.

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

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. Suggested-by:

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

On 21/05/2015 11:47, Ben Skeggs wrote: > 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

[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 --- Comment #3 from Mikkel Oscar Lyderik --- Created attachment 177571 --> https://bugzilla.kernel.org/attachment.cgi?id=177571=edit xorg log -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 --- Comment #2 from Mikkel Oscar Lyderik --- Created attachment 177561 --> https://bugzilla.kernel.org/attachment.cgi?id=177561=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

[Bug 98751] radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 Mikkel Oscar Lyderik changed: What|Removed |Added CC||mikkeloscar at gmail.com

[Bug 98751] New: radeon: multihead "no signal" on one of the monitors - regression

https://bugzilla.kernel.org/show_bug.cgi?id=98751 Bug ID: 98751 Summary: radeon: multihead "no signal" on one of the monitors - regression Product: Drivers Version: 2.5 Kernel Version: 4.0.3+ Hardware: All

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

Gustavo Padovan wrote: > 2015-05-21 Tobias Jakobi : > >> Gustavo Padovan wrote: >>> 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'

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

-- 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/8901620c/attachment-0001.html>

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

Hey Emil, Emil Velikov wrote: > 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,

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

Gustavo Padovan wrote: > 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

[PATCH] drm/nouveau: add nv_error_ratelimited()

When things go badly, the log is flooded with SCHED_ERROR messages, which is less than useful. Instead lets ratelimit these so we can still find the traces leading up to the problems. Signed-off-by: Rob Clark --- drivers/gpu/drm/nouveau/include/nvkm/core/printk.h | 9 +

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

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

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

for your nice work! pstglia -- 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/a5bf016a/attachment.html>

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

On 05/21/2015 06:07 PM, 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, etc. See thread: >> >>

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

[RFC PATCH] perf: enable fsync to flush buffered samples

Instead of having a PERF_EVENT_IOC_FLUSH ioctl this instead allows userspace to use fsync for flushing pmu samples, as suggested by Ingo Molnar - thanks. For reference I've also pushed a patch to my Mesa branch to test this: https://github.com/rib/mesa wip/rib/oa-hsw-4.0.0 - Robert --- >8 ---

[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

[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

[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

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

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 (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 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 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] 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: > > >

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

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

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

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

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

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

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

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

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

2015-05-21 Tobias Jakobi : > Gustavo Padovan wrote: > > 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'

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

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

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

[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

[pull] radeon drm-fixes-4.1

Hi Dave, Just two small DP fixes for 4.1 The following changes since commit 755c814a7d826257d5488cfaa801ec19377c472a: drm/msm/mdp5: fix incorrect parameter for msm_framebuffer_iova() (2015-05-21 14:31:45 +1000) are available in the git repository 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

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

[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

[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

[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 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] drm/vgem: drop DRIVER_PRIME (v2)

On Thu, May 21, 2015 at 12:10 PM, Chris Wilson wrote: > 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

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

[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

[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

[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

[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

[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

  1   2   >