Re: [RFC PATCH] drm/atomic: add ASYNC_UPDATE flag to the Atomic IOCTL.

2018-06-28 Thread Maarten Lankhorst
Op 27-06-18 om 23:25 schreef Enric Balletbo i Serra: > From: Gustavo Padovan > > This flag tells core to jump ahead the queued update if the conditions > in drm_atomic_async_check() are met. That means we are only able to do an > async update if no modeset is pending and update for the same plane

Re: [PATCH v8 3/3] drm: writeback: Add client capability for exposing writeback connectors

2018-05-23 Thread Maarten Lankhorst
Op 18-05-18 om 17:17 schreef Liviu Dudau: > Due to the fact that writeback connectors behave in a special way > in DRM (they always report being disconnected) we might confuse some > userspace. Add a client capability for writeback connectors that will > filter them out for clients that don't

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

2018-05-22 Thread Maarten Lankhorst
Op 20-05-18 om 19:17 schreef Randy Li: > This pixel format is a fully packed and 10bits variant of NV12. > A luma pixel would take 10bits in memory, without any > filled bits between pixels in a stride. The color gamut > follows the BT.2020 standard. > > Signed-off-by: Randy Li

Re: [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

2018-05-22 Thread Maarten Lankhorst
Op 20-05-18 om 19:17 schreef Randy Li: > This pixel format is a fully packed and 10bits variant of NV12. > A luma pixel would take 10bits in memory, without any > filled bits between pixels in a stride. The color gamut > follows the BT.2020 standard. > > Signed-off-by: Randy Li

Re: [RFC PATCH] drm: Add per-plane pixel blend mode property

2018-05-17 Thread Maarten Lankhorst
Op 08-05-18 om 12:34 schreef Lowry Li: > Pixel blend modes represent the alpha blending equation > selection, describing how the pixels from the current > plane are composited with the background. > > Add a pixel_blend_mode to drm_plane_state and a > blend_mode_property to drm_plane, and related

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

2018-04-19 Thread Maarten Lankhorst
Op 19-04-18 om 13:05 schreef Fengguang Wu: > Hi Maarten, > >> What extra dmesg output do you get when you boot with drm.debug=0x1f ? > > Attached is the dmesg with drm.debug=0x1f. > > Thanks, > Fengguang Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768: kern :debug : [

Re: [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060

2018-04-19 Thread Maarten Lankhorst
Hey, Op 19-04-18 om 04:52 schreef Fengguang Wu: > Hello, > > FYI this happens in mainline kernel and at least dates back to v4.13 . > > [ 75.245840] > [ 75.247783] /opt/deb/gawk_1%3a4.1.4+dfsg-1_amd64.deb > [ 75.247785] > [ 75.248145] [ cut here ] > [ 75.248446]

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

2018-04-04 Thread Maarten Lankhorst
Op 04-04-18 om 14:26 schreef Daniel Vetter: > On Wed, Apr 4, 2018 at 2:05 PM, Rob Clark <robdcl...@gmail.com> wrote: >> On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst >> <maarten.lankho...@linux.intel.com> wrote: >>> Op 04-04-18 om 13:37 schreef Rob Clark:

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

2018-04-04 Thread Maarten Lankhorst
Op 04-04-18 om 14:05 schreef Rob Clark: > On Wed, Apr 4, 2018 at 7:49 AM, Maarten Lankhorst > <maarten.lankho...@linux.intel.com> wrote: >> Op 04-04-18 om 13:37 schreef Rob Clark: >>> On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst >>> <maarten.lankho...@l

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

2018-04-04 Thread Maarten Lankhorst
Op 04-04-18 om 13:37 schreef Rob Clark: > On Wed, Apr 4, 2018 at 6:36 AM, Maarten Lankhorst > <maarten.lankho...@linux.intel.com> wrote: >> Op 04-04-18 om 12:21 schreef Daniel Vetter: >>> On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >>>> O

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

2018-04-04 Thread Maarten Lankhorst
Op 04-04-18 om 12:21 schreef Daniel Vetter: > On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote: >> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote: >>> Add an atomic helper to implement dirtyfb support. This is needed to >>> support DSI command-mode panels with x11

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

2018-03-15 Thread Maarten Lankhorst
Op 15-03-18 om 14:30 schreef Ville Syrjälä: > On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote: >> drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary >> arguments that can be removed by creating separate functins. >> >> Create specific functions for these calls to

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

2018-03-15 Thread Maarten Lankhorst
Op 13-03-18 om 23:02 schreef Joe Perches: > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary > arguments that can be removed by creating separate functins. > > Create specific functions for these calls to reduce x86/64 defconfig > size by ~20k. > > Modify the existing macros to

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

2018-02-21 Thread Maarten Lankhorst
Hey, Op 21-02-18 om 15:37 schreef Rob Clark: > Follow the same pattern of locking as with other state objects. This > avoids boilerplate in the driver. I'm afraid this will prohibit any uses of this on i915, since it still uses legacy lock_all(). Oh well, afaict nothing in i915 uses private

Re: [PATCH 1/4] locking/ww_mutex: add ww_mutex_is_owned_by function v3

2018-02-21 Thread Maarten Lankhorst
Op 21-02-18 om 00:56 schreef Daniel Vetter: > On Tue, Feb 20, 2018 at 04:21:58PM +0100, Peter Zijlstra wrote: >> On Tue, Feb 20, 2018 at 04:05:49PM +0100, Christian König wrote: >>> Am 20.02.2018 um 15:54 schrieb Peter Zijlstra: On Tue, Feb 20, 2018 at 03:34:07PM +0100, Christian König wrote:

Re: 995d11c4c0 ("drm: rework delayed connector cleanup in .."): WARNING: possible circular locking dependency detected

2017-12-18 Thread Maarten Lankhorst
Op 18-12-17 om 08:08 schreef Daniel Vetter: > Hm, the bisect looks funny. Only way I can explain that is that my > patch fixed a pre-existing lockdep splat, and uncovered the issue in > the ww-mutex self tests. That one is uncovered by the new > cross-release lockdep checks in 4.15. > > Anyway I

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

2017-12-14 Thread Maarten Lankhorst
Op 14-12-17 om 16:54 schreef Rafael J. Wysocki: > On Thursday, December 14, 2017 4:52:22 PM CET Thomas Gleixner wrote: >> On Thu, 14 Dec 2017, Rafael J. Wysocki wrote: >>> The problem here is that pci_pm_thaw_noirq() calls pci_restore_state() which >>> in fact requires the device to be in D0, so

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

2017-12-11 Thread Maarten Lankhorst
Op 11-12-17 om 12:06 schreef Thomas Gleixner: > On Mon, 11 Dec 2017, Thomas Gleixner wrote: > >> On Mon, 11 Dec 2017, Daniel Vetter wrote: >>> Anything else we can do to move this? I just had to resolve a small >>> conflict when moving forward to -rc3. Carrying a revert for the entire >>> apic

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

2017-12-07 Thread Maarten Lankhorst
Op 06-12-17 om 15:15 schreef Thomas Gleixner: > On Wed, 6 Dec 2017, Maarten Lankhorst wrote: >> Op 06-12-17 om 13:46 schreef Thomas Gleixner: >>> On Wed, 6 Dec 2017, Maarten Lankhorst wrote: >>>> Op 06-12-17 om 13:15 schreef Michal Hocko: >>>>> &

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

2017-12-06 Thread Maarten Lankhorst
Op 06-12-17 om 13:46 schreef Thomas Gleixner: > On Wed, 6 Dec 2017, Maarten Lankhorst wrote: >> Op 06-12-17 om 13:15 schreef Michal Hocko: >>> "No irq handler" part looks a bit scary (maybe related to lost affinity >>> messages?) but the following messages look

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

2017-12-06 Thread Maarten Lankhorst
Op 06-12-17 om 13:15 schreef Michal Hocko: > On Mon 04-12-17 14:36:20, Linus Torvalds wrote: >> On Mon, Dec 4, 2017 at 2:25 PM, Rafael J. Wysocki wrote: >>> So far, resume from suspend-to-RAM (ACPI S3) is broken on all of the >>> systems I have tested, so it is probably safe

Re: [GIT pull] x86 APIC updates for 4.15

2017-12-06 Thread Maarten Lankhorst
Hey, Op 30-11-17 om 23:47 schreef Thomas Gleixner: > On Thu, 30 Nov 2017, Maarten Lankhorst wrote: >> Op 30-11-17 om 10:18 schreef Thomas Gleixner: >> # cat /sys/kernel/debug/irq/irqs/28 >> handler: handle_edge_irq >> device: :00:02.0 >> status: 0

Re: WARNING: CPU: 1 PID: 185 at drivers/gpu/drm/i915/intel_display.c:14422 intel_modeset_init+0x3dc/0xf60 [i915]

2017-11-30 Thread Maarten Lankhorst
Op 30-11-17 om 14:15 schreef Fengguang Wu: > Hello, > > This happens in mainline kernel v4.15-rc1 on LENOVO IdeaPad U410. > It at least dates back to v4.11 . > > It occurs in 72 out of 72 boots. Can I get a boot log with drm.debug=0x1f? I don't have enough information to see what's going on. :)

Re: [GIT pull] x86 APIC updates for 4.15

2017-11-30 Thread Maarten Lankhorst
Op 30-11-17 om 10:18 schreef Thomas Gleixner: > Maarten, > > On Wed, 29 Nov 2017, Maarten Lankhorst wrote: >> The changes to interrupts bring down our CI during hibernate, see: >> >> https://bugs.freedesktop.org/show_bug.cgi?id=103712 >> >> I created a bu

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

2017-11-29 Thread Maarten Lankhorst
Op 28-11-17 om 16:13 schreef Thomas Voegtle: > On Tue, 28 Nov 2017, Daniel Vetter wrote: > >> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote: >>> Some drivers like i915 start with crtc's enabled, but with deferred >>> fbcon setup they were no lo

Re: [GIT pull] x86 APIC updates for 4.15

2017-11-29 Thread Maarten Lankhorst
Hey, Op 13-11-17 om 13:05 schreef Thomas Gleixner: > Linus, > > please pull the latest x86-apic-for-linus git tree from: > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > x86-apic-for-linus > > This update provides a major overhaul of the APIC initialization and vector >

[PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

2017-11-28 Thread Maarten Lankhorst
once during initial fbdev setup. Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup") Cc: <sta...@vger.kernel.org> # v4.14+ Reported-by: Thomas Voegtle <t...@lio96.de> --- drivers/gpu/drm/drm_

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

2017-11-28 Thread Maarten Lankhorst
Op 28-11-17 om 10:30 schreef Thomas Voegtle: > On Tue, 28 Nov 2017, Maarten Lankhorst wrote: > >> Op 27-11-17 om 19:09 schreef Thomas Voegtle: >>> >>> Hello, >>> >>> with v4.14 I recognized that my file server (headless haswell system) >>&g

Re: v4.14/v4.15-rc1: deferred setup in drm/fb-helper breaks entering pc3

2017-11-28 Thread Maarten Lankhorst
Op 27-11-17 om 19:09 schreef Thomas Voegtle: > > Hello, > > with v4.14 I recognized that my file server (headless haswell system) > doesn't enter packages pc3 anymore and only enters pc2 according to > powertop. > In v4.13 the system used pc2 and pc3. > > So I bisected that down to: > >

Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()

2017-10-09 Thread Maarten Lankhorst
helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev, > drm_modeset_backoff(); > } > > + drm_atomic_state_put(state); > drm_modeset_drop_locks(); > drm_modeset_acquire_fini();

[PATCH 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

2017-07-19 Thread Maarten Lankhorst
We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. Cc: dri-de...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst

scripts/get_maintainer.pl misses maintainers sometimes

2017-07-12 Thread Maarten Lankhorst
~/linux$ git show | scripts/get_maintainer.pl | wc -l 37 ~/linux$ git show | scripts/get_maintainer.pl | wc -l 38 Any idea why this happens? The commit I used for testing is pasted below. Kind regards, Maarten Lankhorst --8<-- commit 94273dc6f6e3ab77948dddc6e0572ca7ea890520 Author: Daniel Vet

[PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

2017-07-11 Thread Maarten Lankhorst
We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. Cc: dri-de...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: intel-...@lists.freedesktop.org Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

2017-07-03 Thread Maarten Lankhorst
Op 30-06-17 om 15:56 schreef Daniel Vetter: > On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote: >> We want to change swap_state to wait indefinitely, but to do this >> swap_state should wait interruptibly. This requires propagating >> the error to each dri

Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

2017-07-03 Thread Maarten Lankhorst
Op 30-06-17 om 15:56 schreef Daniel Vetter: > On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote: >> We want to change swap_state to wait indefinitely, but to do this >> swap_state should wait interruptibly. This requires propagating >> the error to each dri

[PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

2017-06-28 Thread Maarten Lankhorst
kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: linux-te...@vger.kernel.org Signed-off-by: Maarten Lankhorst

[PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.

2017-06-28 Thread Maarten Lankhorst
Cc: Eric Anholt <e...@anholt.net> Cc: dri-de...@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: intel-...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-media...@lists.infradead.org Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org Cc: n

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-28 Thread Maarten Lankhorst
Op 27-06-17 om 17:01 schreef Daniel Vetter: > On Tue, Jun 27, 2017 at 04:29:44PM +0200, Maarten Lankhorst wrote: >> Op 27-06-17 om 09:37 schreef Daniel Vetter: >>> On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: >>>> On 2017-06-20 01:57 PM, Andrey G

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-27 Thread Maarten Lankhorst
Op 27-06-17 om 09:37 schreef Daniel Vetter: > On Mon, Jun 26, 2017 at 03:44:07PM -0400, Harry Wentland wrote: >> On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote: >>> Problem : While running IGT kms_atomic_transition test suite i encountered >>> a hang in drmHandleEvent immediately following an

Re: [PATCH] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

2017-06-12 Thread Maarten Lankhorst
Op 09-06-17 om 23:30 schreef Andrey Grodzovsky: > Problem: > While running IGT kms_atomic_transition test suite i encountered > a hang in drmHandleEvent immidietly follwoing an atomic_commit. > After dumping the atomic state I relized that in this case there was > not even one CRTC attached to the

[PATCH v3] drm/bridge: Build the panel wrapper in drm_kms_helper

2017-06-06 Thread Maarten Lankhorst
uot;) Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> --- diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index dc69175255b1..3999dffcd9ef 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -24,7 +24,6 @@ drm-$(CONFIG_COMPA

Re: [PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

2017-06-06 Thread Maarten Lankhorst
Op 05-06-17 om 12:08 schreef Archit Taneja: > > > On 06/03/2017 01:55 AM, Eric Anholt wrote: >> Many DRM drivers have common code to make a stub connector >> implementation that wraps a drm_panel. By wrapping the panel in a DRM >> bridge, all of the connector code (including calls during encoder

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

2016-12-16 Thread Maarten Lankhorst
Op 16-12-16 om 14:17 schreef Nicolai Hähnle: > On 06.12.2016 16:25, Peter Zijlstra wrote: >> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: >> >>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, >>> unsigned int subclass, >>> struct mutex_waiter

Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress

2016-11-30 Thread Maarten Lankhorst
Op 30-11-16 om 01:35 schreef Chris Wilson: > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Maarten Lankhorst <d...@mblankhorst.nl> > Cc: Nicolai Hähnle <nhaeh...@gmail.com> > ---

Re: [PATCH 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

2016-11-28 Thread Maarten Lankhorst
Op 28-11-16 om 13:20 schreef Nicolai Hähnle: > From: Nicolai Hähnle <nicolai.haeh...@amd.com> > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: Maarten Lankhorst <d...@mblankhorst.nl> > Cc: Daniel Vetter <dan

Re: [PATCH 1/4] locking/ww_mutex: Fix a deadlock affecting ww_mutexes

2016-11-23 Thread Maarten Lankhorst
ntinuously submits >>>> command streams from tens of threads, where all command streams reference >>>> hundreds of GPU buffer objects with a lot of overlap in the buffer lists >>>> between command streams. This test reliably caused a deadlock, and while I >>

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

2016-10-17 Thread Maarten Lankhorst
Op 17-10-16 om 08:05 schreef Daniel Vetter: > On Thu, Oct 13, 2016 at 05:04:03PM -0300, Paulo Zanoni wrote: >> Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu: >>> Op 08-10-16 om 02:11 schreef Lyude: >>>> Now that we've make skl_wm_levels make a little

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

2016-10-13 Thread Maarten Lankhorst
st use a single > helper, skl_write_wm_level(), to convert and write the new watermarks on > the fly. > > Changes since v1: > - Fixup skl_write_wm_level() > - Fixup skl_wm_level_from_reg_val() > - Don't forget to copy *active to intel_crtc->wm.active.skl > > Signed-o

Re: [PATCH 0/6] Start of skl watermark cleanup

2016-10-06 Thread Maarten Lankhorst
Op 05-10-16 om 17:33 schreef Lyude: > While it (mostly) works, the code for handling watermarks on Skylake has been > kind of ugly for a while. As well a lot of it isn't that friendly to atomic > transactions, Lots of copy paste, redundant wm values, etc. While this isn't a > full cleanup, it's a

Re: [Intel-gfx] [PATCH 4/6] drm/i915/gen9: Make skl_wm_level per-plane

2016-10-06 Thread Maarten Lankhorst
el, something we take advantage of in >> the next commit to cut down on all of the copy paste code in here. > I'd like to start my review pointing that I really like this patch. I > agree the current form is annoying. > > See below for some details. > > >> Signed-off-by

Re: [PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

2016-09-21 Thread Maarten Lankhorst
et...@intel.com> >Cc: Radhakrishna Sripada <radhakrishna.srip...@intel.com> >Cc: Hans de Goede <hdego...@redhat.com> >Signed-off-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com> >Link: > http://patchwork.freedesktop.org/patch/msgi

Re: [PATCH v3] drm/fence: allow fence waiting to be interrupted by userspace

2016-09-12 Thread Maarten Lankhorst
re we change the wait to be interruptible so it stop immediately when > userspace wants to quit. > > Also adds the necessary error checking for fence_wait(). > > v2: Comment by Daniel Vetter > - Add error checking for fence_wait() > > v3: Rebase on top of new atomic noblocking

Re: [RFC v4 1/3] drm/fence: add in-fences support

2016-09-01 Thread Maarten Lankhorst
Op 31-08-16 om 21:07 schreef Gustavo Padovan: > From: Gustavo Padovan > > There is now a new property called FENCE_FD attached to every plane > state that receives the sync_file fd from userspace via the atomic commit > IOCTL. > > The fd is then translated to a

Re: [PATCH v13 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

2016-08-23 Thread Maarten Lankhorst
Op 22-08-16 om 18:50 schreef Lyude: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New > values written to

Re: [PATCH v12 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

2016-08-22 Thread Maarten Lankhorst
Op 17-08-16 om 21:55 schreef Lyude: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New > values written to

Re: [PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-22 Thread Maarten Lankhorst
Op 18-08-16 om 16:05 schreef Lyude Paul: > On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote: >> Hey, >> >> Op 17-08-16 om 21:55 schreef Lyude: >>> Since the watermark calculations for Skylake are still broken, we're apt >>> to hitting un

Re: [PATCH v2 2/2] drm/fence: allow fence waiting to be interrupted by userspace

2016-08-18 Thread Maarten Lankhorst
re we change the wait to be interruptible so it stop immediately when > userspace wants to quit. > > Also adds the necessary error checking for fence_wait(). > > v2: Comment by Daniel Vetter > - Add error checking for fence_wait() > > v3: Rebase on top of new atomic noblocking

Re: [PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-18 Thread Maarten Lankhorst
timeout to jiffies > Changes since v2: > - Really apply minor style nitpicks to patch this time > Changes since v1: > - Added comments about this probably being one of the requirements to >fixing Skylake's watermark issues > - Minor style nitpicks from Matt Rop

Re: [PATCH 2/2] drm/fence: allow fence waiting to be interrupted by userspace

2016-08-15 Thread Maarten Lankhorst
Op 11-08-16 om 20:39 schreef Gustavo Padovan: > From: Gustavo Padovan > > If userspace is running an synchronously atomic commit and interrupts the > atomic operation during fence_wait() it will hang until the timer expires, > so here we change the wait to be

Re: [PATCH REBASED v10 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

2016-08-11 Thread Maarten Lankhorst
Hey, Op 10-08-16 om 16:28 schreef Lyude: > Now that we can hook into update_crtcs and control the order in which we > update CRTCs at each modeset, we can finish the final step of fixing > Skylake's watermark handling by performing DDB updates at the same time > as plane updates and watermark

Re: [PATCH REBASED v10 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-11 Thread Maarten Lankhorst
patch this time > Changes since v1: > - Added comments about this probably being one of the requirements to > fixing Skylake's watermark issues > - Minor style nitpicks from Matt Roper > - Disable these functions on Broxton, since it doesn't have an SAGV > > Reviewed-by: Matt R

Re: [PATCH v10] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-09 Thread Maarten Lankhorst
Hey, Op 08-08-16 om 23:03 schreef Lyude: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this

Re: [PATCH 2/7] staging/android: display sync_pt name on debugfs

2016-08-09 Thread Maarten Lankhorst
Op 08-08-16 om 21:59 schreef Gustavo Padovan: > 2016-08-08 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 20-06-16 om 17:53 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>> >>> When creati

Re: [PATCH 2/7] staging/android: display sync_pt name on debugfs

2016-08-08 Thread Maarten Lankhorst
Op 20-06-16 om 17:53 schreef Gustavo Padovan: > From: Gustavo Padovan > > When creating a sync_pt the name received wasn't used anywhere. > Now we add it to the sync info debug output to make it easier to indetify > the userspace name of that sync pt. > >

Re: [PATCH v8 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

2016-08-08 Thread Maarten Lankhorst
@intel.com> > Signed-off-by: Lyude <cp...@redhat.com> > Reviewed-by: Matt Roper <matthew.d.ro...@intel.com> > Cc: sta...@vger.kernel.org > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>

Re: [PATCH v6 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-03 Thread Maarten Lankhorst
enabled > + */ > + if (IS_SKYLAKE(dev_priv) && > + hweight32(intel_state->active_crtcs) > 1) > + skl_disable_sagv(dev_priv); > intel_modeset_verify_disabled(dev); > } > >

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

2016-08-02 Thread Maarten Lankhorst
Op 01-08-16 om 13:48 schreef Ville Syrjälä: > On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote: >> Op 29-07-16 om 22:33 schreef Matt Roper: >>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: >>>> On Thu, Jul 28, 2016 at 05:0

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

2016-08-01 Thread Maarten Lankhorst
Op 29-07-16 om 22:33 schreef Matt Roper: > On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: >> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: >>> This is completely untested (and probably horribly broken/buggy), but >>> here's a quick mockup of the general approach I was

Re: [PATCH v3 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-07-26 Thread Maarten Lankhorst
Op 26-07-16 om 16:50 schreef Lyude: > Since the watermark calculations for Skylake are still broken, we're apt > to hitting underruns very easily under multi-monitor configurations. > While it would be lovely if this was fixed, it's not. Another problem > that's been coming from this however, is

Re: [PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

2016-07-26 Thread Maarten Lankhorst
@intel.com> > Signed-off-by: Lyude <cp...@redhat.com> > Reviewed-by: Matt Roper <matthew.d.ro...@intel.com> > Cc: sta...@vger.kernel.org > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Ville Syrjälä <ville.syrj...@linux.intel.com&g

Re: [PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

2016-07-25 Thread Maarten Lankhorst
Op 21-07-16 om 21:23 schreef Lyude: > From: Matt Roper > > When we write watermark values to the hardware, those values are stored > in dev_priv->wm.skl_hw. However with recent watermark changes, the > results structure we're copying from only contains valid watermark

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/skl: Only flush pipes when we change the ddb allocation

2016-07-25 Thread Maarten Lankhorst
Op 21-07-16 om 21:23 schreef Lyude: > Manual pipe flushes are only necessary in order to make sure that we prevent > pipes with changed ddb allocations from overlapping from one another at > any point in time. Additionally, forcing us to wait for the next vblank > every time we have to update the

Re: [PATCH] dma-buf/sync_file: only enable fence signalling during wait

2016-07-12 Thread Maarten Lankhorst
Op 11-07-16 om 22:27 schreef Gustavo Padovan: > 2016-07-10 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 08-07-16 om 17:44 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>> >>> Signalli

Re: [PATCH] dma-buf/sync_file: only enable fence signalling during wait

2016-07-10 Thread Maarten Lankhorst
Op 08-07-16 om 17:44 schreef Gustavo Padovan: > From: Gustavo Padovan > > Signalling doesn't need to be enabled at sync_file creation, it is only > required if userspace waiting the fence to signal through poll(). > > Thus we delay fence_add_callback() until poll

Re: [PATCH] mutex: Report recursive ww_mutex locking early

2016-05-30 Thread Maarten Lankhorst
Op 30-05-16 om 12:45 schreef Chris Wilson: > On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote: >> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote: >>> Patch not applied, SCHED_RR: >> ww_mutex isn't RT aware at all; its one of the things I

Re: [PATCH] mutex: Report recursive ww_mutex locking early

2016-05-30 Thread Maarten Lankhorst
Op 30-05-16 om 11:11 schreef Peter Zijlstra: > On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote: >> Op 26-05-16 om 22:08 schreef Chris Wilson: >>> Recursive locking for ww_mutexes was originally conceived as an >>> exception. However, it is hea

Re: [PATCH] mutex: Report recursive ww_mutex locking early

2016-05-30 Thread Maarten Lankhorst
ever release the lock, we spin until > kicked, whereupon the deadlock is discovered and reported. > > A simple solution for the now common problem is to move the recursive > deadlock discovery to the first action when taking the ww_mutex. > > Testcase: igt/kms_cursor_legacy >

Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

2016-05-26 Thread Maarten Lankhorst
Op 26-05-16 om 12:43 schreef Chris Wilson: > On Thu, May 26, 2016 at 12:37:30PM +0200, Maarten Lankhorst wrote: >> The check should also not be for NULL, but for use_ww_ctx. >> This way the if check is optimized out for the ww_ctx path, where >> ww_ctx is always non-null. &

Re: [PATCH] mutex: Do not spin/queue before performing ww_mutex deadlock avoidance

2016-05-26 Thread Maarten Lankhorst
modesets. > > Testcase: igt/kms_cursor_legacy > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Ingo Molnar <mi...@redhat.com> > Cc: Christian König <christian.koe...@amd.com> > Cc: Maarten Lankhors

Re: [PATCH] MAINTAINERS: add entry for the Sync File Framework

2016-05-12 Thread Maarten Lankhorst
Cc: Sumit Semwal <sumit.sem...@linaro.org> > Signed-off-by: Gustavo Padovan <gustavo.pado...@collabora.co.uk> Acked-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

Re: [PATCH] drm/vc4: Return -EBUSY if there's already a pending flip event.

2016-05-03 Thread Maarten Lankhorst
Op 02-05-16 om 21:25 schreef robert.f...@collabora.com: > From: Robert Foss > > As per the docs, atomic_commit should return -EBUSY "if an asycnhronous > update is requested and there is an earlier update pending". > > Signed-off-by: Robert Foss

Re: [PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

2016-04-24 Thread Maarten Lankhorst
tavo Padovan <gustavo.pado...@collabora.co.uk> > Acked-by: Rob Clark <robdcl...@gmail.com> > Looking much better. Acked-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

Re: [PATCH v10 RESEND 2/3] kernel.h: add u64_to_user_ptr()

2016-04-20 Thread Maarten Lankhorst
Op 19-04-16 om 22:42 schreef Gustavo Padovan: > From: Gustavo Padovan > > This function had copies in 3 different files. Unify them in kernel.h. > > Cc: Joe Perches > Cc: Andrew Morton > Cc: David Airlie

Re: [PATCH] drm/i915: fix deadlock on lid open

2016-03-30 Thread Maarten Lankhorst
Op 30-03-16 om 11:08 schreef Bjørn Mork: > commit e2c8b8701e2d moved modeset locking inside resume/suspend > functions, but missed a code path only executed on lid close/open > on older hardware. The result was a deadlock when closing and > opening the lid without suspending on such hardware: >

Re: [RFC 0/6] drm/fences: add in-fences to DRM

2016-03-24 Thread Maarten Lankhorst
Hey, Op 23-03-16 om 19:47 schreef Gustavo Padovan: > From: Gustavo Padovan > > Hi, > > This is a first proposal to discuss the addition of in-fences support > to DRM. It adds a new struct to fence.c to abstract the use of sync_file > in DRM drivers. The new

Re: [lkp] [drm/i915] 396e33ae20: [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B

2016-03-19 Thread Maarten Lankhorst
Op 17-03-16 om 11:49 schreef William Dauchy: > On Mon, Jan 11, 2016 at 2:35 AM, kernel test robot > wrote: >> FYI, we noticed the below changes on >> >> git://anongit.freedesktop.org/drm-intel drm-intel-next-queued >> commit 396e33ae204f52abebec9e578f44c749305500f4

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

2016-03-03 Thread Maarten Lankhorst
> call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences > in the sync_file. > > Also, info->sync_fence_info was converted to __u64 pointer to prevent > 32bit compatibility issues. For this patch and 6/6: Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

Re: [PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO

2016-03-03 Thread Maarten Lankhorst
nfo)); > > err = ioctl(fd, SYNC_IOC_FILE_INFO, info); > } > > v2: fix fence_info memory leak > > v3: Comments from Emil Velikov > - improve commit message > - remove __u64 cast > - remove check for output fields in file_info >

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

2016-03-01 Thread Maarten Lankhorst
Op 29-02-16 om 23:08 schreef Gustavo Padovan: > Hi Maarten, > > 2016-02-29 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 26-02-16 om 22:00 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>>

Re: [PATCH v4 3/5] staging/android: remove redundant comments on sync_merge_data

2016-02-29 Thread Maarten Lankhorst
> - __s32 fence; /* fd on newly created fence */ > + __s32 fd2; > + charname[32]; > + __s32 fence; > }; > > /** For the first 3 patches: Reviewed-by: Maarten Lankhorst <maarten.lankho...@linux.intel.com>

Re: [PATCH v4 5/5] staging/android: add flags member to sync ioctl structs

2016-02-29 Thread Maarten Lankhorst
Op 26-02-16 om 19:31 schreef Gustavo Padovan: > From: Gustavo Padovan > > Play safe and add flags member to all structs. So we don't need to > break API or create new IOCTL in the future if new features that requires > flags arises. > > v2: check if flags are

Re: [PATCH] staging/android: refactor SYNC_IOC_FILE_INFO

2016-02-29 Thread Maarten Lankhorst
Op 26-02-16 om 22:00 schreef Gustavo Padovan: > From: Gustavo Padovan > > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and > optimize buffer allocation. In the new approach the ioctl needs to be called > twice to retrieve the array of fence_infos

Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer

2016-02-04 Thread Maarten Lankhorst
Op 03-02-16 om 21:09 schreef Gustavo Padovan: > Hi Maarten, > > 2016-02-03 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 03-02-16 om 14:25 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>> &g

Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer

2016-02-04 Thread Maarten Lankhorst
Op 04-02-16 om 14:05 schreef Gustavo Padovan: > 2016-02-04 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 03-02-16 om 21:09 schreef Gustavo Padovan: >>> Hi Maarten, >>> >>> 2016-02-03 Maarten Lankhorst <maarten.lankho...@linux.i

Re: [PATCH v2 06/11] staging/android: turn fence_info into a __u64 pointer

2016-02-03 Thread Maarten Lankhorst
Op 02-02-16 om 21:28 schreef Gustavo Padovan: > Hi Maarten, > > 2016-02-02 Maarten Lankhorst <maarten.lankho...@linux.intel.com>: > >> Op 02-02-16 om 14:23 schreef Gustavo Padovan: >>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk> >>> >

Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer

2016-02-03 Thread Maarten Lankhorst
Op 03-02-16 om 14:25 schreef Gustavo Padovan: > From: Gustavo Padovan > > Turn sync_fence_info into __u64 type enable us to extend the struct in the > future without breaking the ABI. > > v2: use type __u64 for fence_info > > v3: fix commit message to reflect the

Re: [PATCH v2 02/11] staging/android: rename sync_pt_info to fence_info

2016-02-02 Thread Maarten Lankhorst
Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > As struct sync_pt doesn't exist anymore it is a good idea remove any > reference to it in the sync_framework. sync_pts were replaced directly by > fences. > rename it to sync_fence_info to

Re: [PATCH v2 06/11] staging/android: turn fence_info into a __u64 pointer

2016-02-02 Thread Maarten Lankhorst
Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > Making fence_info a pointer enables us to extend the struct in the future > without breaking the ABI. > > v2: use type __u64 for fence_info > Signed-off-by: Gustavo Padovan

Re: [PATCH v2 08/11] staging/android: make info->len return only the size of fence_infos

2016-02-02 Thread Maarten Lankhorst
Op 02-02-16 om 14:23 schreef Gustavo Padovan: > From: Gustavo Padovan > > The len member of struct sync_file_info was returning the size of the whole > buffer (struct sync_file_info + fence_infos at the of it). This commit > change it to return only the size of

Re: [PATCH 09/10] staging/android: add flags member to sync ioctl structs

2016-02-01 Thread Maarten Lankhorst
Op 29-01-16 om 22:20 schreef Gustavo Padovan: > From: Gustavo Padovan > > Play safe and add flags member to all structs. So we don't need to > break API or create new IOCTL in the future if new features that requires > flags arises. > This only helps if you reject

  1   2   3   4   5   6   >