[RFC/PATCH 5/5] drm/rcar-du: Restart the DU group when a plane source changes

Plane sources are configured by the VSPS bit in the PnDDCR4 register. Although the datasheet states that the bit is updated during vertical blanking, it seems that updates only occur when the DU group is held in reset through the DSYSR.DRES bit. Restart the group if the source changes. Signed-off-

[RFC/PATCH 4/5] drm/rcar-du: Add VSP1 live source support

Register live sources for VSPD0 and VSPD1 and configure the plane source at plane setup time to source frames from memory or from the VSP1. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 + drivers/gpu/drm/rcar-

[RFC/PATCH 3/5] drm/rcar-du: Add VSP1 support to the planes allocator

The R8A7790 DU can source frames directly from the VSP1 devices VSPD0 and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0 or DU0/1 plane 1. Allocate the correct fixed plane when sourcing frames from VSPD0 or VSPD1, and allocate planes in reverse index order otherwise to ensure

[RFC/PATCH 2/5] drm: Connect live source to plane

Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/armada/armada_overlay.c | 2 +- drivers/gpu/drm/drm_atomic.c| 7 ++ drivers/gpu/drm/drm_atomic_helper.c | 4 + drivers/gpu/drm/drm_crtc.c | 134 +++- drivers/gpu/drm/drm_

[RFC/PATCH 1/5] drm: Add live source object

Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/drm_crtc.c | 231 drivers/gpu/drm/drm_ioctl.c | 3 + include/drm/drm_crtc.h | 42 include/uapi/drm/drm.h | 4 + include/uapi/drm/drm_mode.h | 32 ++ 5 files changed, 312

[RFC/PATCH 0/5] Add live source objects to DRM

Hello, I have a feeling that RFC/PATCH will work better than just RFC, so here's a patch set that adds a new object named live source to DRM. The need comes from the Renesas R-Car SoCs in which a video processing engine (named VSP1) that operates from memory to memory has one output directly conn

[Bug 94171] ati multihead black on one output

https://bugzilla.kernel.org/show_bug.cgi?id=94171 --- Comment #3 from Alex Deucher --- The fix works. Tested by another user on this bug: https://bugs.freedesktop.org/show_bug.cgi?id=89505 Just waiting for feedback from Christian. -- You are receiving this mail because: You are watching the as

[Bug 84648] Lag/Pause When VRAM->GTT or GTT->VRAM transfer occur

.19/4.0? They were applied to 4.0 and they will also show up in the stable kernels. -- 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/att

[PATCH 2/2] drm_atomic_helper.c: connector => tmp_connector

I'm not sure whether this is right, as far as I can see, for the macro 'list_for_each_entry', if not use the tmp_connector, it does make sense. Hope I am right with that. --- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/dr

[PATCH 1/2] drm_atomic_helper.c: cosmetic: fix some typos and add some empty line

there are some duplication in the annotations add some empty line to make it easier to read --- drivers/gpu/drm/drm_atomic_helper.c | 48 + 1 file changed, 38 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm

[git pull] drm fixes - slightly urgent

Hi Linus, hope this can make -rc4, an oops snuck in in -rc3 patch, this fixes it. Dave. The following changes since commit 6981e2af36b0d96404b60df29e90068855a81225: Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2015-03-15 10:49:38 -0700) are ava

commit 440fd52 drm/mm: Support 4GiB and larger ranges oops on 32bit kernel

Problem solved and tested: [PATCH] drm/mm: Fix support 4 GiB and larger ranges bad argument if(tmp)... in check_free_hole fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305! Signed-off-by: Krzysztof Kolasa --- drivers/gpu/drm/drm_mm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) d

commit 440fd52 drm/mm: Support 4GiB and larger ranges oops on 32bit kernel

On Sun, Mar 15, 2015 at 08:22:36PM +0100, Krzysztof Kolasa wrote: > Problem solved and tested: > > [PATCH] drm/mm: Fix support 4 GiB and larger ranges > > bad argument if(tmp)... in check_free_hole > > fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305! > > Signed-off-by: Krzysztof Kolasa N

Connection to the remote recipient's server was denied for unknown reason

nce &Technology Peking University Beijing, 100871, PRC -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150315/ba00e8dc/attachment.html>

[PATCH] nouveau: add coherent BO attribute

On 03/14/2015 04:33 AM, Maarten Lankhorst wrote: > Hey, > > Op 13-03-15 om 07:27 schreef Alexandre Courbot: >> 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 bot

[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

On 03/12/2015 11:36 AM, Christian König wrote: > On 12.03.2015 10:30, Oded Gabbay wrote: >> >> On 03/12/2015 11:23 AM, Christian König wrote: >>> On 12.03.2015 10:02, Michel Dänzer wrote: On 12.03.2015 06:14, Alex Deucher wrote: > On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher >

[PATCH 3/3] drm: rcar-du: Enable the atomic updates API

Set the DRIVER_ATOMIC flag to enable usage of the atomic updates API with the driver. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/r

[PATCH 2/3] drm: rcar-du: Don't initialize event->pipe field

The field is set by drm_send_vblank_event(), there's no need to preinitialize it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index

[PATCH 1/3] drm: rcar-du: Fix framebuffer reference leak through plane state

Plane state duplication takes a reference to the framebuffer stored in the state, but state destroy doesn't release it. This causes a reference leak. Fix it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers

[PATCH 0/3] R-Car DU fixes

Hello, Here are three patches that fix issues with the R-Car DU driver implementation of the atomic updates API. There's not much else to be said, please see individual patches for details. Laurent Pinchart (3): drm: rcar-du: Fix framebuffer reference leak through plane state drm: rcar-du: Do

[PATCH libdrm 4/8] xf86drmSL: Fix neighbour printing

asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150315/e69c32b0/attachment.sig>

[PATCH libdrm v2 1/8] Add static qualifier to local functions

v2: Don't bother marking dead functions static (handler, xf86VDrvMsgVerb, drmSetDebugMsgFunction) Signed-off-by: Jan Vesely --- tests/drmstat.c | 2 +- tests/kmstest/main.c| 2 +- tests/modeprint/modeprint.c | 18 +- tests/proptest/proptest.c | 2 +-

[Bug 94171] ati multihead black on one output

https://bugzilla.kernel.org/show_bug.cgi?id=94171 --- Comment #2 from Felix Miata --- Using the HD from the comment 0 system with the same cedar PCIe card installed in a slightly older P965 system , which has no onboard Intel gfx, both VGA-0 and DVI-0 outputs remain functional in X also with Mage