Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On 03/22/2017 10:50 PM, Daniel Vetter wrote: > It's been around forever, no one bothered to address the FIXME, so I > presume it's all fine. > > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Signed-off-by: Daniel Vetter NAK. We need to properly address this. Probably as part of the atomic update. /

Re: [lkp-robot] [drm] f04f7e3e04: general_protection_fault:#[##]

kernel test robot writes: > FYI, we noticed the following commit: > > commit: f04f7e3e041aab12abbf3ed7b854446af5a624a9 ("drm: bochs: Don't > remove uninitialized fbdev framebuffer") > url: > https://github.com/0day-ci/linux/commits/Gabriel-Krisman-Bertazi/drm-bochs-Don-t-remove-uninitialized-fbde

[pull] radeon and amdgpu drm-fixes-4.11

Hi Dave, A few small fixes for 4.11 The following changes since commit 27b713c2e08ef27d500a79166098d42b24977500: Merge branch 'drm-fixes-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-03-16 11:28:44 +1000) are available in the git repository at: git://people.freed

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||99856 Referenced Bugs: https://bugs.freed

Re: [PATCH v2] drm: Refactor vblank sequence number comparison

On 22/03/17 07:06 PM, Chris Wilson wrote: > Move the repeated (a - b) <= (1 << 23) to its own function. > > v2: Catch the '1<<23' inside drm_handle_vblank() as well > > Signed-off-by: Chris Wilson Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray wrote: > On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote: >> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote: >> > I guess I'm a little late to the party here, but I haven't had time to >> > really let all of this sink in and actuall

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote: > On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote: > > I guess I'm a little late to the party here, but I haven't had time to > > really let all of this sink in and actually look at meson. It doesn't > > seem so bad with a quick lo

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=96897 --- Comment #7 from Andy Furniss --- (In reply to Andy Furniss from comment #6) > Same for me on tonga + git llvm/libclc/mesa/clpeak > > Platform: Clover > Device: AMD TONGA (DRM 3.13.0 / 4.11.0-rc1-g00c1259, LLVM 5.0.0) > Driver version

Re: [PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane

On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index 34cb73d0db77..b54fd8cbd3a6 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++ b/drivers/gpu/drm/armada/armada_overlay.

[PATCH v5 4/8] drm: Add driver-private objects to atomic state

From: "Pandiyan, Dhinakaran" It is necessary to track states for objects other than connector, crtc and plane for atomic modesets. But adding objects like DP MST link bandwidth to drm_atomic_state would mean that a non-core object will be modified by the core helper functions for swapping and cle

Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

Hi Philipp I moved house again on Sunday - that is the second time in two months. I won't bore you with the details but it means I've not had much time to myself recently and why I've not been able to test this patch. As I was saying previously, the only way I can reliably test this is to do it '

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=96897 --- Comment #6 from Andy Furniss --- Same for me on tonga + git llvm/libclc/mesa/clpeak Platform: Clover Device: AMD TONGA (DRM 3.13.0 / 4.11.0-rc1-g00c1259, LLVM 5.0.0) Driver version : 17.1.0-devel (Linux x64) Compute units : 28

[Bug 100067] [OpenCL] const int in argument list crashes build

https://bugs.freedesktop.org/show_bug.cgi?id=100067 --- Comment #5 from Mig --- minimal.cpp compiled with gcc -c minimal.cpp -g -o minimal.o [miguel@antergos-mig extra]$ gdb GNU gdb (GDB) 7.12.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Quoting Eric Anholt (2017-03-22 15:15:46) > Rob Clark writes: > > > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker wrote: > >> Here's a not so complete list: > >> https://github.com/mesonbuild/meson/wiki/Users > >> > >> Notably gnome is moving to meson (and some parts already use it), weston > >

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Alex Deucher writes: > On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote: >> Why bother, and why would we want this? >> │~ >> >> First it's written in python, which means the potential developer base >> is massive. And it provides a

[PATCH v3 0/5] DRM OF graph clean-up

I've been unhappy with the OF graph API for some time and decided to do something about it. The problem is drivers have to do too much of the graph parsing and walking themselves. This has led to the same pattern duplicated over and over. This series adapts DRM drivers to use a new OF graph helper

Re: [PATCH v4 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

Hi Neil, On 21-03-2017 15:12, Neil Armstrong wrote: > In order to describe the RGB and YUV bus formats used to feed the > Synopsys DesignWare HDMI TX Controller, add missing formats to the > list of Bus Formats. > > Documentation for these formats is added in a separate patch. > > Reviewed-by: Ar

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 17/03/17 02:28, Brian Paul wrote: On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand mailto:ja...@jlekstrand.net>> wrote: On March 16, 2017 5:41:24 PM Emil Velikov mailto:emil.l.veli...@gmail.com>> wrote: On 17 March 2017 at 00:21, Dylan Baker mailto:dy...@pnwbakers.com>> wrote:

Re: [PATCH v3 1/5] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

Rob Herring writes: > For drm_of_find_panel_or_bridge() added in the next commit, an empty > version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL. > > Signed-off-by: Rob Herring Makes sense. Reviewed-by: Eric Anholt signature.asc Description: PGP signature __

[PATCH v3 2/5] drm: of: introduce drm_of_find_panel_or_bridge

Many drivers have a common pattern of searching the OF graph for either an attached panel or bridge and then finding the DRM struct for the panel or bridge. Also, most drivers need to handle deferred probing when the DRM device is not yet instantiated. Create a common function, drm_of_find_panel_or

[RFC 0/5] HDMI 2.0+ video modes handling in DRM core

Hi all, This is a RFC series that aims to collect comments regarding the handling of HDMI 2.0+ video modes and features in the DRM core. Some of the HDMI 2.0 features are already implemented and only affect kernel drivers (SDCD for example). There are some features, though, which can, and will, a

[RFC 4/5] drm: connector: Add hdmi2_allowed flag

Add a new HDMI 2.0+ flag which will signal core that the connector can handle HDMI 2.0+ video modes. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: dri-devel@lists.freedesktop.org --- include/drm/drm_connector.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_connector.

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

++ Daniel ++ Ville ++ Shashank On 22-03-2017 17:35, Jose Abreu wrote: > Hi all, > > This is a RFC series that aims to collect comments regarding the handling > of HDMI 2.0+ video modes and features in the DRM core. > > Some of the HDMI 2.0 features are already implemented and only affect kernel

[RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

We can't expect userspace to have full support for all HDMI 2.0+ features. Instead of expecting/waiting for userspace to support the new features add a knob, much like the stereo knob, so that DRM core will only expose the features when asked too. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc

Re: [Intel-gfx] [PATCH v4 4/8] drm: Add driver-private objects to atomic state

On Wed, 2017-03-22 at 11:00 +0100, Maarten Lankhorst wrote: > Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan: > > From: "Pandiyan, Dhinakaran" > > > > It is necessary to track states for objects other than connector, crtc > > and plane for atomic modesets. But adding objects like DP MST link > >

Re: [Intel-gfx] [PATCH v4 8/8] drm/dp: Track MST link bandwidth

On Wed, 2017-03-22 at 13:30 +0100, Maarten Lankhorst wrote: > Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan: > > From: "Pandiyan, Dhinakaran" > > > > Use the added helpers to track MST link bandwidth for atomic modesets. > > Link bw is acquired in the ->atomic_check() phase when CRTCs are being

[RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new flag which will signal userspace that this is a HDMI 2.0+ mode. It is expected that these new flags will not be exported to userspace unless client asks to. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: dri-devel@lists.freedes

[PATCH v3 3/5] drm: convert drivers to use of_graph_get_remote_node

Convert drivers to use the new of_graph_get_remote_node() helper instead of parsing the endpoint node and then getting the remote device node. Now drivers can just specify the device node and which port/endpoint and get back the connected remote device node. The details of the graph binding are nic

Re: [PATCH v7] drm/rockchip: Refactor the component match logic.

Hi Sean, On 03/22/2017 03:55 AM, Sean Paul wrote: On Tue, Mar 21, 2017 at 02:42:11PM +0800, Jeffy Chen wrote: Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm.

[PATCH v8] drm/rockchip: Refactor the component match logic.

Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by: Jeffy Chen Reviewed-by: Andrzej Hajda Acked-by: Mark Yao Tested-by: Heiko Stuebner --- Chang

Re: [PATCH v4 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

Hi Neil, On 21-03-2017 15:12, Neil Armstrong wrote: > Some display pipelines can only provide non-RBG input pixels to the HDMI TX > Controller, this patch takes the pixel format from the plat_data if provided. > > Signed-off-by: Neil Armstrong Looks fine, I'm assuming you test this on your plat

[RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

This patch completes CEA table of video modes so that VIC 1-107 are now available. Use the HDMI 2.0+ flag to signal these are modes for HDMI 2.0 onwards. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 258 ++

Re: [PATCH v3 2/5] drm: of: introduce drm_of_find_panel_or_bridge

On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote: > Many drivers have a common pattern of searching the OF graph for either an > attached panel or bridge and then finding the DRM struct for the panel > or bridge. Also, most drivers need to handle deferred probing when the > DRM device is not ye

[PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

Similar to the previous commit, convert drivers open coding OF graph parsing to use drm_of_find_panel_or_bridge instead. This changes some error messages to debug messages (in the graph core). Graph connections are often "no connects" depending on the particular board, so we want to avoid spurious

Re: [PATCH v4 1/6] drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

Hi Neil, On 21-03-2017 15:12, Neil Armstrong wrote: > From: Laurent Pinchart > > In preparation for adding PHY operations to handle RX SENSE and HPD, > group all the PHY interrupt setup code in a single location and extract > it to a separate function. > > Signed-off-by: Laurent Pinchart > Sign

[PATCH v3 1/5] drm: make of_drm_find_panel also depend on CONFIG_DRM_PANEL

For drm_of_find_panel_or_bridge() added in the next commit, an empty version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL. Signed-off-by: Rob Herring --- v3: - rebase to v4.11-rc2 include/drm/drm_panel.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm

[PATCH v3 5/5] drm: omap: use common OF graph helpers

The OMAP driver has its own OF graph helpers that are similar to the common helpers. This commit replaces most of the calls with the common helpers. There's still a couple of custom helpers left, but the driver needs more extensive changes to get rid of them. In dss_init_ports, we invert the loop,

[BUG][REGRESSION] i915 gpu hangs under load

Hi I know something similar is here: https://bugs.freedesktop.org/show_bug.cgi?id=100110 too. But this is rc3 and my machine is totally *not usable*. Let me be annoying :) I hope I can help: Since rc1 I get gpu hangs and resets under load: This is almost certainly a kernel issue. 4.10 is f

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

On Wed, 2017-03-22 at 08:26 -0500, Rob Herring wrote: > Similar to the previous commit, convert drivers open coding OF graph > parsing to use drm_of_find_panel_or_bridge instead. > > This changes some error messages to debug messages (in the graph core). > Graph connections are often "no connects"

[RFC 5/5] drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked to

Perform sanity checks so that HDMI 2.0+ modes are not exported to drivers or userspace unless asked to. Signed-off-by: Jose Abreu Cc: Carlos Palminha Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_connector.c| 2 ++ drivers/gpu/drm/drm_probe_helper.c | 9 - include/dr

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 16/03/17 22:36, Marek Olšák wrote: Is there a way not to use ninja with meson, because ninja redirects all stderr output from gcc to stdout, which breaks many development environments that expect errors in stderr? I'm basically saying that if ninja can't keep gcc errors in stderr, I wouldn't

Re: [PATCH] drm/msm/hdmi: redefinitions of macros not required

hi, Could you please give some feedback or review comments for this patch On 3/14/17, Vinay Simha BN wrote: > 4 macros already defined in hdmi.h, > which is not required to redefine in hdmi_audio.c > > Signed-off-by: Vinay Simha BN > --- > drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 7 --- > 1

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Rob Clark writes: > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker wrote: >> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users >> >> Notably gnome is moving to meson (and some parts already use it), weston and >> libinput have ports, libepoxy uses meson, and gstreamer i

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=96897 --- Comment #5 from Jan Ziak <0xe2.0x9a.0...@gmail.com> --- With LLVM 4.0.0 I am getting the following results: $ clinfo Platform ID: 0x7ff6aaf2ed60 Name: AMD HAWAII (DRM 3.10.0 / 4.11.0-rc2+, LLVM 4.0

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker wrote: > Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users > > Notably gnome is moving to meson (and some parts already use it), weston and > libinput have ports, libepoxy uses meson, and gstreamer is using meson. I > can't s

[PATCH 17/19] drm: Add explicit acquire ctx handling around ->set_config

Just the groundwork to have something to feed into ->set_config. Again we need a temporary hack to still fill out the legacy ctx in mode_config.acquire_ctx. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(

[PATCH 12/19] drm/atomic-helper: remove backoff hack from page_flip

Yay, we can now properly retry in case of deadlocks or whatever! Also don't forget to remove the transitional crtc->acquire_ctx assignment again. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 40 ++--- drivers/gpu/drm/drm_plane.c

[PATCH 18/19] drm: Add acquire ctx parameter to ->set_config

Surprisingly a lot of legacy drivers roll their own, for runtime pm and because vmwgfx. Also make nouveau's set_config static while at it. Cc: Sinclair Yeh Cc: Thomas Hellstrom Cc: Ben Skeggs Cc: Patrik Jakobsson Cc: Alex Deucher Cc: Christian König Signed-off-by: Daniel Vetter --- drive

[PATCH 19/19] drm/atomic-helper: Remove the backoff hack from set_config

Another one bites the dust. Again let's not forget to remove the temporary hidden acquire_ctx assignment, now that we pass this all around explicitly it can go away again. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 21 ++--- drivers/gpu/drm/drm_crtc.c

[PATCH 14/19] drm: Remove drm_modeset_(un)lock_crtc

The last user, the cursor ioctl, can just open-code this too. We simply have to move the acquire ctx dance from the universal function up into the top-level ioctl handler. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_internal.h | 3 -- drivers/gpu/drm/drm_modeset_lock.c | 67 -

[PATCH 13/19] drm: simplify the locking in the GETCRTC ioctl

No need to grab both plane and crtc locks at the same time, we can do them one after the other. If userspace races it'll get what it deserves either way. This removes another user of drm_modeset_lock_crtc. There's only one left. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 6 ++

[PATCH 10/19] drm: Roll out acquire context for the page_flip ioctl

Again just prep work. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_plane.c | 21 +++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 8535dc17db7e..62e833ffeffd 100644 --- a/drivers/gpu/drm/dr

[PATCH 16/19] drm: Restrict drm_mode_set_config_internal to non-atomic drivers

This is another case where we really can't reconstruct a acquire ctx in any useful fashion because all the callers are legacy drivers. So like drm_plane_force_disable simply restrict it to non-atomic drivers so that it's clear we're ok with passing a NULL ctx. Signed-off-by: Daniel Vetter --- dr

[PATCH 15/19] drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctx

With all the callers of drm_modeset_lock_crtc gone, and all the places it was formerly used properly wiring the acquire ctx through, we can remove this. The only hidden context magic we still have is now the global one. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c | 14

[PATCH 11/19] drm: Add acquire ctx parameter to ->page_flip(_target)

Again just going through the motions, no functional changes in here. Cc: Gerd Hoffmann Cc: Ben Skeggs Cc: Russell King Cc: Laurent Pinchart Cc: Eric Anholt Cc: Alex Deucher Cc: Christian König Signed-off-by: Daniel Vetter t --- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++- drivers/g

[PATCH 09/19] drm: Make drm_modeset_lock_crtc internal

This is only for legacy paths that need to grab the crtc/plane lock combo. If you want to lock a crtc, just use drm_modeset_lock(). Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc_internal.h | 3 +++ drivers/gpu/drm/drm_modeset_lock.c | 14 -- include/drm/drm_modeset_lock

[PATCH 08/19] drm/tilcdc: Drop calls to modeset_lock_crtc

Again this is an internal helper, not the official way to lock a crtc. Cc: Jyri Sarha Cc: Tomi Valkeinen Signed-off-by: Daniel Vetter --- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c

[PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

It's been around forever, no one bothered to address the FIXME, so I presume it's all fine. Cc: Sinclair Yeh Cc: Thomas Hellstrom Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 25 - 1 file changed, 25 deletions(-) diff --git a/drivers/gpu/drm/v

[PATCH 07/19] drm/tegra: Don't use modeset_lock_crtc

Yes the help text is unhelpful, but atomic drivers should never use this. Just grab the lock without context or anything. Also an aside: Checking ->active like this doesn't protect against nonblocking commits, this is rather bogus. Cc: Thierry Reding Signed-off-by: Daniel Vetter --- drivers/gp

[PATCH 05/19] drm/atomic-helper: remove backoff hack from disable/update_plane

We can now properly retry at the top level, yay! v2: Also remove the temporary acquire_ctx hack again, no longer needed! Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 49 ++--- drivers/gpu/drm/drm_plane.c | 2 -- 2 files changed,

[PATCH 03/19] drm: drm_plane_force_disable is not for atomic drivers

This way I can explain why it'll be fine to pass a NULL acquire ctx here in the next patch. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_plane.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 8a4e75929810..67119

[PATCH 04/19] drm: Add acquire ctx parameter to ->plane_disable

Nouveau had a few direct calls to ->disable_plane, I replaced those with drm_plane_force_disable. Same story for shmob. Otherwise no code changes. Cc: Ben Skeggs Cc: Russell King Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- drivers/gpu/drm/armada/armada_overlay.c| 3 ++- driver

[PATCH 00/19] wire acquire ctx through legacy modeset paths

Hi all, This is something I kinda had on my todo list ever since atomic landed. The legacy_backoff() hack really doesn't work if you need to acquire additional locks, which does restrict drivers in how they handle and protect legacy paths, and kinda forces us to be overzealous with taking locks fo

[PATCH 01/19] drm: Wire up proper acquire ctx for plane functions

This is just prep work to get an acquire ctx into every place where we call ->update_plane or ->disable_plane. v2: Keep the hidden acquire_ctx pointers valid while transitioning. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_plane.c | 52 - 1 f

[PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane

Just rolling it out, no code change here. Cc: Ben Skeggs Cc: Russell King Cc: Rob Clark Cc: Laurent Pinchart Cc: Eric Anholt Signed-off-by: Daniel Vetter --- drivers/gpu/drm/armada/armada_overlay.c| 3 ++- drivers/gpu/drm/drm_atomic_helper.c| 4 +++- drivers/gpu/drm/drm_plane.c

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: > Quoting Rob Clark (2017-03-22 10:07:54) >> I guess an interesting question (from someone who doesn't know meson >> yet) would be whether meson could slurp in the Makefile.sources type >> stuff that we have, which are shared so far between >> an

[Bug 97338] Black squares in the Spec Ops: The Line chapter select screen

https://bugs.freedesktop.org/show_bug.cgi?id=97338 Samuel Pitoiset changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: [PATCH v3 06/10] drm/fb-helper: Support deferred setup

On Wed, Mar 22, 2017 at 10:06 PM, Thierry Reding wrote: > On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote: >> On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote: > [...] >> > diff --git a/drivers/gpu/drm/drm_fb_helper.c >> > b/drivers/gpu/drm/drm_fb_helper.c > [...] >> >

Re: [PATCH v3 06/10] drm/fb-helper: Support deferred setup

On Tue, Mar 21, 2017 at 11:10:22AM +0100, Daniel Vetter wrote: > On Tue, Mar 21, 2017 at 09:13:54AM +0100, Thierry Reding wrote: [...] > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > b/drivers/gpu/drm/drm_fb_helper.c [...] > > @@ -2437,11 +2476,16 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config

Re: [RFC libdrm 0/2] Replace the build system with meson

Quoting Jani Nikula (2017-03-22 01:24:19) > On Tue, 21 Mar 2017, Dylan Baker wrote: > > Quoting Jani Nikula (2017-03-21 07:44:55) > >> How does meson handle build file backwards compatibility between meson > >> versions? I don't intend to flame, but I've found for some reason many > >> python proj

Re: [PATCH] drm: Extract drm_debugfs.h

On Wed, Mar 22, 2017 at 09:53:36PM +0100, Daniel Vetter wrote: > Doc polish will follow in the next patch. > > v2: Put the include guard #endif at the end (Ville). > > Cc: Ville Syrjälä > Signed-off-by: Daniel Vetter Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_debugfs.c | 5 ++-

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Quoting Jose Fonseca (2017-03-22 10:59:10) > On 17/03/17 02:28, Brian Paul wrote: > > > > [snip] > > > > Sure, I'd like to see one build system instead of two. Meson supports > > Windows so that's good. But the big issue is our automated build > > system. Replacing SCons with Meson could be a bi

[PATCH] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is update already at the beginning of the modeset helper, which means when we disable a pipe. Hence th

[PATCH] drm: update todo.rst

Just drive-by, but we have gsoc running so better to update it now. Great news is that two entries can be removed because essentially all done. v2: Keep a bunch of the todos, Gabriel is working on them. Cc: Gabriel Krisman Bertazi Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst |

[PATCH] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places arlready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (callin drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else).

[PATCH] drm: Extract drm_ioctl.h

To match the drm_ioctl.c we already have. v2: Remove spurious space (Ville). Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_ioctl.c | 1 + include/drm/drmP.h | 61 +- include/drm/drm_ioctl.h | 102 +

[PATCH] drm/debugfs: Add kerneldoc

I've decided to not document drm_debugfs_remove_files, it's on the way out. The biggest part is a huge todo.rst entry with what all should be improved. v2: Nits from Gabriel. Cc: Gabriel Krisman Bertazi Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Daniel Vetter --- Documentation/gpu/d

[PATCH] drm: Extract drm_debugfs.h

Doc polish will follow in the next patch. v2: Put the include guard #endif at the end (Ville). Cc: Ville Syrjälä Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_debugfs.c | 5 ++- include/drm/drmP.h| 44 + include/drm/drm_debugfs.h | 77 +++

Re: [PATCH v4 8/8] drm/dp: Track MST link bandwidth

On Wed, Mar 22, 2017 at 01:30:30PM +0100, Maarten Lankhorst wrote: > Op 16-03-17 om 08:10 schreef Dhinakaran Pandiyan: > Is there any issue into attempting to release vcpi slots when they're already > released? If not, for patches 1-3 5-8 > > Reviewed-by: Maarten Lankhorst Merged patches 1-3 to

Re: [PATCH] drm/doc: Document feature merge deadlines

On Tue, Mar 21, 2017 at 03:38:26PM -0400, Sean Paul wrote: > On Tue, Mar 21, 2017 at 04:52:28PM +0100, Daniel Vetter wrote: > > The discussion pretty much concluded without objections, let's > > document what we agreed on. > > > > Cc'ing linux-doc for the new tag in Documentation/process/index.rst

[Bug 70199] clang+llvm from svn crashes when generating opencl code for 64 bit types

https://bugs.freedesktop.org/show_bug.cgi?id=70199 Jan Vesely changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #12 from Jan Vesely ---

Re: [PATCH 05/16] drm: update todo.rst

On Wed, Mar 22, 2017 at 03:31:00PM -0300, Gabriel Krisman Bertazi wrote: > Daniel Vetter writes: > > > Just drive-by, but we have gsoc running so better to update it now. > > > > Great news is that two entries can be removed because essentially all > > done. > > > > Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH 07/16] drm: Extract drm_ioctl.h

On Wed, Mar 22, 2017 at 09:15:23PM +0100, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote: > > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote: > > > To match the drm_ioctl.c we already have. > > > > > > Signed-off-by: Daniel Vetter > > > --- > >

Re: [Intel-gfx] [PATCH 07/16] drm: Extract drm_ioctl.h

On Wed, Mar 22, 2017 at 03:47:31PM +0200, Ville Syrjälä wrote: > On Wed, Mar 22, 2017 at 09:36:08AM +0100, Daniel Vetter wrote: > > To match the drm_ioctl.c we already have. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_ioctl.c | 1 + > > include/drm/drmP.h | 6

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote: > I guess I'm a little late to the party here, but I haven't had time to > really let all of this sink in and actually look at meson. It doesn't > seem so bad with a quick look and I think I could probably sort it out > when the time came, but

Re: [Intel-gfx] [PATCH 02/16] drm: Extract drm_debugfs.h

On Wed, Mar 22, 2017 at 03:34:10PM +0200, Ville Syrjälä wrote: > On Wed, Mar 22, 2017 at 09:36:03AM +0100, Daniel Vetter wrote: > > Doc polish will follow in the next patch. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_debugfs.c | 5 ++- > > include/drm/drmP.h

Re: [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)

On Wed, Mar 22, 2017 at 04:06:32PM +0100, Mario Kleiner wrote: > On 03/15/2017 10:00 PM, Ville Syrjälä wrote: > > On Wed, Mar 15, 2017 at 08:40:25PM +, Chris Wilson wrote: > >> On vblank instant-off systems, we can get into a situation where the cost > >> of enabling and disabling the vblank IR

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 omegap...@startmail.com changed: What|Removed |Added CC||omegap...@startmail.com --- Co

Re: [PATCH 04/16] drm/debugfs: Add kerneldoc

Daniel Vetter writes: > I've decided to not document drm_debugfs_remove_files, it's on the way > out. > > The biggest part is a huge todor.rst entry with what all should be > improved. todo.rst > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-uapi.rst | 9 > Documentat

Re: [PATCH 01/16] drm: drop extern from function decls

Daniel Vetter writes: > It's the default storage class for functions, entirely redundant. And > a lot of these headers are a bit inconsistent due to organically > grown. > Reviewed-by: Gabriel Krisman Bertazi -- Gabriel Krisman Bertazi ___ dri-deve

[PATCH 2/2] Android: disable pointer-arith and enum-conversion

Disable some more warnings from clang. These don't appear to be warnings worth fixing. Signed-off-by: Rob Herring --- Android.common.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Android.common.mk b/Android.common.mk index f57b8d378565..35c0f02c213c 100644 --- a/Andro

[PATCH 1/2] Android: fix building of modetest and proptest

These tests depend on tests/util/ headers, but expect the include path to be tests/. Signed-off-by: Rob Herring --- Android.mk| 2 ++ tests/util/Android.mk | 2 ++ 2 files changed, 4 insertions(+) diff --git a/Android.mk b/Android.mk index 5209059e670f..292be2360263 100644 --- a/And

RE: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

Hi Jose, I can't find the other patches of this series in dri patchwork, am I missing something ? Also, I am planning to publish a series for YUV 420 handling, where I have re-used one of your patch to parse YUV 420 block, with some modifications :-). Regards Shashank -Original Message-

[Bug 100239] Incorrect rendering in CS:GO

https://bugs.freedesktop.org/show_bug.cgi?id=100239 --- Comment #2 from Ernst Sjöstrand --- I can't reproduce this with my Fury, and have never seen it, for reference... Any tweaks like R600_DEBUG etc? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 100067] [OpenCL] const int in argument list crashes build

https://bugs.freedesktop.org/show_bug.cgi?id=100067 --- Comment #4 from Vedran Miletić --- Can you provide GDB backtraces of both minimal and mat-mul? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 100067] [OpenCL] const int in argument list crashes build

https://bugs.freedesktop.org/show_bug.cgi?id=100067 --- Comment #3 from Vedran Miletić --- Created attachment 130386 --> https://bugs.freedesktop.org/attachment.cgi?id=130386&action=edit Kernel from minimal.cpp Sorry, that was a false positive, local installation issue. I can't reproduce it on

Re: [PATCH 2/5] drm: Remove fb hsub/vsub alignment requirement

On Tue, Mar 21, 2017 at 01:26:23PM -0700, Ben Widawsky wrote: > On 17-03-21 20:12:15, Ville Syrjälä wrote: > >From: Ville Syrjälä > > > >Allow framebuffers dimesions to be misaligned w.r.t. the subsampling > >factors. No real reason the core should have to enforce this, and > >it definitely starts

Re: [PATCH 05/16] drm: update todo.rst

Daniel Vetter writes: > Just drive-by, but we have gsoc running so better to update it now. > > Great news is that two entries can be removed because essentially all > done. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 51 > -

[PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

We were experiencing an infinite loop due to VRAM bos getting added back to the VRAM lru on eviction via ttm_bo_mem_force_space, and reverting this commit solves the problem. Signed-off-by: Zachary Michaels Signed-off-by: Julien Isorce --- drivers/gpu/drm/radeon/radeon_ttm.c | 25 +-

Re: [PATCH 12/16] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

On Wed, Mar 22, 2017 at 09:36:13AM +0100, Daniel Vetter wrote: > It's overkill to have a flag parameter which is essentially used just > as a boolean. This takes care of core + adjusting drivers. > > Adjusting the scanout position callback is a bit harder, since radeon > also supplies it's own dri

  1   2   3   >