[PATCH] drm: Wrap direct calls to driver->gem_free_object from CMA

Since the introduction of (struct_mutex) lockless GEM bo freeing, there are a pair of driver vfuncs for freeing the GEM bo, of which the driver may choose to only implement driver->gem_object_free_unlocked (and so avoid taking the struct_mutex along the free path). However, the CMA GEM helpers

[Bug 96296] clpeak causes a GPU hang

as scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/7fd54e9b/attachment.html>

[PATCH 0/6] drm/i915: Remaining PSR fixes

On Tue, May 31, 2016 at 09:07:49PM +0200, Daniel Vetter wrote: > On Tue, May 31, 2016 at 06:50:24PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > Here's a repost of my PSR fixes, and one straggler from Daniel. > > > > One interesting thing I noticed is that

[RFC PATCH v1 2/2] drm/rockchip: analogix: add eDP PSR function

The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this would make a lots of sense to save the power consumption. For example, when desktop haven't change the context for a long time, then we could refresh the data to the hardware

[RFC PATCH v1 1/2] drm/rockchip: add a notify event about vblank enable/disable

EDP PSR function is interesting in vblank enable or disable event, so it would be great introduce a way to notify encoder about this event. Signed-off-by: Yakir Yang --- drivers/gpu/drm/rockchip/Makefile | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_notify.c | 66

[RFC PATCH v1 0/2]

The full name of PSR is Panel Self Refresh, panel device could refresh itself with the hardware framebuffer in panel, this would make a lots of sense to save the power consumption. For example, when desktop haven't change the context for a long time, then we could refresh the data to the hardware

[PATCH 07/26] drm/exynos: Use for_each_crtc_in_state

2016-05-30 3:35 GMT+09:00 Daniel Vetter : > We want to hide drm_atomic_state internals better. > Acked-by: Inki Dae > Cc: Inki Dae > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git

[PATCH 15/27] drm/vc4: Use lockless gem BO free callback

On Tue, May 31, 2016 at 10:23:32AM -0700, Eric Anholt wrote: > Daniel Vetter writes: > > > No dev->struct_mutex anywhere to be seen. > > The vc4 patches are: > > Reviewed-by: Eric Anholt Thanks for the review, both applied to drm-misc. -Daniel -- Daniel Vetter Software Engineer, Intel

[PATCH 0/6] drm/i915: Remaining PSR fixes

On Tue, May 31, 2016 at 06:50:24PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > Here's a repost of my PSR fixes, and one straggler from Daniel. > > One interesting thing I noticed is that my SKL actually hits the PSR setup > time vs. vblank length check, so after

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Tue, May 31, 2016 at 06:58:34PM +0200, Luis R. Rodriguez wrote: > On Sun, May 29, 2016 at 08:27:07PM +0200, Daniel Vetter wrote: > > On Fri, May 27, 2016 at 3:18 AM, Luis R. Rodriguez > > wrote: > > > To get KFD support in radeon we need the following > > > initialization to happen in this

[Bug 96296] clpeak causes a GPU hang

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/0e310200/attachment.html>

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Tue, May 31, 2016 at 8:15 PM, Luis R. Rodriguez wrote: > On Sun, May 29, 2016 at 05:49:17PM +0300, Oded Gabbay wrote: >> On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez >> wrote: >> > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c >> > b/drivers/gpu/drm/radeon/radeon_drv.c >> > index

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Sun, May 29, 2016 at 05:49:17PM +0300, Oded Gabbay wrote: > On Fri, May 27, 2016 at 4:18 AM, Luis R. Rodriguez > wrote: > > diff --git a/drivers/gpu/drm/radeon/radeon_drv.c > > b/drivers/gpu/drm/radeon/radeon_drv.c > > index b55aa740171f..1fa1b7f3a89c 100644 > > ---

[PATCH 00/27] locklesss gem BO free driver patches

Hi Daniel! On 30 May 2016 at 23:22, Daniel Vetter wrote: > HI all, > > Here's the pile of lockless gem BO free conversion patches. Assuming I didn't > botch it these are all the ones that didn't yet get an ack. Since this is all > pretty boring stuff I'll just send a pull request to Dave later

[RFT v3] drm: use late_initcall() for amdkfd and radeon

On Sun, May 29, 2016 at 08:27:07PM +0200, Daniel Vetter wrote: > On Fri, May 27, 2016 at 3:18 AM, Luis R. Rodriguez > wrote: > > To get KFD support in radeon we need the following > > initialization to happen in this order, their > > respective driver file that has its init routine > > listed

[PATCH 6/6] drm/i915: Move psr.link_standby setup to intel_psr_match_conditions()

From: Ville Syrjälä Determine the value of psr.link_standby at runtime rather than at init time. This helps in testing since you can change between link-off and link-standby at runtime. Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä ---

[PATCH 5/6] drm/i915: Ask the sink whether training is required when exiting PSR main-link off mode

From: Ville Syrjälä The sink can tell us if link training needs to be performed when exiting PSR main-link off mode. Currently we get that information from the VBT, but at least on my HSW the VBT says one thing, the sink another. And in practice the sink doesn't

[PATCH 4/6] drm/i915/psr: Skip aux handeshake if the vbt tells us to

From: Daniel Vetter Not sure we can trust VBT on this one, but let's try. Cc: Rodrigo Vivi Cc: Sonika Jindal Cc: Durgadoss R Signed-off-by: Daniel Vetter Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_psr.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH 3/6] drm/i915: Check PSR setup time vs. vblank length

From: Ville Syrjälä Bspec says: "Restriction : SRD must not be enabled when the PSR Setup time from DPCD 00071h is greater than the time for vertical blank minus one line." Let's check for that and disallow PSR if we exceed the limit. Cc: Daniel Vetter

[PATCH v2 2/6] drm/dp: Add drm_dp_psr_need_train_on_exit()

From: Ville Syrjälä Add a small helper to parse from the DPCD whether link training is required when exiting PSR main-link off mode. v2: Rebased Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_dp_helper.c

[PATCH v2 1/6] drm/dp: Add drm_dp_psr_setup_time()

From: Ville Syrjälä Add a small helper to parse the PSR setup time from the DPCD PSR capabilities and return the value in microseconds. v2: Don't waste so many bytes on the psr_setup_time_us[] table Cc: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by:

[PATCH 0/6] drm/i915: Remaining PSR fixes

From: Ville Syrjälä Here's a repost of my PSR fixes, and one straggler from Daniel. One interesting thing I noticed is that my SKL actually hits the PSR setup time vs. vblank length check, so after these patches that machine won't actually use PSR. The panel

[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch

org/archives/dri-devel/attachments/20160531/54493392/attachment.html>

[Bug 93217] [tonga] [powerplay] Radon M395X isn't initialised with the powerplay branch

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160531/a6bb9a80/attachment.html>

[PATCH] drm: Wrap direct calls to driver->gem_free_object from CMA

Verified working on rpi2. Tested-by: Robert Foss On 2016-05-31 05:25 PM, Chris Wilson wrote: > Since the introduction of (struct_mutex) lockless GEM bo freeing, there > are a pair of driver vfuncs for freeing the GEM bo, of which the driver > may choose to only implement

[PATCH v2 10/10] drm/imx: atomic phase 3 step 5: Advertise DRIVER_ATOMIC

With all the beforehand phases and steps done, we can adverstise DRIVER_ATOMIC. Signed-off-by: Liu Ying --- v1->v2: * None. drivers/gpu/drm/imx/imx-drm-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/imx-drm-core.c

[PATCH v2 09/10] drm/imx: atomic phase 3 step 4: Use generic atomic page flip

To support generic atomic page flip, this patch customizes ->atomic_commit for nonblock commits. Signed-off-by: Liu Ying --- v1->v2: * s/async/nonblock/ on this patch to address Daniel Vetter's comment. * Wait for pending commit on each CRTC for both block and nonblock atomic mode settings.

[PATCH v2 08/10] drm/imx: atomic phase 3 step 3: Legacy callback fixups

Now that we can use atomic configurations, all the legacy callbacks of CRTCs, encoders and connectors can be switched to the atomic version. For the imx-ldb driver, there is a clock parent setting mismatch bewteen ->enable and ->disable after the switch, so a fixup is added. For the imx-tve

[PATCH v2 07/10] drm/imx: atomic phase 3 step 2: Use atomic configuration

Replacing drm_crtc_helper_set_config() by drm_atomic_helper_set_config() and converting the suspend/resume operations to atomic makes us be able to use atomic configurations. All of these allow us to remove the crtc_funcs->mode_set callback as it is no longer used. Also, we may remove all the

[PATCH v2 06/10] drm/imx: atomic phase 3 step 1: Atomic updates for planes

This patch switches the update/disable_plane callbacks to their atomic version. Also, use the default atomic helpers to implement the atomic_check/commit callbacks for mode configuration. Signed-off-by: Liu Ying --- v1->v2: * None. drivers/gpu/drm/imx/imx-drm-core.c | 3 +++

[PATCH v2 05/10] drm/imx: atomic phase 2 step 2: Track plane_state->fb correctly in ->page_flip

Use drm_atomic_set_fb_for_plane() in the legacy ->page_flip path to track the pointer plane_state->fb correctly. Signed-off-by: Liu Ying --- v1->v2: * None. drivers/gpu/drm/imx/ipuv3-crtc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c

[PATCH v2 04/10] drm/imx: atomic phase 2 step 1: Wire up state ->reset, ->duplicate and ->destroy

Wire up CRTCs', planes' and connectors' ->reset, ->duplicate and ->destroy state hooks to use the default implementations from the atomic helper library. The helpers track each DRM object state. Signed-off-by: Liu Ying --- v1->v2: * Remove the 'atomic' from the name of the structure

[PATCH v2 03/10] drm/imx: atomic phase 1: Use transitional atomic CRTC and plane helpers

Use the drm_plane_helper_update/disable() and drm_helper_crtc_mode_set() transitional atomic helpers. The crtc->mode_set_nofb callback is added so that the primary plane is no longer tied to the CRTC. Check/update logics are separated to make sure crtc->mode_set_nofb and plane->atomic_update are

[PATCH v2 02/10] gpu: ipu-v3: ipu-dmfc: Use static DMFC FIFO allocation mechanism

For all video modes we support currently, we always get 2 slots for a plane by using the current existing dynamic DMFC FIFO allocation mechanism. So, let's change to use the static one to simplify the code. This also makes it easier to implement the atomic mode setting as we don't need to handle

[PATCH v2 01/10] drm/imx: ipuv3 plane: Check different types of plane separately

The IPUv3 primary plane doesn't support partial off screen. So, this patch separates plane check logics for primary plane and overlay plane and adds more limitations on the primary plane. Signed-off-by: Liu Ying --- v1->v2: * Remove an unnecessary copy to address Philipp's comment.

[PATCH v2 00/10] imx drm atomic mode setting conversion

Hi, This patch set converts imx drm into atomic mode setting. It takes 3 phases to achieve the goal as recommended. v1->v2: * Rebase onto Philipp Zabel's open git branch imx-drm/next as Philipp required. * Drop patch 05/14 and 10/14 in v1 which touch drm core to disable plane in transitional

[PATCH 18/18] staging/android: add DEBUG_FS dependence on Kconfig

From: Gustavo Padovan SW_SYNC only works with DEBUG_FS so state it in the Kconfig file. Signed-off-by: Gustavo Padovan --- drivers/staging/android/Kconfig | 1 + drivers/staging/android/sync_debug.c | 4 drivers/staging/android/sync_debug.h | 4 +---

[PATCH 17/18] staging/android: rename sync.h to sync_debug.h

From: Gustavo Padovan This header file only contains information for debugging and SW_SYNC, so rename it to sync_debug.h instead of having a more generic name. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c| 2 +-

[PATCH 16/18] staging/android: remove drv_name from sync_timeline

From: Gustavo Padovan As it is internal to sw_sync now this value will always be "sw_sync". Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c| 11 +++ drivers/staging/android/sync.h | 2 --

[PATCH 15/18] staging/android: remove sync_timeline_destroy()

From: Gustavo Padovan This function was just used by the file release function, so we just fold its content there and remove sync_timeline_destroy(). Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c | 19 +++ 1 file changed,

[PATCH 14/18] staging/android: remove 'destroyed' member from struct sync_timeline

From: Gustavo Padovan 'destroyed' was set but not used ny anyone. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c | 5 - drivers/staging/android/sync.h| 5 + 2 files changed, 1 insertion(+), 9 deletions(-) diff --git

[PATCH 13/18] staging/android: make sw_ioctl info internal to sw_sync.c

From: Gustavo Padovan We don't want to export this from the kernel. This is interface is only for testing and debug. So testers shall copy the ioctl info in their own projects. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c | 13

[PATCH 12/18] staging/android: make sync_timeline internal to sw_sync

From: Gustavo Padovan The only use sync_timeline will have in upstream kernel is for debugging through the SW_SYNC interface. So make it internal to SW_SYNC to avoid people use it in the future. Signed-off-by: Gustavo Padovan ---

[PATCH 11/18] staging/android: clean up #includes in the sync framework

From: Gustavo Padovan Most of the includes there are not necessary anymore. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 6 -- drivers/staging/android/sync.h | 3 --- drivers/staging/android/sync_debug.c | 16

[PATCH 10/18] staging/android: move sw_sync related code to sw_sync.c

From: Gustavo Padovan Split sync_debug and sw_sync in two different files. Signed-off-by: Gustavo Padovan --- drivers/staging/android/Makefile | 1 + drivers/staging/android/sw_sync.c| 136 +++

[PATCH 09/18] staging/android: bring struct sync_pt back

From: Gustavo Padovan Move the list_head members from sync_pt to struct fence was a mistake, they will not be used by struct fence as planned before, so here we create sync_pt again to bring the list heads back. Signed-off-by: Gustavo Padovan ---

[PATCH 08/18] staging/android: remove size arg of sync_timeline_create()

From: Gustavo Padovan After we removed sw_sync_timeline this arg has not been really used by anyone, all its users pass the size of struct sync_timeline there. So simplify this function but not requiring the size anymore. Signed-off-by: Gustavo Padovan ---

[PATCH 07/18] staging/android: remove unnecessary check for fence

From: Gustavo Padovan When we call sync_print_fence() fence is always valid. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync_debug.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/android/sync_debug.c

[PATCH 06/18] staging/android: rename android_fence to timeline_fence

From: Gustavo Padovan We are moving out of staging/android so rename it to a name that is not related to android anymore. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sync.c | 36 ++-- 1 file changed, 18

[PATCH 05/18] staging/android: remove sw_sync.[ch] files

From: Gustavo Padovan We can glue the sw_sync file operations directly on the sync framework without the need to pass through sw_sync wrappers. It only builds sw_sync debugfs file support if CONFIG_SW_SYNC is enabled. Signed-off-by: Gustavo Padovan ---

[PATCH 04/18] staging/android: remove sw_sync_timeline and sw_sync_pt

From: Gustavo Padovan As we moved value storage to sync_timeline and fence those two structs became useless and can be removed now. Signed-off-by: Gustavo Padovan --- drivers/staging/android/sw_sync.c| 24 +++-

[PATCH 03/18] staging/android: remove struct sync_timeline_ops

From: Gustavo Padovan Move drv_name, the last field of sync_timeline_ops, to sync_timeline and remove sync_timeline_ops. struct sync_timeline_ops was just an extra abstraction on top of fence_ops, and in the last few commits we removed all it ops in favor of

[PATCH 02/18] staging/android: remove .{fence, timeline}_value_str() from timeline_ops

From: Gustavo Padovan Now that the value of fence and the timeline are not stored by sw_sync anymore we can remove this extra abstraction to retrieve this data. This patch changes both fence_ops (.fence_value_str and .timeline_value_str) to return the str

[PATCH 01/18] staging/android: store last signaled value on sync timeline

From: Gustavo Padovan Now fence timeline is aware of the last signaled fence, as it receives the increment to the current value in sync_timeline_signal(). That allow us to remove .has_signaled() from timeline_ops as we can directly compare using timeline->value

[PATCH 00/18] staging/android: clean up SW_SYNC

From: Gustavo Padovan Hi, The following patches do a clean up on the sw_sync inteface. It starts by removing struct sync_timeline_ops, which was creating unecessary wrappers in the code and the start to organize the sync_timeline and sw_sync code better.

[PATCH 4/5] add cursor hotspot to drm_framebuffer

On Tue, May 31, 2016 at 03:09:13PM +0200, Gerd Hoffmann wrote: > On Di, 2016-05-31 at 15:36 +0300, Ville Syrjälä wrote: > > > Why store it in the fb and not eg. the plane state? > > Well, drm_plane_state is allocated by drm_atomic_helper_update_plane. > > When sticking the hotspot into the

[RFC PATCH v1 0/2]

On Tue, May 31, 2016 at 09:37:36PM +0800, Yakir Yang wrote: > The full name of PSR is Panel Self Refresh, panel device could refresh > itself with the hardware framebuffer in panel, this would make a lots > of sense to save the power consumption. > > For example, when desktop haven't change the

[RFC PATCH v1 1/2] drm/rockchip: add a notify event about vblank enable/disable

On Tue, May 31, 2016 at 09:39:19PM +0800, Yakir Yang wrote: > EDP PSR function is interesting in vblank enable or disable event, > so it would be great introduce a way to notify encoder about this > event. > > Signed-off-by: Yakir Yang notifiers considered evil, especially if you add a global

[PATCH] drm/omap: rename panel/encoder Kconfig names

omapdrm is using much too generic Kconfig names for its panels and encoders. Rename them to have "DRM_OMAP" in the name. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/displays/Kconfig | 28 ++-- drivers/gpu/drm/omapdrm/displays/Makefile | 28

[Intel-gfx] [PATCH] drm/atomic-helper: nonblocking commit support

On Tue, May 31, 2016 at 04:22:57PM +0200, Maarten Lankhorst wrote: > Op 30-05-16 om 10:01 schreef Daniel Vetter: > > Design ideas: > > > > - split up the actual commit into different phases, and have > > completions for each of them. This will be useful for the future > > when we want to

[Intel-gfx] [PATCH] drm/atomic-helper: nonblocking commit support

Op 30-05-16 om 10:01 schreef Daniel Vetter: > Design ideas: > > - split up the actual commit into different phases, and have > completions for each of them. This will be useful for the future > when we want to interleave phases much more aggressively, for e.g. > queue depth > 1. For not it's

[PATCH 2/3] drm/exynos: fimd: add HW trigger support

On 2016-05-30 23:58, Javier Martinez Canillas wrote: > Hello Inki, > > On 04/05/2016 04:27 AM, Inki Dae wrote: >> This patch adds HW trigger support on i80 mode. >> >> Until now, Exynos DRM only supported SW trigger which was set >> SWTRGCMD bit of TRIGCON register by CPU to transfer scanout >>

[Bug 93216] Artifacts with DCC when render target also texture

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/19e4e1a8/attachment.html>

[PATCH v2 0/10] Add RK3399 eDP support and fix some bugs to analogix_dp driver.

Hello Yakir, On 05/27/2016 02:16 AM, Yakir Yang wrote: > Hi Javier, > > On 05/26/2016 08:48 PM, Javier Martinez Canillas wrote: >> Hello Yakir, >> >> On 05/26/2016 05:34 AM, Yakir Yang wrote: >>> Hi Javier, >>> >>> On 05/24/2016 01:01 PM, Yakir Yang wrote: Hi all, This series have

[Bug 94860] [radeonsi/amdgpu][DCC] screen is corrupted when logging out of kde

was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/91ce6f0c/attachment.html>

[Bug 94860] [radeonsi/amdgpu][DCC] screen is corrupted when logging out of kde

was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/943c9c1a/attachment-0001.html>

[PATCH] drm: hdlcd: Cleanup the atomic operations

Dispatch DRM pending events from crtc_atomic_flush() and not from the IRQ handler. Don't disable the vsync interrupt, as the hardware lacks hardware counters for vsync time stamping. Signed-off-by: Liviu Dudau --- This replaces the previous patch "drm: hdlcd: Replace the mode config's

[PATCH 4/5] add cursor hotspot to drm_framebuffer

On Tue, May 31, 2016 at 12:53:12PM +0200, Gerd Hoffmann wrote: > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/drm_crtc.c | 2 ++ > include/drm/drm_crtc.h | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index

[PATCH 01/10] drm: Initialize a linear gamma table by default

Op 31-05-16 om 15:24 schreef Daniel Vetter: > On Tue, May 31, 2016 at 03:05:32PM +0200, Maarten Lankhorst wrote: >> Op 30-03-16 om 11:51 schreef Daniel Vetter: >>> Code stolen from gma500. >> It would be useful to mention why this is done. :) >> >> But even with this patch it seems the legacy

[PATCH 16/27] drm/vgem: Use lockless gem BO free callback

On Tue, May 31, 2016 at 09:20:07AM -0400, Sean Paul wrote: > On Mon, May 30, 2016 at 1:53 PM, Daniel Vetter > wrote: > > No dev->struct_mutex anywhere to be seen. > > > > Cc: seanpaul at chromium.org > > Signed-off-by: Daniel Vetter > > Reviewed-by: Sean Paul Applied to drm-misc, thanks for

[PATCH 09/10] drm/qxl: Don't set a gamma table size

On Tue, May 31, 2016 at 03:17:57PM +0200, Maarten Lankhorst wrote: > Op 30-03-16 om 11:51 schreef Daniel Vetter: > > qxl doesn't have any functions for setting the gamma table, so this is > > completely defunct. > > > > Not nice to lie to userspace, so let's stop! > Reviewed-by: Maarten Lankhorst

[PATCH 02/10] drm/fb-helper: Remove dead code in setcolreg

On Tue, May 31, 2016 at 03:09:42PM +0200, Maarten Lankhorst wrote: > Op 30-03-16 om 11:51 schreef Daniel Vetter: > > DRM fbdev emulation only supports pallete_color with depth == 8, and > > truecolor with depth > 8. Handling depth == 16 for palettes is hence > > dead code, let's remove it. >

[PATCH 01/10] drm: Initialize a linear gamma table by default

On Tue, May 31, 2016 at 03:05:32PM +0200, Maarten Lankhorst wrote: > Op 30-03-16 om 11:51 schreef Daniel Vetter: > > Code stolen from gma500. > It would be useful to mention why this is done. :) > > But even with this patch it seems the legacy gamma in gamma_get is not very > reliable. > A

[GIT PULL] omapdrm fixes for 4.7

A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/3cc648f7/attachment.sig>

[PATCH 06/10] drm/msm: Nuke dummy gamma_set/get functions

Op 30-03-16 om 11:51 schreef Daniel Vetter: > Again the fbdev emulation gamma_set/get functions are only needed for > drivers that try to also use 8bpp paletted mode. Which msm doesn't, so > this is dead code. Let's rip it out. > > Cc: Rob Clark > Signed-off-by: Daniel Vetter Reviewed-by:

[PATCH 09/10] drm/qxl: Don't set a gamma table size

Op 30-03-16 om 11:51 schreef Daniel Vetter: > qxl doesn't have any functions for setting the gamma table, so this is > completely defunct. > > Not nice to lie to userspace, so let's stop! Reviewed-by: Maarten Lankhorst

[PATCH 05/10] drm/cirrus: Drop redundnant gamma size check

Op 30-03-16 om 11:51 schreef Daniel Vetter: > The core does this for us already. Unfortunately some other drivers do the same. :( various variations of end = min_t(start + size, 256); I'll kill the rest off when killing start parameter and returning int. Reviewed-by: Maarten Lankhorst

[PATCH 02/10] drm/fb-helper: Remove dead code in setcolreg

Op 30-03-16 om 11:51 schreef Daniel Vetter: > DRM fbdev emulation only supports pallete_color with depth == 8, and > truecolor with depth > 8. Handling depth == 16 for palettes is hence > dead code, let's remove it. Hooray, less chance for failure! Reviewed-by: Maarten Lankhorst

[PATCH 4/5] add cursor hotspot to drm_framebuffer

On Di, 2016-05-31 at 15:36 +0300, Ville Syrjälä wrote: > Why store it in the fb and not eg. the plane state? Well, drm_plane_state is allocated by drm_atomic_helper_update_plane. When sticking the hotspot into the the plane state we have to add hot_x and hot_y parameters to

[Bug 94860] [radeonsi/amdgpu][DCC] screen is corrupted when logging out of kde

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/ea213ff5/attachment-0001.html>

[PATCH 01/10] drm: Initialize a linear gamma table by default

Op 30-03-16 om 11:51 schreef Daniel Vetter: > Code stolen from gma500. It would be useful to mention why this is done. :) But even with this patch it seems the legacy gamma in gamma_get is not very reliable. A failed call to gamma_set could leave wrong values in crtc->gamma_store either by

[PATCHv2 4/4] drm: fix fb refcount issue with atomic modesetting

After commit 027b3f8ba9277410c3191d72d1ed2c6146d8a668 ("drm/modes: stop handling framebuffer special") extra fb refs are left around when doing atomic modesetting. The problem is that the new drm_property_change_valid_get() does not return anything in the '**ref' parameter, which causes

[PATCHv2 3/4] drm: make drm_atomic_set_mode_prop_for_crtc() more reliable

drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so old data may be left there when a new mode is set, possibly causing odd issues. This patch improves the situation by always clearing the state->mode first. Signed-off-by: Tomi Valkeinen Cc: stable at vger.kernel.org ---

[PATCHv2 2/4] drm/sti: remove extra mode fixup

Commit 652353e6e561c2aeeac62df183f721f6f9b5b45f ("drm/sti: set CRTC modesetting parameters") added a hack to avoid warnings related to setting mode with atomic API. With the previous patch, the hack should no longer be necessary. Signed-off-by: Tomi Valkeinen Cc: Benjamin Gaignard Cc: Vincent

[PATCHv2 1/4] drm: add missing drm_mode_set_crtcinfo call

When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data

[PATCHv2 0/4] drm: fix two atomic modesetting issues on v4.7-rc1

These fix two atomic modesetting issues on v4.7-rc1. The last one is a bit of an RFC. Changes to v1: - drop unnecessary cleanups from "drm: make drm_atomic_set_mode_prop_for_crtc() more reliable". - Cc stable where appropriate - Add "Fixes:" to "drm: fix fb refcount issue with atomic

[PATCHv2 3/4] drm: make drm_atomic_set_mode_prop_for_crtc() more reliable

On Tue, May 31, 2016 at 03:03:17PM +0300, Tomi Valkeinen wrote: > drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so > old data may be left there when a new mode is set, possibly causing odd > issues. > > This patch improves the situation by always clearing the state->mode >

[PATCH] virtio-gpu: use src not crtc

Pick up the correct source rectangle from framebuffer. Without this multihead setups are not working correctly. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git

[Intel-gfx] [PATCH 12/26] drm/atomic-helper: Massage swap_state signature somewhat

Op 31-05-16 om 12:46 schreef Daniel Vetter: > On Tue, May 31, 2016 at 10:43:56AM +0200, Maarten Lankhorst wrote: >> Op 30-05-16 om 17:09 schreef Daniel Vetter: >>> On Mon, May 30, 2016 at 03:08:39PM +0200, Maarten Lankhorst wrote: Op 29-05-16 om 20:35 schreef Daniel Vetter: > - dev is

[Nouveau] [PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM

On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > Do you have any suggestions for the case where the pcieport driver > refuses to put the bridge in D3 (because the BIOS is too old)? In that > case the nouveau driver needs to fallback to the DSM method (but not > when runtime PM is

[RFC v2] dma-mapping: Use unsigned long for dma_attrs

On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote: > The dma-mapping core and the implementations do not change the > DMA attributes passed by pointer. Thus the pointer can point to const > data. However the attributes do not have to be a bitfield. Instead > unsigned long will

[PATCH 16/26] drm/hdlcd: Use helper support for nonblocking commits

On Tue, May 31, 2016 at 01:07:15PM +0200, Daniel Vetter wrote: > On Tue, May 31, 2016 at 12:02:23PM +0100, Liviu Dudau wrote: > > On Sun, May 29, 2016 at 08:35:13PM +0200, Daniel Vetter wrote: > > > Again, just doing them as blocking commits isn't cool. > > > > > > From a cursory check hdlcd does

[libdrm][PATCH] drm: fix multi GPU drmGetDevices only return one device

From: Qiang Yu When multi GPU present, after drmFoldDuplicatedDevices merge same busid deveces, two different devices may be seperated by zero in local_devices[]. The for loop should check all local_devices instead of exit when meet a zero. Change-Id:

[Bug 94860] [radeonsi/amdgpu][DCC] screen is corrupted when logging out of kde

<https://lists.freedesktop.org/archives/dri-devel/attachments/20160531/0feccc41/attachment.html>

[Nouveau] [PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload

On Tue, May 31, 2016 at 01:34:43PM +0200, Lukas Wunner wrote: > On Mon, May 30, 2016 at 07:03:46PM +0200, Peter Wu wrote: > > On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote: > > > How exactly did you reach the situation where the root port didn't wake > > > up when you tried to load

[Nouveau] [PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload

On Mon, May 30, 2016 at 07:03:46PM +0200, Peter Wu wrote: > On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote: > > How exactly did you reach the situation where the root port didn't wake > > up when you tried to load nouveau again? (IRC conversation this week.) > > Ensure that the

[PATCH] drm: hdlcd: Replace the mode config's atomic_commit with the proper implementation.

On Tue, May 31, 2016 at 12:03:04PM +0100, Liviu Dudau wrote: > The HDLCD atomic_commit code was mis-using the drm_atomic_helper_commit() > function to implement the non-blocking code. Replace that with the correct > implementation that does the async queue-ing of commits. > > Signed-off-by: Liviu

[PATCH v6 2/2] vga_switcheroo: Support deferred probing of audio clients

On Tue, May 31, 2016 at 11:13:27AM +0200, Lukas Wunner wrote: > Daniel Vetter pointed out that vga_switcheroo_client_probe_defer() could > be needed by audio clients as well. To avoid mistakes when someone adds > conditions for these in the future, constrain the single existing > condition to VGA

did the drm patch to support Iris(TM) Graphics P555 fell through the cracks? (Was: Re: [Intel-gfx] RFC: libdrm: Support Iris Graphics 540 & 550 (Skylake GT3e))

CCing danvet Thorsten Leemhuis wrote on 28.04.2016 10:37: > Kenneth Graunke wrote on 28.04.2016 03:05: >> On Wednesday, April 27, 2016 9:37:07 AM PDT Thorsten Leemhuis wrote: >>> Thorsten Leemhuis wrote on 26.04.2016 13:41: >>> Forget that patch -- a way better one was submitted weeks ago my

[PATCH 16/26] drm/hdlcd: Use helper support for nonblocking commits

On Tue, May 31, 2016 at 12:02:23PM +0100, Liviu Dudau wrote: > On Sun, May 29, 2016 at 08:35:13PM +0200, Daniel Vetter wrote: > > Again, just doing them as blocking commits isn't cool. > > > > From a cursory check hdlcd does seem to at least try to handle > > drm_pending_vblank_event, so

  1   2   >