[PATCH 4/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()

From: Ville Syrjälä The only caller of vmw_kms_update_implicit_fb() is the page_flip hook which itself gets called with the plane mutex already held. Hence we can look at plane->state safely. Toss in a lockdep assert to make the situation more clear. Cc: Thomas

[PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

From: Ville Syrjälä Instead of looking at plane->fb let's look at the proper new plane state. Not that the code makes a ton of sense. It's only going through the crtcs in the atomic state, so assuming not all of them are included we're not even calculating the

[PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

From: Ville Syrjälä Instead of plane->fb (which we're going to deprecate for atomic drivers) we need to look at plane->state->fb. The maze of code leading to vmw_kms_helper_dirty() wasn't particularly clear, but my analysis concluded that the calls originating from

[PATCH 1/7] drm/arc: Stop consulting plane->fb

From: Ville Syrjälä We want to stop using plane->fb with atomic driver, so stop looking at it. I have no idea what this code is trying to achieve. There is no corresponding check in the enable path. Also since arc_pgu_set_pxl_fmt() will anyway oops if there is no

[Bug 100105] Make Theano OpenCL support work on Clover and RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=100105 --- Comment #4 from Jan Vesely --- Lowering CL requirements combined with the following pull requests: https://github.com/Theano/libgpuarray/pull/571 https://github.com/Theano/libgpuarray/pull/570 Results in: Ran 4970

[Bug 105910] Graphical artifacts on unresponsible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 Ivan Chebykin changed: What|Removed |Added Summary|Graphical artifacts on |Graphical artifacts

[Bug 105912] [IGT] gem_exec_reloc@cpu-30 iwlwifi 0000:00:14.3: Scan failed! ret -110 dmesg-warn

https://bugs.freedesktop.org/show_bug.cgi?id=105912 Bug ID: 105912 Summary: [IGT] gem_exec_reloc@cpu-30 iwlwifi :00:14.3: Scan failed! ret -110 dmesg-warn Product: DRI Version: DRI git Hardware: x86-64 (AMD64)

[Bug 105910] Graphical artifacts on unresposible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 --- Comment #5 from Ivan Chebykin --- Created attachment 138632 --> https://bugs.freedesktop.org/attachment.cgi?id=138632=edit Xorg log -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Hi Rob, On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote: > On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote: > > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote: > >> On 03/27/2018 01:10 PM, jacopo mondi wrote: > >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300,

[Bug 105910] Graphical artifacts on unresposible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 --- Comment #4 from Ivan Chebykin --- Created attachment 138631 --> https://bugs.freedesktop.org/attachment.cgi?id=138631=edit glxinfo -- You are receiving this mail because: You are the assignee for the

[Bug 105910] Graphical artifacts on unresposible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 --- Comment #3 from Ivan Chebykin --- Created attachment 138630 --> https://bugs.freedesktop.org/attachment.cgi?id=138630=edit dmesg full log -- You are receiving this mail because: You are the assignee for the

[Bug 105910] Graphical artifacts on unresposible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 --- Comment #2 from Ivan Chebykin --- Created attachment 138629 --> https://bugs.freedesktop.org/attachment.cgi?id=138629=edit Xeyes render artifacts instead of background -- You are receiving this mail because: You are

[Bug 105910] Graphical artifacts on unresposible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 --- Comment #1 from Ivan Chebykin --- Created attachment 138628 --> https://bugs.freedesktop.org/attachment.cgi?id=138628=edit Artifacts when window is opening -- You are receiving this mail because: You are the assignee

[Bug 105910] Graphical artifacts on unresposible surfaces on AMD Radeon RX 570

https://bugs.freedesktop.org/show_bug.cgi?id=105910 Bug ID: 105910 Summary: Graphical artifacts on unresposible surfaces on AMD Radeon RX 570 Product: Mesa Version: 17.3 Hardware: x86-64 (AMD64) OS: Linux

RE: [RFC 0/3] drm: page-flip with damage

> > On Wed, Apr 04, 2018 at 04:49:05PM -0700, Deepak Rawat wrote: > > Hi All, > > > > This is extension to Lukasz Spintzyk earlier draft of damage interface for > drm. > > Bascially a new plane property is added called "DAMAGE_CLIPS" which is > simply > > an array of drm_rect (exported to

Re: [PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

Hi Mauro, Thank you for the patch. On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote: > Add stubs for omapfb_dss.h, in the case it is included by > some driver when CONFIG_FB_OMAP2 is not defined. The omapfb driver doesn't include any asm/ header, so it should probably build

Re: [PATCH 04/13] drm/amdgpu/dc: Stop updating plane->fb

On 2018-04-05 12:41 PM, Daniel Vetter wrote: > On Thu, Apr 05, 2018 at 06:13:51PM +0300, Ville Syrjala wrote: >> From: Ville Syrjälä >> >> We want to get rid of plane->fb on atomic drivers. Stop setting it. >> >> Cc: Alex Deucher >> Cc:

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote: > With damage property in drm_plane_state, this patch adds helper iterator > to traverse the damage clips. Iterator will return the damage rectangles > in framebuffer, plane or crtc coordinates as need by driver > implementation. > >

Re: [Intel-gfx] [PATCH] drm/i915/dp: Send DPCD ON for MST before phy_up

On Thu, 2018-04-05 at 19:38 +0300, Ville Syrjälä wrote: > On Wed, Apr 04, 2018 at 07:27:21PM -0400, Lyude Paul wrote: > > As it turns out, the aux block being off was not the real problem here, > > as transition from D3 to D0 is mandated by the DP spec to take a maximum > > of 1ms, whereas

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

https://bugs.freedesktop.org/show_bug.cgi?id=104412 --- Comment #15 from S.H. --- (In reply to Harry Wentland from comment #13) > The problem with 4k60 being blocked due to a BIOS bit should be fixed now. I > recommend trying the drm-next-4.17-wip from >

Re: [PATCH 1/9] drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacks

On 04/05/2018 05:44 PM, Daniel Vetter wrote: Less hits to go through when I git grep over all drivers. These callbacks are optional. Signed-off-by: Daniel Vetter Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas

[PATCH v2 05/13] drm/i915: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. v2: Fix up the comment in intel_crtc_active() and nuke the rest of the stale comments (Daniel) Cc: Daniel Vetter Signed-off-by: Ville

Re: [PATCH 13/13] drm: Add local 'plane' variable for tmp->primary

On Thu, Apr 05, 2018 at 06:14:00PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Clean up the ugly tmp->primary-> stuff in > __drm_mode_set_config_internal() with a local plane variable. > > Cc: Daniel Vetter > Suggested-by: Daniel

Re: [Intel-gfx] [PATCH 12/13] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

On Thu, Apr 05, 2018 at 06:13:59PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Stop playing around with plane->crtc/fb/old_fb with atomic > drivers. Make life a lot simpler when we don't have to do the > magic old_fb vs. fb dance around plane updates.

Re: [Intel-gfx] [PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

On Thu, Apr 05, 2018 at 06:13:58PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > omap_framebuffer_get_next_connector() uses plane->fb which we want to > deprecate for atomic drivers. As omap_framebuffer_get_next_connector() > is unused just nuke the entire

Re: [Intel-gfx] [PATCH 09/13] drm/vc4: Stop updating plane->fb/crtc

On Thu, Apr 05, 2018 at 06:13:56PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > Cc: Eric Anholt > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 08/13] drm/virtio: Stop updating plane->crtc

On Thu, Apr 05, 2018 at 06:13:55PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->crtc on atomic drivers. Stop setting it. > > v2: s/fb/crtc/ in the commit message (Gerd) > > Cc: David Airlie > Cc: Gerd

Re: [PATCH 06/13] drm/exynos: Stop updating plane->crtc

On Thu, Apr 05, 2018 at 06:13:53PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->crtc on atomic drivers. Stop setting it. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo

Re: [PATCH 05/13] drm/i915: Stop updating plane->fb/crtc

On Thu, Apr 05, 2018 at 06:13:52PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > Signed-off-by: Ville Syrjälä > Reviewed-by: Maarten Lankhorst

Re: [PATCH 04/13] drm/amdgpu/dc: Stop updating plane->fb

On Thu, Apr 05, 2018 at 06:13:51PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb on atomic drivers. Stop setting it. > > Cc: Alex Deucher > Cc: "Christian König" > Cc:

Re: [PATCH] drm/i915/dp: Send DPCD ON for MST before phy_up

On Wed, Apr 04, 2018 at 07:27:21PM -0400, Lyude Paul wrote: > As it turns out, the aux block being off was not the real problem here, > as transition from D3 to D0 is mandated by the DP spec to take a maximum > of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs. > The real

Re: [PATCH 10/13] drm/atmel-hlcdc: Stop using plane->fb

On Thu, Apr 05, 2018 at 06:13:57PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb on atomic drivers. Stop looking at it. > > Daniel pointed out that the drm_framebuffer_put() in the plane cleanup > indicates that the driver

Re: [PATCH 03/13] drm/atmel-hlcdc: Stop consulting plane->crtc

On Thu, Apr 05, 2018 at 06:13:50PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->crtc on atomic drivers. Stop looking at it. > > Cc: Boris Brezillon > Signed-off-by: Ville Syrjälä

Re: [PATCH 02/13] drm/sti: Stop consulting plane->crtc

On Thu, Apr 05, 2018 at 06:13:49PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->crtc on atomic drivers. Stop looking at it. > > Cc: Benjamin Gaignard > Cc: Vincent Abriou

Re: [PATCH 01/13] drm/msm: Stop consulting plane->fb/crtc

On Thu, Apr 05, 2018 at 06:13:48PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop > looking at them. > > v2: Catch the plane->crtc case too > > Cc: Rob Clark > Cc:

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote: > Hi Vladimir, > > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote: >> On 03/27/2018 01:10 PM, jacopo mondi wrote: >> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:

Re: [PATCH 07/13] drm/msm: Stop updating plane->fb/crtc

On Thu, Apr 05, 2018 at 06:13:54PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > v2: Catch a few more cases > > Cc: Rob Clark > Cc:

Re: drm: Branch 'master'

On 2018-03-30 04:51 AM, Chunming Zhou wrote: > include/drm/amdgpu_drm.h |4 > 1 file changed, 4 insertions(+) > > New commits: > commit 2fa58c77fb9e563219f8ec647b9ddf52f3390ed2 > Author: Rex Zhu > Date: Tue Mar 20 14:08:09 2018 +0800 > > headers: sync up

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 --- Comment #4 from Lyberta --- Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform Version

Re: DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

Just realized Joonas had some other comments down at the bottom that I missed originally... On Thu, Apr 05, 2018 at 08:06:23AM -0700, Matt Roper wrote: > On Thu, Apr 05, 2018 at 07:49:44AM -0700, Matt Roper wrote: > > On Thu, Apr 05, 2018 at 05:15:13PM +0300, Joonas Lahtinen wrote: > > > + Some

[PATCH 9/9] drm/msm: Always obey implicit fencing

Again same justification as for drm_gem_fb_prepare_fb(). Definitely needs some testing because Rob doesn't remember why he did this, and Google/git.fd.o or anything also doesn't shed some light on it. Signed-off-by: Daniel Vetter Cc: Rob Clark Cc:

[PATCH 8/9] drm/vc4: Always obey implicit sync

Same justification as for drm_gem_fb_prepare_fb. Cc: Eric Anholt Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vc4/vc4_plane.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c

[PATCH 7/9] drm/gem-fb-helper: Always do implicit sync

I've done a lot of history digging. The first signs of this optimization was introduced in i915: commit 25067bfc060d1a481584dcb51ef4b5680176ecb6 Author: Gustavo Padovan Date: Wed Sep 10 12:03:17 2014 -0300 drm/i915: pin sprite fb only if it changed

[PATCH 5/9] drm/mxsfb: Use simple_display_pipe prepare_fb helper

Signed-off-by: Daniel Vetter Cc: Marek Vasut --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index

[PATCH 2/9] drm: Move simple_display_pipe prepare_fb helper into gem fb helpers

There's nothing tinydrm specific to this, and there's a few more copies of the same in various other drivers. Signed-off-by: Daniel Vetter Cc: Gustavo Padovan Cc: Maarten Lankhorst Cc: Sean Paul

[PATCH 1/9] drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacks

Less hits to go through when I git grep over all drivers. These callbacks are optional. Signed-off-by: Daniel Vetter Cc: VMware Graphics Cc: Sinclair Yeh Cc: Thomas Hellstrom ---

[PATCH 4/9] drm/pl111: Use simple_display_pipe prepare_fb helper

Signed-off-by: Daniel Vetter Cc: Eric Anholt --- drivers/gpu/drm/pl111/pl111_display.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c index

[PATCH 6/9] drm/atomic: better doc for implicit vs explicit fencing

Note that a pile of drivers don't seem to take implicit fencing into account, or at least don't call drm_atoimc_set_fence_for_plane(). Cc'ing relevant people, or at least some. Some drivers also look like they don't disable implicit fencing (e.g. amdgpu) because the explicit fences and implicit

[PATCH 3/9] drm/tve200: Use simple_display_pipe prepare_fb helper

Signed-off-by: Daniel Vetter Cc: Linus Walleij --- drivers/gpu/drm/tve200/tve200_display.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tve200/tve200_display.c

[PATCH 0/9] implicit fencing clarification

Hi all, Somewhat motivated (but only really tangentially) by the dirtyfb discussion with Rob and Thomas I started digging around in the various driver implementations for implicit vs. explicit fencing. There's definitely a huge pile of drivers which don't do any implicit fencing at all - not

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

On 03/29/2018 09:39 AM, Daniel Vetter wrote: > On Thu, Mar 29, 2018 at 9:35 AM, Philippe CORNU wrote: >> Hi Daniel, >> >> On 03/27/2018 05:51 PM, Daniel Vetter wrote: >>> On Mon, Feb 26, 2018 at 01:16:04PM +0100, Philippe Cornu wrote: This patch clarifies the

[PATCH 13/13] drm: Add local 'plane' variable for tmp->primary

From: Ville Syrjälä Clean up the ugly tmp->primary-> stuff in __drm_mode_set_config_internal() with a local plane variable. Cc: Daniel Vetter Suggested-by: Daniel Vetter Signed-off-by: Ville Syrjälä

[PATCH 11/13] drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

From: Ville Syrjälä omap_framebuffer_get_next_connector() uses plane->fb which we want to deprecate for atomic drivers. As omap_framebuffer_get_next_connector() is unused just nuke the entire function. Cc: Tomi Valkeinen Signed-off-by:

[PATCH 12/13] drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

From: Ville Syrjälä Stop playing around with plane->crtc/fb/old_fb with atomic drivers. Make life a lot simpler when we don't have to do the magic old_fb vs. fb dance around plane updates. That way we can't risk plane->fb getting out of sync with plane->state->fb

[PATCH 10/13] drm/atmel-hlcdc: Stop using plane->fb

From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop looking at it. Daniel pointed out that the drm_framebuffer_put() in the plane cleanup indicates that the driver doesn't shut things down cleanly. To do that we should be able to just call

[PATCH 09/13] drm/vc4: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. Cc: Eric Anholt Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst ---

[PATCH 05/13] drm/i915: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c

[PATCH 08/13] drm/virtio: Stop updating plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop setting it. v2: s/fb/crtc/ in the commit message (Gerd) Cc: David Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org

[PATCH 06/13] drm/exynos: Stop updating plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop setting it. Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park

[PATCH 07/13] drm/msm: Stop updating plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop setting them. v2: Catch a few more cases Cc: Rob Clark Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Ville Syrjälä

[PATCH 04/13] drm/amdgpu/dc: Stop updating plane->fb

From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: Harry Wentland

[PATCH 02/13] drm/sti: Stop consulting plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop looking at it. Cc: Benjamin Gaignard Cc: Vincent Abriou Cc: Daniel Vetter Signed-off-by: Ville Syrjälä

[PATCH 03/13] drm/atmel-hlcdc: Stop consulting plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop looking at it. Cc: Boris Brezillon Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c

[PATCH 01/13] drm/msm: Stop consulting plane->fb/crtc

From: Ville Syrjälä We want to get rid of plane->fb/crtc on atomic drivers. Stop looking at them. v2: Catch the plane->crtc case too Cc: Rob Clark Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Ville

Re: DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

On Thu, Apr 05, 2018 at 07:49:44AM -0700, Matt Roper wrote: > On Thu, Apr 05, 2018 at 05:15:13PM +0300, Joonas Lahtinen wrote: > > + Some more Cc's based on IRC discussion > > > > Quoting Joonas Lahtinen (2018-04-05 16:46:51) > > > + Dave for commenting from DRM subsystem perspective. I strongly

[pull] radeon and amdgpu drm-next-4.17

Hi Dave, A few fixes for 4.17: - Fix a potential use after free in a error case - Fix pcie lane handling in amdgpu SI dpm - sdma pipeline sync fix - A few vega12 cleanups and fixes - Misc other fixes The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79: Merge branch

Re: DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

On Thu, Apr 05, 2018 at 05:15:13PM +0300, Joonas Lahtinen wrote: > + Some more Cc's based on IRC discussion > > Quoting Joonas Lahtinen (2018-04-05 16:46:51) > > + Dave for commenting from DRM subsystem perspective. I strongly believe > > there would be benefit from agreeing on some foundation of

Re: DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

+ Some more Cc's based on IRC discussion Quoting Joonas Lahtinen (2018-04-05 16:46:51) > + Dave for commenting from DRM subsystem perspective. I strongly believe > there would be benefit from agreeing on some foundation of DRM subsystem > level program GPU niceness [-20,19] and memory limit [0,N]

Re: [PATCH] drm/sched: Extend the documentation.

On Thu, Apr 5, 2018 at 3:44 PM, Alex Deucher wrote: > On Thu, Apr 5, 2018 at 9:41 AM, Nayan Deshmukh > wrote: >> On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: >>> On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On 04/05/2018 03:47 PM, Daniel Vetter wrote: On Thu, Apr 05, 2018 at 01:35:25PM +0200, Thomas Hellstrom wrote: On 04/05/2018 12:03 PM, Daniel Vetter wrote: On Thu, Apr 05, 2018 at 11:00:15AM +0200, Thomas Hellstrom wrote: On 04/05/2018 09:35 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On Thu, Apr 05, 2018 at 10:51:42AM +0200, Thomas Hellstrom wrote: > On 04/05/2018 09:52 AM, Daniel Vetter wrote: > > > > TYPE_PLANE I have no idea who needs that. I suggest we just drop it. > > I'm assuming CRTC plane coordinates here. They are used for uploading > contents of hardware planes.

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On Thu, Apr 05, 2018 at 01:51:49PM +0200, Thomas Hellstrom wrote: > On 04/05/2018 12:10 PM, Daniel Vetter wrote: > > On Thu, Apr 05, 2018 at 10:49:09AM +0200, Thomas Hellstrom wrote: > > > On 04/05/2018 09:52 AM, Daniel Vetter wrote: > > > > On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat

Re: [PATCH v3 36/40] drm/i915: Implement gmbus burst read

On Thursday 05 April 2018 02:42 PM, Jani Nikula wrote: On Tue, 03 Apr 2018, Daniel Vetter wrote: On Tue, Apr 03, 2018 at 07:27:49PM +0530, Ramalingam C wrote: Implements a interface for single burst read of data that is larger than 512 Bytes through gmbus. Where does 512

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On Thu, Apr 05, 2018 at 01:42:11PM +0200, Thomas Hellstrom wrote: > On 04/05/2018 12:03 PM, Daniel Vetter wrote: > > > > On the topic of input validation: Should the kernel check in shared code > > that all the clip rects are sensible, i.e. within the dimensions of the > > fb? Relying on drivers

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On Thu, Apr 05, 2018 at 01:35:25PM +0200, Thomas Hellstrom wrote: > On 04/05/2018 12:03 PM, Daniel Vetter wrote: > > On Thu, Apr 05, 2018 at 11:00:15AM +0200, Thomas Hellstrom wrote: > > > On 04/05/2018 09:35 AM, Daniel Vetter wrote: > > > > On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat

DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

+ Dave for commenting from DRM subsystem perspective. I strongly believe there would be benefit from agreeing on some foundation of DRM subsystem level program GPU niceness [-20,19] and memory limit [0,N] pages. Quoting Matt Roper (2018-03-30 03:43:13) > On Mon, Mar 26, 2018 at 10:30:23AM +0300,

Re: DRM_UDL and GPU under Xserver

On Thu, Apr 05, 2018 at 11:10:03AM +, Alexey Brodkin wrote: > Hi Daniel, Lucas, > > On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote: > > On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach wrote: > > > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter:

Re: [PATCH] drm/sched: Extend the documentation.

On Thu, Apr 5, 2018 at 9:41 AM, Nayan Deshmukh wrote: > On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: >> On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: >>> On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter

Re: [PATCH] drm/sched: Extend the documentation.

On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: > On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: >> On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: >>> On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote:

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

On Thu, Apr 5, 2018 at 3:31 PM, Hans de Goede wrote: > Hi, > > > On 05-04-18 15:26, Daniel Vetter wrote: >> >> On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: >>> >>> Hi, >>> >>> >>> On 05-04-18 09:14, Daniel Vetter wrote: On Fri, Mar

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Thu, Apr 5, 2018 at 3:30 PM, Thomas Hellstrom wrote: > On 04/04/2018 11:56 AM, Daniel Vetter wrote: >> >> On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote: >>> >>> On 04/04/2018 10:43 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 10:22:21AM

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 05-04-18 15:26, Daniel Vetter wrote: On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: Hi, On 05-04-18 09:14, Daniel Vetter wrote: On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote: Before this commit the WaSkipStolenMemoryFirstPage workaround

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On 04/04/2018 11:56 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote: On 04/04/2018 10:43 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote: Hi, On 04/04/2018 08:58 AM, Daniel Vetter wrote: On Wed, Apr 4, 2018

Re: [PATCH] drm/sched: Extend the documentation.

On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: > On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: >> On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote: >>> These comments answer all the questions I had for myself when >>>

Re: [PATCH] drm/sched: Extend the documentation.

On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: > On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote: >> These comments answer all the questions I had for myself when >> implementing a driver using the GPU scheduler. >> >> Signed-off-by: Eric Anholt

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: > Hi, > > > On 05-04-18 09:14, Daniel Vetter wrote: >> >> On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote: >>> >>> Before this commit the WaSkipStolenMemoryFirstPage workaround code was >>> skipping the first

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

https://bugs.freedesktop.org/show_bug.cgi?id=104274 --- Comment #14 from Sverd Johnsen --- I just looked at the comments again and based on Comment 2 this seems like expected behavior for now. So my update was kind of pointless. -- You are receiving this mail

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

https://bugs.freedesktop.org/show_bug.cgi?id=104274 --- Comment #13 from Sverd Johnsen --- Still seen with 4.15.15 and dc=1. Not sure if this always reproduces or not, havn't tested this in a while. [13342.285357] [drm] amdgpu: finishing device. [13342.288330]

Re: Fwd: DRM MIPI DSI device and I2C device?

On 05.04.2018 13:51, Carsten Behling wrote: > > > > 2018-04-05 13:39 GMT+02:00 Laurent Pinchart > >: > > Hi Andrzej, > > > > On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: > >> On 05.04.2018 12:28, Laurent

Re: [PATCH] drm/sti: Depend on OF rather than selecting it

On 04/05/2018 01:05 PM, Benjamin Gaignard wrote: > 2018-04-03 7:34 GMT+02:00 Oliver O'Halloran : >> Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg >> structure") reworked some code inside of this driver and made it select >> CONFIG_OF. This results in the entire

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #5 from Alex Deucher --- What physical connectors are on your board and which one(s) are you using? -- You are receiving this mail because: You are the assignee for the

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 Jan Vesely changed: What|Removed |Added Status|NEW |NEEDINFO ---

Re: [PATCH] drm/sched: Extend the documentation.

Am 05.04.2018 um 00:32 schrieb Eric Anholt: These comments answer all the questions I had for myself when implementing a driver using the GPU scheduler. Signed-off-by: Eric Anholt Reviewed-by: Christian König Already pushed to amd-staging-drm-next

[PATCH v5] drm: Fix HDCP downstream dev count read

In both HDMI and DP, device count is represented by 6:0 bits of a register(BInfo/Bstatus) So macro for bitmasking the device_count is fixed(0x3F->0x7F). v3: Retained the Rb-ed. v4: %s/drm\/i915/drm [rodrigo] v5: Added "Fixes:" and HDCP keyword in subject [Rodrigo, Sean Paul]

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #4 from Chí-Thanh Christopher Nguyễn --- Created attachment 138620 --> https://bugs.freedesktop.org/attachment.cgi?id=138620=edit dmest with cik_support=1 dc=1 dc_log=1 doesn't look all that different from

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On 04/05/2018 12:10 PM, Daniel Vetter wrote: On Thu, Apr 05, 2018 at 10:49:09AM +0200, Thomas Hellstrom wrote: On 04/05/2018 09:52 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote: With damage property in drm_plane_state, this patch adds helper iterator to

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 05-04-18 09:14, Daniel Vetter wrote: On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote: Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On 04/05/2018 12:03 PM, Daniel Vetter wrote: On the topic of input validation: Should the kernel check in shared code that all the clip rects are sensible, i.e. within the dimensions of the fb? Relying on drivers for that seems like a bad idea. I guess we could do that. There seems to be

Re: Fwd: DRM MIPI DSI device and I2C device?

Hi Andrzej, On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: > On 05.04.2018 12:28, Laurent Pinchart wrote: > > On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: > >>> Hi, > >>> > >>> I would like to write a DRM bridge driver that is an I2C device and a > >>> DRM MIPI

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 04-04-18 22:49, Ville Syrjälä wrote: On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans de Goede wrote: Hi, On 04-04-18 17:50, Ville Syrjälä wrote: On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote: Hi, On 30-03-18 15:25, Hans de Goede wrote: Hi, On 30-03-18 14:44, Chris

<    1   2   3   >