[RFC PATCH v1 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

Hi Heiko, On 11/22/2015 04:14 AM, Heiko Stuebner wrote: > Hi Yakir, > > Am Mittwoch, 11. November 2015, 15:47:32 schrieb Yakir Yang: >> Signed-off-by: Yakir Yang >> --- >> .../display/rockchip/inno_hdmi-rockchip.txt| 50 >> ++ >> 1 file changed, 50 insertions(+)

[PATCH v2 00/13] drm/exynos: async G2D and g2d_move()

Hello Tobias, I reviewed this whole patchset, and it looks good to me. Also I tested it on my odroid u3, and all works fine. Thanks you for your effort. Tested-by: Hyungwon Hwang Reviewed-by: Hyungwon Hwang BRs, Hyungwon Hwang On Sun, 22 Nov 2015 19:48:30 +0100 Tobias Jakobi wrote: >

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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/20151123/12c47b7c/attachment.html>

[Bug 93032] [radeonsi] gpu lockup after a few minutes of play

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

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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/20151123/59698e69/attachment.html>

[PATCH v2 00/13] drm/exynos: async G2D and g2d_move()

2015년 11월 23일 11:35에 Hyungwon Hwang 이(가) 쓴 글: > Hello Tobias, > > I reviewed this whole patchset, and it looks good to me. Also I tested > it on my odroid u3, and all works fine. Thanks you for your effort. > > Tested-by: Hyungwon Hwang > Reviewed-by: Hyungwon Hwang

[PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

On 11/21/2015 1:29 AM, Rob Herring wrote: > +Stephen > > On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja > wrote: >> Hi Rob, >> >> On 11/18/2015 6:48 PM, Rob Herring wrote: >>> >>> +dt list >>> >>> On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja >>> wrote: Add additional property info

[PATCH v2 1/5] drm/exynos: mixer: refactor layer setup

Hi Tobias, 2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글: > First step in allowing a more generic way to setup complex > blending for the different layers. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 84 > ++- >

[PATCH v2 4/5] drm/exynos: mixer: do blending setup in mixer_cfg_layer()

2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글: > This updates the blending setup when the layer configuration > changes (triggered by mixer_win_{commit,disable}). > > To avoid unnecesary reconfigurations we cache the layer > state in the mixer context. > > Extra care has to be

[PATCH v4 10/13] of: add vendor prefix for boe

; 1 file changed, 1 insertion(+) Applied, with slightly modified commit message. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archiv

[PATCH v4 11/13] drm/panel: simple: Add support for BOE TV080WUM-NL0

ment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/462e78f7/attachment-0001.sig>

[PATCH v4 12/13] drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree binding

opied from the original commit that added the simple-panel binding. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/6672/attachment.sig>

[Bug 92953] Segfault loading UT4 map/server

to revert your dmesg timestamp format to the default and repeat. -- 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/20151123/35610

[PATCH v2 2/5] drm/exynos: mixer: introduce mixer_layer_blending()

2015년 11월 23일 01:09에 Tobias Jakobi 이(가) 쓴 글: > This analyses the current layer configuration (which layers > are enabled, which have alpha-pixelformat, etc.) and setups > blending accordingly. > > We currently disable all kinds of blending for the bottom-most > layer, since

[Bug 92850] Segfault loading War Thunder

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/20151123/06b531c3/attachment.html>

[PATCH i915 v5 2/2] i915: wait for fence in prepare_plane_fb

Op 20-11-15 om 23:09 schreef Alex Goins: > In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive > fence > > v2: First commit > v3: Remove object_name_lock acquire > Move wait from intel_atomic_commit() to intel_prepare_plane_fb() > v4: Wait only on exclusive fences,

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

On Sat, Nov 21, 2015 at 03:22:07PM +0100, Christian König wrote: > On 20.11.2015 16:52, cpaul at redhat.com wrote: > >From: Stephen Chandler Paul > > > >HPD signals on DVI ports can be fired off before the pins required for > >DDC probing actually make contact, due to the pins for HPD making >

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

On Sat, Nov 21, 2015 at 02:49:20PM +, Daniel Stone wrote: > Hi, > > On 21 November 2015 at 14:22, Christian König > wrote: > > On 20.11.2015 16:52, cpaul at redhat.com wrote: > >> This is somewhat rare on most cards (depending on what angle you plug > >> the DVI connector in), but on some

[PATCH 3/8] drm/i915: Use EAGAIN instead EBUSY for aux retry.

On Fri, Nov 20, 2015 at 04:46:25PM -0800, Rodrigo Vivi wrote: > Current EBUSY meaning is immediately retry, but this is > about to change. DRM aux transfer is about to change and > make EAGAIN the immediately retry and use EBUSY to wait > a bit for aux channels to recover for any error or wake up.

[PATCH v2] drm/mm: rewrite drm_mm_for_each_hole

On Sat, Nov 21, 2015 at 10:04:04PM +0800, Geliang Tang wrote: > When backwards is 0, __drm_mm_for_each_hole is same as > drm_mm_for_each_hole. So I rewrite drm_mm_for_each_hole > by using __drm_mm_for_each_hole. > > Signed-off-by: Geliang Tang Applied to drm-misc, thanks. -Daniel > --- >

[PATCH 00/29] dev->struct_mutex crusade, once more

Hi all, Since Daniel Stone pointed out in the last round that I fumbled one locked vs. unlocked case I audited all the drivers once more and uprooted a bunch more offenders. They're mostly in error paths, but in case anyone wants to pick them up I put them at the beginning of the patch series.

[PATCH 01/29] drm/armada: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 02/29] drm/nouveau: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 03/29] drm/omapdrm: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 04/29] drm/amdgpu: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 05/29] drm/radeon: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 06/29] drm/qxl: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 07/29] drm/tegra: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 08/29] drm/msm: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 09/29] drm/udl: Use unlocked gem unreferencing

For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 Author: Daniel Vetter Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check

[PATCH 10/29] drm/armada: Plug leak in dumb_map_offset

We need to drop the gem bo reference if it's an imported one. Cc: Russell King Signed-off-by: Daniel Vetter --- drivers/gpu/drm/armada/armada_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/armada/armada_gem.c

[PATCH 11/29] drm/armada: Don't grab dev->struct_mutex for in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). v2: Split out the leak fix in dump_map_offset into

[PATCH 12/29] drm/armada: Drop struct_mutex from cursor paths

The kms state itself is already protected by the modeset locks acquired by the drm core. The only thing left is gem bo state, and since the cursor code expects small objects which are statically mapped at create time and then invariant over the lifetime of the gem bo there's nothing to protect.

[PATCH 13/29] drm/armada: Use a private mutex to protect priv->linear

Reusing the Big DRM Lock just leaks, and the few things left that dev->struct_mutex protected are very well contained - it's just the linear drm_mm manager. With this armada is completely struct_mutex free! Cc: Russell King Signed-off-by: Daniel Vetter ---

[PATCH 14/29] drm/tegra: don't take dev->struct_mutex in mmap offset ioctl

Since David Herrmann's mmap vma manager rework we don't need to grab dev->struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core still cares). v2: Finally get rid of the copypasta from another

[PATCH 15/29] drm/tegra: Use drm_gem_object_unreference_unlocked

This only grabs the mutex when really needed, but still has a might-acquire lockdep check to make sure that's always possible. With this patch tegra is officially struct_mutex free, yay! v2: refernce_unlocked doesn't exist as kbuild spotted. Cc: Thierry Reding Acked-by: Thierry Reding

[PATCH 16/29] drm/gma500: Use correct unref in the gem bo create function

This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Cc: Patrik Jakobsson Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter ---

[PATCH 17/29] drm/gma500: Drop dev->struct_mutex from modeset code

It's either init code or already protected by other means. Note that psb_gtt_pin/unpin has it's own lock, and that's really the only piece of driver private state - all the modeset state is protected with modeset locks already. The only important bit is to switch all gem_obj_unref calls to the

[PATCH 18/29] drm/gma500: Drop dev->struct_mutex from fbdev init/teardown code

This is init/teardown code, locking is just to appease locking checks. And since gem create/free doesn't need this any more there's really no reason for grabbing dev->struct_mutex. Again important to switch obj_unref to _unlocked variants. Cc: Patrik Jakobsson Acked-by: Patrik Jakobsson

[PATCH 19/29] drm/gma500: Drop dev->struct_mutex from mmap offset function

Simply forgotten about this when I was doing my general cleansing of simple gem mmap offset functions. There's nothing but core functions called here, and they all have their own protection already. Cc: Patrik Jakobsson Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter ---

[PATCH 20/29] drm/gma500: Add driver private mutex for the fault handler

There's currently two places where the gma500 fault handler relies upon dev->struct_mutex: - To protect r->mappping - To make sure vm_insert_pfn isn't called concurrently (in which case the 2nd thread would get an error code). Everything else (specifically psb_gtt_pin) is already protected by

[PATCH 21/29] drm/nouveau: Drop dev->struct_mutex from fbdev init

Doesn't protect anything at all. With this patch nouveau is completely dev->struct_mutex free! Cc: Ben Skeggs Signed-off-by: Daniel Vetter --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c

[PATCH 23/29] drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma

The sg table isn't refcounted, there's no corresponding locking for unmapping and drm_map_sg is ok with being called concurrently. So drop the locking since it doesn't protect anything. Cc: Inki Dae Signed-off-by: Daniel Vetter --- drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 1 file

[PATCH 24/29] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

The only things this protects is reading ->flags and ->size, both of which are invariant over the lifetime of an exynos gem bo. So no locking needed at all (besides that, nothing protects the writers anyway). Aside: exynos_gem_obj->size is redundant with exynos_gem_obj->base.size and probably

[PATCH 25/29] drm/exynos: drop struct_mutex from fbdev setup

Doesn't protect anything at all, and probably just here because a long time ago dev->struct_mutex was required to allocate gem objects. With this patch exynos is completely struct_mutex free! Cc: Inki Dae Signed-off-by: Daniel Vetter --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22

[PATCH 22/29] drm/exynos: Drop dev->struct_mutex from mmap offset function

Simply forgotten about this when I was doing my general cleansing of simple gem mmap offset functions. There's nothing but core functions called here, and they all have their own protection already. Aside: DRM_ERROR for userspace controlled input isn't great, but that's for another patch. v2:

[PATCH 26/29] drm/vgem: Simplify dum_map

The offset manager already checks for existing offsets internally, while holding suitable locks. We can drop this check. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vgem/vgem_drv.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c

[PATCH 28/29] drm/vgem: Drop dev->struct_mutex

With the previous two changes it doesn't protect anything any more. v2: Use _unlocked unreference variant. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vgem/vgem_drv.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c

[PATCH 29/29] drm/vma_manage: Drop has_offset

It's racy, creating mmap offsets is a slowpath, so better to remove it to avoid drivers doing broken things. The only user is i915, and it's ok there because everything (well almost) is protected by dev->struct_mutex in i915-gem. While at it add a note in the create_mmap_offset kerneldoc that

[PATCH 27/29] drm/vgem: Move get_pages to gem_create

vgem doesn't have a shrinker or anything like that and drops backing storage only at object_free time. There's no use in trying to be clever and allocating backing storage delayed, it only causes trouble by requiring locking. Instead grab pages when we allocate the object right away.

[PATCH] v2: Also add a DRIVER_* check like for all other maps functions to really short-circuit the code. And give drm_legacy_rmmap used by the dev unregister code the same treatment.

--- drivers/gpu/drm/drm_bufs.c | 14 ++ include/drm/drm_legacy.h | 2 +- 2 files changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c index de18b8b78a26..5a51633da033 100644 --- a/drivers/gpu/drm/drm_bufs.c +++

[Intel-gfx] [PATCH 1/8] drm: Introduce EAGAIN handling for immediatelly aux retries

On Sat, 21 Nov 2015, Rodrigo Vivi wrote: > The goal here is to offload aux retries handling from the > drivers to drm. > > However there are 2 differents cases for retry: > 1. Immediately retry - Hardware already took care of needed timeouts > before answering that a retry is

[PATCH 3/8] drm/i915: Use EAGAIN instead EBUSY for aux retry.

On Mon, 23 Nov 2015, Daniel Vetter wrote: > On Fri, Nov 20, 2015 at 04:46:25PM -0800, Rodrigo Vivi wrote: >> Current EBUSY meaning is immediately retry, but this is >> about to change. DRM aux transfer is about to change and >> make EAGAIN the immediately retry and use EBUSY to wait >> a bit for

[PATCH v2 2/2] drm/rockchip: Convert the probe function to the generic drm_of_component_probe()

On 2015年11月20日 22:22, Liviu Dudau wrote: > Initial attempt to convert rockchip to drm_of_component_probe() missed the > difference between ports and encoders when using the compare_of() function. > Now that drm_of_component_probe() has been enhanced, let's try again the > conversion. > >

[Intel-gfx] [PATCH 4/8] drm: Wait 1ms before retrying aux transactions on EBUSY.

On Sat, 21 Nov 2015, Rodrigo Vivi wrote: > DP Specs isn't really clear about the amount of retries, > but for cases it mentions retries it also mention times that > vary from 300us to 1ms. > > For many cases hardware can handled the timeouts before retry > is possible and allowed, but for many

[PATCH 6/8] drm/i915: Remove remaining retries from intel_dp_aux_ch.

On Sat, 21 Nov 2015, Rodrigo Vivi wrote: > drm level already takes care of the needed retries so instead of > duplicate the effort here. > > If the retry is possible immediately we return EAGAIN. Otherwise, > if we have no idea what caused the error let's assume something > was busy and let drm

[PATCH 04/29] drm/amdgpu: Use unlocked gem unreferencing

On 23.11.2015 10:32, Daniel Vetter wrote: > For drm_gem_object_unreference callers are required to hold > dev->struct_mutex, which these paths don't. Enforcing this requirement > has become a bit more strict with > > commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 > Author: Daniel Vetter > Date:

[PATCH 7/8] drm/i915: Fix random aux transactions failures.

On Sat, 21 Nov 2015, Rodrigo Vivi wrote: > Mainly aux communications on sink_crc > were failing a lot randomly on recent platforms. > The first solution was to try to use intel_dp_dpcd_read_wake, but then > it was suggested to move retries to drm level. > > Since drm level was already taking care

[PATCH 25/29] drm/exynos: drop struct_mutex from fbdev setup

Hi, On 23 November 2015 at 09:32, Daniel Vetter wrote: > Doesn't protect anything at all, and probably just here because a long > time ago dev->struct_mutex was required to allocate gem objects. > > With this patch exynos is completely struct_mutex free! > > Cc: Inki Dae > Signed-off-by: Daniel

[PATCH 22/29] drm/exynos: Drop dev->struct_mutex from mmap offset function

Hi, On 23 November 2015 at 09:32, Daniel Vetter wrote: > Simply forgotten about this when I was doing my general cleansing of > simple gem mmap offset functions. There's nothing but core functions > called here, and they all have their own protection already. > > Aside: DRM_ERROR for userspace

[PATCH 24/29] drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl

Hi, On 23 November 2015 at 09:32, Daniel Vetter wrote: > The only things this protects is reading ->flags and ->size, both of > which are invariant over the lifetime of an exynos gem bo. So no > locking needed at all (besides that, nothing protects the writers > anyway). > > Aside:

[PATCH 07/29] drm/tegra: Use unlocked gem unreferencing

5 insertions(+), 5 deletions(-) Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/3d5abad2/attachment.sig>

[PATCH 14/29] drm/tegra: don't take dev->struct_mutex in mmap offset ioctl

p-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/ef1ff25c/attachment.sig>

[PATCH 15/29] drm/tegra: Use drm_gem_object_unreference_unlocked

anks. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/47e04a6b/attachment.sig>

[PATCH 23/29] drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma

Hi, On 23 November 2015 at 09:32, Daniel Vetter wrote: > The sg table isn't refcounted, there's no corresponding locking for > unmapping and drm_map_sg is ok with being called concurrently. > > So drop the locking since it doesn't protect anything. > > Cc: Inki Dae > Signed-off-by: Daniel

[PATCH 7/8] drm/i915: Fix random aux transactions failures.

I don't see how the subject matches the commit. On Sat, 21 Nov 2015, Rodrigo Vivi wrote: > This read wake with retries were initially added by 2 commits: > > commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure") > commit 899526d9 ("drm/i915/dp: try to read receiver

[Intel-gfx] [PATCH] v2: Also add a DRIVER_* check like for all other maps functions to really short-circuit the code. And give drm_legacy_rmmap used by the dev unregister code the same treatment.

Accidental patch? On Mon, 23 Nov 2015, Daniel Vetter wrote: > --- > drivers/gpu/drm/drm_bufs.c | 14 ++ > include/drm/drm_legacy.h | 2 +- > 2 files changed, 11 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c > index

[Intel-gfx] [PATCH] v2: Also add a DRIVER_* check like for all other maps functions to really short-circuit the code. And give drm_legacy_rmmap used by the dev unregister code the same treatment.

On Mon, Nov 23, 2015 at 12:15:18PM +0200, Jani Nikula wrote: > > Accidental patch? Yup, dunno how that one ended up in there ... -Daniel > > On Mon, 23 Nov 2015, Daniel Vetter wrote: > > --- > > drivers/gpu/drm/drm_bufs.c | 14 ++ > > include/drm/drm_legacy.h | 2 +- > > 2

[PATCH] drm/atomic_helper: Add drm_atomic_helper_disable_planes_on_crtc()

Add drm_atomic_helper_disable_planes_on_crtc() for disabling all planes associated with the given CRTC. This can be used for instance in the CRTC helper disable callback to disable all planes before shutting down the display pipeline. Signed-off-by: Jyri Sarha --- This a follow version to

[PATCH] drm/panel: simple: Add support for G121X1-L03

t -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/dd98523b/attachment-0001.sig>

[PATCH] drm/panel: simple: Add Innolux N133HSE panel support

text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/4592bcf8/attachment.sig>

[PATCH 2/3] panel/panasonic-vvx10f034n00: Add DT bindings

as scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/2d2400f0/attachment.sig>

[PATCH 3/3] drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel

<http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/3fe29412/attachment.sig>

[PATCH v2 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/7d017ad9/attachment.sig>

[PATCH v2 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

p.org/archives/dri-devel/attachments/20151123/9eb76c67/attachment.sig>

[PATCH 2/5] drm/imx: ipuv3 crtc: Cleanup ipu planes in ipu_crtc_init() when necessary

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying: > To avoid memory leakage, we need to cleanup the initialized ipu planes in > the bailout path of ipu_crtc_init(). > > Signed-off-by: Liu Ying > --- > This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git. > >

[PATCH 4/5] drm/imx: ipuv3 plane: Use the helper ipu_plane_cleanup() in ipu_plane_destroy()

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying: > To reduce code duplication, we can use the helper ipu_plane_cleanup() in > ipu_plane_destroy(). > > Signed-off-by: Liu Ying > --- > This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git. > >

[PATCH 1/5] drm/imx: ipuv3 plane: Introduce ipu_plane_cleanup()

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying: > This patch adds a helper ipu_plane_cleanup() to cleanup a IPU plane. > It can be used in the bailout path of ipu_crtc_init(), for instance. > > Signed-off-by: Liu Ying > --- > This patch applies to the imx-drm/fixes branch of Philipp

[PATCH 3/5] drm/imx: ipuv3 crtc: Cleanup ipu planes in ipu_drm_unbind()

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying: > To avoid memory leakage, we need to cleanup ipu planes in ipu_drm_unbind(). > > Signed-off-by: Liu Ying > --- > This patch applies to the imx-drm/fixes branch of Philipp Zabel's open git. > > drivers/gpu/drm/imx/ipuv3-crtc.c | 5 +

[PATCH 5/5] drm/imx: ipuv3 plane: Replace dev_info with dev_dbg if a plane's CRTC changes

Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying: > This patch changes the dev_info() call to dev_dbg() in ipu_plane_update() > to print out the information that a plane's CRTC is changed, because this > kind of information is only useful for debugging. > > Signed-off-by: Liu Ying > ---

[Bug 80419] XCOM: Enemy Unknown Causes lockup

RL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/e864bcd2/attachment.html>

[PATCH 2/2] drm/rockchip: Send events for same-fb flips

Hi, 于 2015年11月16日 20:50, Daniel Stone 写道: > Rockchip previously treated a pageflip to the same framebuffer as a > no-op, discarding the event if one was requested. This breaks Weston, > which, when idle, sends a no-op vblank event to discover vblank > timings if the vblank query

[PATCH v5 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

This patch adds drm_bridge driver for parade DSI to eDP bridge chip. Signed-off-by: Jitao Shi --- Change since v4 -fix build error, change Kconfig DRM_PARADE_PS8640 from bool to tristate --- drivers/gpu/drm/bridge/Kconfig | 10 + drivers/gpu/drm/bridge/Makefile|1 +

[PATCH v5 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

Add documentation for DT properties supported by ps8640 DSI-eDP converter. Signed-off-by: Jitao Shi Acked-by: Rob Herring Reviewed-by: Philipp Zabel --- Changes since v4 -no change --- .../devicetree/bindings/display/bridge/ps8640.txt | 43 1 file changed, 43

[PATCH v2 0/7] drm/exynos: add pm runtime support

Hello, On 11/21/2015 11:59 AM, Inki Dae wrote: > Hi Daniel, > > > 2015-11-21 22:40 GMT+09:00 Daniel Stone : >> Hi Inki, >> >> On 21 November 2015 at 09:38, Inki Dae wrote: >>> 2015-11-21 1:44 GMT+09:00 Javier Martinez Canillas >> osg.samsung.com>: On 11/20/2015 08:13 AM, Inki Dae wrote:

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

> -Original Message- > From: Lyude [mailto:cpaul at redhat.com] > Sent: Sunday, November 22, 2015 9:45 PM > To: Koenig, Christian; Daniel Stone > Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing List; > Jerome Glisse; Benjamin Tissoires > Subject: Re: [PATCH]

[Bug 108221] amdgpu: mouse cursor flickers + black boxes

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

[Bug 92996] [Fiji/amdgpu/Powerplay] Problems with vsync, interactivity, performance, EQ overflow with Powerplay

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/d861bdea/attachment-0001.html>

[PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

On Mon, 2015-11-23 at 14:20 +, Deucher, Alexander wrote: > > -Original Message- > > From: Lyude [mailto:cpaul at redhat.com] > > Sent: Sunday, November 22, 2015 9:45 PM > > To: Koenig, Christian; Daniel Stone > > Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing

[PATCH] drm/imx: parallel-display: allow to determine bus format from the connected panel

Philipp, All, On Fri, Nov 20, 2015 at 01:46:39PM +0100, Philipp Zabel wrote: > Similarly to commit 5e501ed7253b3 ("drm/imx: imx-ldb: allow to determine > bus format from the connected panel"), if a panel is connected to the ldb > output port via the of_graph bindings, the data mapping is

[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4

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/20151123/de477148/attachment.html>

[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/734510ca/attachment.html>

[Bug 92850] Segfault loading War Thunder

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

[PATCH 0/4] Component helper updates

Greg, These four patches update the component helper by: * Removing the legacy matching code with the .add_components method in the master's operation structure. Nothing in -rc1 appears to be using the legacy functions or method, according to my git greps. * A slight code reorganisation

[Bug 93080] War Thunder launcher no longer loads

-devel/attachments/20151123/fd6683b5/attachment-0001.html>

[Bug 93080] War Thunder launcher no longer loads

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151123/5d274203/attachment.html>

[PATCH] drm/atomic_helper: Add drm_atomic_helper_disable_planes_on_crtc()

On Mon, Nov 23, 2015 at 12:44:35PM +0200, Jyri Sarha wrote: > Add drm_atomic_helper_disable_planes_on_crtc() for disabling all > planes associated with the given CRTC. This can be used for instance > in the CRTC helper disable callback to disable all planes before > shutting down the display

[PATCH 1/4] component: remove old add_components method

Now that drivers create an array of component matches at probe time, we can retire the old methods. This involves removing the add_components master method, and removing component_master_add_child() from public view. We also remove component_add_master() as that interface is no longer useful.

[PATCH 3/4] component: track components via array rather than list

Since we now have an array which defines each component, maintain the components to be bound in the array rather than a separate list. We also need duplicate tracking so we can eliminate multiple bind calls for the same component: we preserve the list-based component order in that the first match

[PATCH 4/4] component: add support for releasing match data

The component helper treats the void match data pointer as an opaque object which needs no further management. When device nodes being passed, this is not true: the caller should pass its refcount to the component helper, and there should be a way to drop the refcount when the matching

  1   2   >