Re: [Intel-gfx] [PATCH v4] drm/i915/ilk: Don't disable SSC source if it's in use

2016-06-06 Thread Lyude Paul
On Mon, 2016-06-06 at 14:30 +0300, Ville Syrjälä wrote: > On Thu, May 26, 2016 at 09:54:56AM +0200, Daniel Vetter wrote: > > > > On Wed, May 25, 2016 at 02:11:02PM -0400, Lyude wrote: > > > > > > Thanks to Ville Syrjälä for pointing me towards the cause of this issue. > > > > > > Unfortunately

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Enable polling when we don't have hpd

2016-06-20 Thread Lyude Paul
As a forewarning: I have confirmed the CRT hpd loops Vsyrjala has mentioned, and they are triggered by this patch. I'm working on a patch for this atm. On Mon, 2016-06-20 at 16:57 -0400, Lyude wrote: > Unfortunately, there's two situations where we lose hpd right now: > - Runtime suspend > - When

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

2016-02-25 Thread Lyude Paul
Unfortunately MST is a wild beast, and doesn't work at all like other connectors. This being said, putting it above intel_display_resume() was the first thing I tried but that didn't work. Originally I had thought putting it this high up was required because I had assumed drm_mode_config_reset()

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Call intel_dp_mst_resume() before resuming displays

2016-03-18 Thread Lyude Paul
On Sun, 2016-03-13 at 19:45 +0100, Daniel Vetter wrote: > On Fri, Mar 11, 2016 at 10:57:01AM -0500, Lyude wrote: > > > > Since we need MST devices ready before we try to resume displays, > > calling this after intel_display_resume() can result in some issues with > > various laptop docks where

Re: [Intel-gfx] [PATCH] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()

2016-03-18 Thread Lyude Paul
On Wed, 2016-03-16 at 21:39 +0200, Ville Syrjälä wrote: > On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote: > > > > After unplugging a DP MST display from the system, we have to go through > > and destroy all of the DRM connectors associated with it since none of > > them are valid anymore.

Re: [Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

2016-04-11 Thread Lyude Paul
NAK. Try plugging in an MST display, suspending the machine, then resuming it. Hotplugging still breaks (which I've traced down to this patch) I wouldn't worry about fixing this up. I'm probably going to be sending a revert for this anyway soon along with probably some of the other patches. On

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Get rid of intel_dp_dpcd_read_wake()

2016-03-21 Thread Lyude Paul
On Fri, 2016-03-18 at 20:05 +0200, Ville Syrjälä wrote: > On Fri, Mar 18, 2016 at 07:00:29PM +0100, Daniel Vetter wrote: > > > > On Fri, Mar 18, 2016 at 06:41:40PM +0200, Ville Syrjälä wrote: > > > > > > On Fri, Mar 18, 2016 at 06:12:35PM +0200, Ville Syrjälä wrote: > > > > > > > > On Fri, Mar

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Call intel_dp_mst_resume() before resuming displays

2016-03-29 Thread Lyude Paul
bump Could we get a reviewed-by for this patch? It's needed in addition to the patch series I sent for removing intel_dp_dpcd_read_wake() for the T560 to have it's monitors work properly on resume. On Wed, 2016-03-16 at 17:49 -0400, Lyude Paul wrote: > On Sun, 2016-03-13 at 19:45 +0100, Dan

Re: [Intel-gfx] [PATCH v4 RESEND 1/5] drm/dp_helper: Increase retry interval to 1000us

2016-03-29 Thread Lyude Paul
Yep, the rest of the patchset works fine without this patch On Tue, 2016-03-29 at 10:27 +0200, Daniel Vetter wrote: > On Mon, Mar 28, 2016 at 10:33:22AM -0400, Lyude wrote: > > > > This is part of a patch series to migrate all of the workarounds for > > commonly seen behavior from bad sinks in

Re: [Intel-gfx] [PATCH v2 15/16] drm/i915/gen9: Reject display updates that exceed wm limitations

2016-04-22 Thread Lyude Paul
Thu, 2016-04-21 at 16:14 -0700, Matt Roper wrote: > On Thu, Apr 21, 2016 at 05:49:52PM -0400, Lyude Paul wrote: > > > > On a T560, this ends up rejecting valid watermark configurations so the > > internal > > display doesn't switch from fbcon to X properly: > Hmm.  W

Re: [Intel-gfx] [PATCH v2 15/16] drm/i915/gen9: Reject display updates that exceed wm limitations

2016-04-21 Thread Lyude Paul
On a T560, this ends up rejecting valid watermark configurations so the internal display doesn't switch from fbcon to X properly: [5.767383] [drm:intelfb_create] re-using BIOS fb [5.767444] [drm] Initialized i915 1.6.0 20160411 for :00:02.0 on minor 0 [5.767449]

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Wait one vblank before enabling audio

2016-05-23 Thread Lyude Paul
On Mon, 2016-05-23 at 21:06 +0300, Ville Syrjälä wrote: > On Fri, May 20, 2016 at 05:36:40PM -0400, Lyude wrote: > > > > We no longer call ilk_audio_codec_enable() while we have vblanks > > disabled. As such, we can finally fix this and stop the occasional pipe > > underruns I'm seeing on this

Re: [Intel-gfx] [PATCH v2] drm/i915/ilk: Don't disable SSC source if it's in use

2016-05-24 Thread Lyude Paul
Huh… so I'm going to have to take back what I said before about this. On further observation, it looks like the "Don't disable SSC source if it's in use" patch actually got rid of the underruns entirely, with or without the wait for a vblank here. On Tue, 2016-05-24 at 16:14 +0300, Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: Discard previous atomic state on resume if connectors change

2016-05-03 Thread Lyude Paul
Yeah airlied said the same thing. This patch is more intended for just 4.6 since the refcounting patch isn't very likely to get into 4.6. On Tue, 2016-05-03 at 16:29 +0200, Daniel Vetter wrote: > On Tue, May 03, 2016 at 10:03:40AM -0400, Lyude wrote: > > > > If an MST device is disconnected

Re: [Intel-gfx] [PATCH v3 09/16] drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)

2016-05-06 Thread Lyude Paul
On Thu, 2016-04-21 at 16:17 -0700, Matt Roper wrote: > Now that we're properly pre-allocating the DDB during the atomic check > phase and we trust that the allocation is appropriate, let's actually > use the allocation computed and not duplicate that work during the > commit phase. > > v2: >  -

Re: [Intel-gfx] [PATCH v3 09/16] drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)

2016-05-06 Thread Lyude Paul
On Fri, 2016-05-06 at 14:12 -0400, Lyude Paul wrote: > On Thu, 2016-04-21 at 16:17 -0700, Matt Roper wrote: > > > > Now that we're properly pre-allocating the DDB during the atomic check > > phase and we trust that the allocation is appropriate, let's actually > >

Re: [Intel-gfx] [PATCH] drm/i915: Fix enc_to_dig_port() for MST encoders

2016-05-02 Thread Lyude Paul
I gave a short try at fixing MST audio, but it definitely looks like it's going to require quite a bit of troubleshooting and a few more patches :(. Since I can't find an immediate fix to actually make MST audio work I'm totally in favor of reverting the MST audio support for the time being On

Re: [Intel-gfx] [PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

2016-05-05 Thread Lyude Paul
I would Cc it to stable just in case tbh. I picked up on this one since KASAN was picking up on some of the memcpy() calls around here going out of bounds. I can include some of the backtraces from that if needed. On Wed, 2016-05-04 at 19:11 +0200, Daniel Vetter wrote: > On Wed, May 04, 2016 at

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

2016-04-15 Thread Lyude Paul
Huh, neither am I now. I seem to be able to reproduce the problem just fine again. Anyway I'll send the new versions of the patches in a little bit On Fri, 2016-04-15 at 18:49 +0300, Ville Syrjälä wrote: > On Fri, Apr 15, 2016 at 09:47:51AM -0400, Lyude Paul wrote: > > > > Look

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Enable/disable VGA hotplugging properly

2016-04-15 Thread Lyude Paul
Looks like we might not need to worry about this patch anymore actually, looks like this problem got fixed by accident by one of the other vlv fixes you pushed. Now it's not always modesetting on hotplug when it was before though :(, so I'll get to work on bisecting that. On Thu, 2016-04-14 at

Re: [Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change

2016-05-09 Thread Lyude Paul
Yep, Dave's patches fix the issue on their own so this is only going to be needed for 4.6. On Mon, 2016-05-09 at 08:42 +0200, Daniel Vetter wrote: > On Fri, May 06, 2016 at 05:39:56PM -0400, Lyude wrote: > > > > If an MST device is disconnected while the machine is suspended, the > > number of

Re: [Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change

2016-05-09 Thread Lyude Paul
no problem, I'll let you know when they're ready On Mon, 2016-05-09 at 16:53 +0200, Daniel Vetter wrote: > On Mon, May 09, 2016 at 10:07:08AM -0400, Lyude Paul wrote: > > > > Yep, Dave's patches fix the issue on their own so this is only going to be > > needed for 4.6. >

Re: [Intel-gfx] [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

2016-07-21 Thread Lyude Paul
Two things for this one: 1. I completely messed up the description on this patchset, this was for fixing underruns on pipe disablement. I'm impressed I wrote up that whole description without realizing that at all, lol. 2. This patch may not actually be necessary. On the original git branch I was

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

2016-07-11 Thread Lyude Paul
ot; messages and leaving watermarks > non-functional, even ones initiated by intel_fbdev_restore_mode). > > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Lyude Paul <cp...@redhat.com> > Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

2016-08-03 Thread Lyude Paul
On Wed, 2016-08-03 at 18:00 +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 06:37:37PM -0400, Lyude wrote: > > > > 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

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

2016-08-18 Thread 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 underruns very easily under multi-monitor configurations. > > While it would be lovely if

Re: [Intel-gfx] [PATCH] drm/i915: Enable atomic support by default on supported platforms.

2017-02-02 Thread Lyude Paul
Nice! I actually was already thinking of bringing up the fact we should just be turning this on by default now, especially so we can see atomic start getting some real use. So, I'm more then happy to say I support flipping the switch :) Reviewed-by: Lyude On Thu, 2017-02-02 at

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Adapt to dynamic number of planes changes

2017-02-01 Thread Lyude Paul
Reviewed-by: Lyude If you need someone to push this let me know On Wed, 2017-02-01 at 12:56 +0200, Petri Latvala wrote: > CC: Robert Foss > CC: Lyude > Signed-off-by: Petri Latvala > --- >  

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

2017-02-23 Thread Lyude Paul
On Thu, 2017-02-23 at 07:26 +, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote: > > Now that we can just disable HPD storm detection, there's no need > > to > > sleep between each hotplug cycle. > > > > Signed-off-by: Lyude > > --- > >  

Re: [Intel-gfx] [PATCH i-g-t v4 0/5] Add support for the Chamelium

2017-01-16 Thread Lyude Paul
(CCing Tomeu Vizoso here since it looks like I somehow had suppresscc turned on by accident) On Mon, 2017-01-16 at 14:26 -0500, Lyude wrote: > This adds basic support for using the Chamelium in hotplugging tests, > along > with checking video outputs. > > So far there's

Re: [Intel-gfx] [PATCH v5 2/4] drm/i915: Switch to using port stored in intel_encoder

2016-08-31 Thread Lyude Paul
Reviewed-by: Lyude On Wed, 2016-08-31 at 17:20 -0700, Dhinakaran Pandiyan wrote: > Now that we have the port enum stored in intel_encoder, use that instead of > dereferencing intel_dig_port. Saves us a few locals. > > struct intel_encoder variables have been renamed to be

Re: [Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()

2016-09-08 Thread Lyude Paul
On Thu, 2016-09-08 at 11:59 +0300, Jani Nikula wrote: > On Wed, 07 Sep 2016, Lyude wrote: > > > > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote: > > > > > > And use it to move knowledge about the SAGV-supporting platforms from > > > the callers to the SAGV code. > > >

Re: [Intel-gfx] [PATCH v4 1/4] drm/i915: Store port enum in intel_encoder

2016-08-29 Thread Lyude Paul
Reviewed-by: Lyude On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote: > Storing the port enum in intel_encoder makes it convenient to know the > port attached to an encoder. Moving the port information up from > intel_digital_port to intel_encoder avoids unecessary

Re: [Intel-gfx] [PATCH v4 2/4] drm/i915: Switch to using port stored in intel_encoder

2016-08-29 Thread Lyude Paul
Looks like a much better solution then the previous one. Reviewed-by: Lyude On Wed, 2016-08-24 at 00:22 -0700, Dhinakaran Pandiyan wrote: > Now that we have the port enum stored in intel_encoder, use that instead of > dereferencing intel_dig_port. Saves us a few locals. > >

Re: [Intel-gfx] [PATCH 0/4] Backported vlv fixes for 4.7.y

2016-08-29 Thread Lyude Paul
drm/i915/vlv: Make intel_crt_reset() per-encoder: 4570d833390b10043d082fe535375d4a0e071d9c drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init(): 4c732e6ee9e71903934d75b12a021eb3520b6197 drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug(): 21842ea84f161ae37ba25f0250c377fd19c5b307

Re: [Intel-gfx] [PATCH v6 0/5] Prep. for DP audio MST support

2016-09-15 Thread Lyude Paul
For the new patch, and any of the other patches in this series I haven't reviewed yet, looks good to me: Reviewed-by: Lyude On Wed, 2016-09-14 at 17:17 -0700, Dhinakaran Pandiyan wrote: > This series lays the groundwork for more DP MST audio work that will > follow. > > v2: >

Re: [Intel-gfx] [PATCH] drm/i915/gen9: only add the planes actually affected by ddb changes

2016-09-29 Thread Lyude Paul
On Thu, 2016-09-29 at 15:39 -0300, Paulo Zanoni wrote: > We were previously adding all the planes owned by the CRTC even when > the ddb partitioning didn't change for them. As a consequence, a lot > of functions were being called when we were just moving the cursor > around the screen, such as

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

2016-10-10 Thread Lyude Paul
Was there a new workaround added recently? Or was this something I just missed when writing the original code for this On Mon, 2016-10-10 at 17:30 -0300, Paulo Zanoni wrote: > Mahesh Kumar is already working on a proper implementation for the > workaround, but while we still don't have it, let's

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen9: look for adjusted_mode in the SAGV check for interlaced

2016-10-10 Thread Lyude Paul
Reviewed-by: Lyude On Mon, 2016-10-10 at 17:30 -0300, Paulo Zanoni wrote: > We want to look at the mode that we're actually going to set. All the > other display checks for interlaced flags also look at adjusted_mode. > > Cc: Lyude > Signed-off-by: Paulo

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

2016-10-10 Thread Lyude Paul
we're going to have to apply other unrelated memory bandwidth workarounds on other platforms. How about skl_needs_memory_bw_wa() or gen9_needs_memory_bw_wa()? On Mon, 2016-10-10 at 20:46 +, Zanoni, Paulo R wrote: > Em Seg, 2016-10-10 às 16:34 -0400, Lyude Paul escre

Re: [Intel-gfx] [PATCH v2 09/11] drm/i915/gen9+: Program watermarks as a separate step during evasion, v2.

2016-10-26 Thread Lyude Paul
This approach is perfect :). Reviewed-by: Lyude On Wed, 2016-10-26 at 15:41 +0200, Maarten Lankhorst wrote: > The watermark updates for SKL style watermarks are no longer done > in the plane callbacks, but are now called in a separate watermark > update function that's called

Re: [Intel-gfx] [RFC 3/4] drm/i915/gen9: Expose top-most universal plane as cursor

2016-10-27 Thread Lyude Paul
the problem. > > Cc: Bob Paauwe <bob.j.paa...@intel.com> > Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> > Cc: Lyude Paul <ly...@redhat.com> > Signed-off-by: Matt Roper <matthew.d.ro...@intel.com> >

Re: [Intel-gfx] [RFC 3/4] drm/i915/gen9: Expose top-most universal plane as cursor

2016-10-27 Thread Lyude Paul
On Thu, 2016-10-27 at 15:35 -0700, Matt Roper wrote: > On Thu, Oct 27, 2016 at 06:15:32PM -0400, Lyude Paul wrote: > > > > On Wed, 2016-10-26 at 15:51 -0700, Matt Roper wrote: > > > > > > Gen9 has a traditional cursor plane that is mutually exclusive > > &

Re: [Intel-gfx] [RFC i-g-t 4/4] Add support for hotplug testing with the Chamelium

2016-11-14 Thread Lyude Paul
> > new file mode 100644 > > index 000..a281ef6 > > --- /dev/null > > +++ b/lib/igt_chamelium.c > > @@ -0,0 +1,628 @@ > > +/* > > + * Copyright © 2016 Red Hat Inc. > > + * > > + * Permission is hereby granted, free of charge,

Re: [Intel-gfx] [PATCH] drm/i915: Make skl_write_{plane, cursor}_wm() static

2016-11-22 Thread Lyude Paul
Reviewed-by: Lyude On Tue, 2016-11-22 at 22:21 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Someone forgot to make skl_write_{plane,cursor}_wm() static when > removing the prototypes from the header. Sparse isn't

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Use enum plane_id in SKL wm code

2016-11-22 Thread Lyude Paul
Looks good to me Reviewed-by: Lyude On Tue, 2016-11-22 at 18:01 +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Nuke skl_wm_plane_id() and just use the new intel_plane->id. > > v2: Convert skl_write_plane_wm() as well >

Re: [Intel-gfx] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium

2016-11-28 Thread Lyude Paul
: > On 15 November 2016 at 22:44, Lyude Paul <ly...@redhat.com> wrote: > > I'm fine with libsoup as well, I'll check it out and probably move > > all > > of the code over to using that instead. > > Cool. > > > On Tue, 2016-11-15 at 12:44 +0100, Tomeu Viz

Re: [Intel-gfx] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium

2016-11-11 Thread Lyude Paul
Alright, quick question: should we be going with your branch then or mine? On Wed, 2016-11-09 at 16:09 +0100, Tomeu Vizoso wrote: > Hi Lyude, > > I think this looks very good. > > On 8 November 2016 at 01:05, Lyude wrote: > > > > > >  - While writing this patch series, I

Re: [Intel-gfx] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium

2016-11-15 Thread Lyude Paul
I'm fine with libsoup as well, I'll check it out and probably move all of the code over to using that instead. On Tue, 2016-11-15 at 12:44 +0100, Tomeu Vizoso wrote: > On 11 November 2016 at 18:53, Lyude Paul <ly...@redhat.com> wrote: > > > > Alright, quick question: should

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

2016-11-03 Thread Lyude Paul
On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote: > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote: > > > > Weine's investigation on benchmarking the suspend/resume process pointed > > out a lot of the time in suspend/resume is being spent reprobing. While > > the reprobing process is

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

2016-11-03 Thread Lyude Paul
On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote: > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote: > > > > On Thu, Nov 03, 2016 at 11:42:37AM -0400, Lyude wrote: > > > > > > > > > Weine's investigation on benchmarking the suspend/resume p

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Remove redundant reprobe in i915_drm_resume

2016-11-03 Thread Lyude Paul
On Thu, 2016-11-03 at 16:25 +, Chris Wilson wrote: > On Thu, Nov 03, 2016 at 12:11:55PM -0400, Lyude Paul wrote: > > > > On Thu, 2016-11-03 at 12:11 -0400, Lyude Paul wrote: > > > > > > On Thu, 2016-11-03 at 16:02 +, Chris Wilson wrote: > > >

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

2016-10-13 Thread Lyude Paul
Your is SAGV related, and when we don't make the SAGV happy people's machines usually hang. So I'm definitely for your patches getting merged first On Thu, 2016-10-13 at 17:07 -0300, Paulo Zanoni wrote: > Em Qui, 2016-10-13 às 17:04 -0300, Paulo Zanoni escreveu: > > > > Em Qui, 2016-10-13 às

Re: [Intel-gfx] [RFC i-g-t v3 5/5] Add support for hotplug testing with the Chamelium

2016-12-07 Thread Lyude Paul
h" > >  #include "rendercopy.h" > > > > +#ifdef HAVE_CHAMELIUM > > +#include "igt_chamelium.h" > > +#endif > > + > >  #endif /* IGT_H */ > > diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c > > new

Re: [Intel-gfx] [PATCH i-g-t] igt_kms: Dynamically allocate igt_display->pipes

2016-12-13 Thread Lyude Paul
Pushed, thanks On Tue, 2016-12-13 at 07:20 +0200, Abdiel Janulgue wrote: > > On 12.12.2016 22:50, Lyude wrote: > > Many GPUs have more then 3 pipes available, so hard limiting this > > to > > I915_MAX_PIPES prevents us from using anything that relies on > > igt_display_init() on non-intel

Re: [Intel-gfx] [PATCH] drm/probe-helpers: Drop locking from poll_enable

2017-01-12 Thread Lyude Paul
Fixes locking issues I've witnessed on the W541. Tested-by: Lyude Reviewed-by: Lyude On Wed, 2017-01-11 at 10:01 +0100, Daniel Vetter wrote: > It was only needed to protect the connector_list walking, see > > commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/gen9: Fix PCODE polling during SAGV disabling

2016-11-29 Thread Lyude Paul
One tiny nitpick below On Mon, 2016-11-28 at 13:12 +0200, Imre Deak wrote: > According to the previous patch, it's possible atm that we call > intel_do_sagv_disable() only once during the 1ms period and time out > if > that call fails. As opposed to this the spec says that we need to > keep >

Re: [Intel-gfx] [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

2017-01-05 Thread Lyude Paul
On Thu, 2017-01-05 at 09:52 +0100, Daniel Vetter wrote: > On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote: > > No matter what we do here, the question remains what to do with > > Chamelium. Changing the color range is really a workaround for > > Chamelium, not a fix. Using CEA range is

Re: [Intel-gfx] [PATCH i-g-t] igt_core: add igt_constructor

2016-12-21 Thread Lyude Paul
On Wed, 2016-12-21 at 20:25 +, Chris Wilson wrote: > On Wed, Dec 21, 2016 at 03:17:21PM -0500, Lyude wrote: > > This is a simple macro for executing a block of code at the > > beginning of > > intel-gpu-tools, before any tests have been ran. Useful for > > initialization of global resources

Re: [Intel-gfx] Panic after S3 resume and modeset with MST

2017-03-30 Thread Lyude Paul
On Thu, 2017-03-30 at 07:55 +0200, Takashi Iwai wrote: > On Thu, 30 Mar 2017 02:24:37 +0200, > Lyude Paul wrote: > > > > On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote: > > > On Wed, 29 Mar 2017 15:34:15 +0200, > > > Ville Syrjälä wrote: > > >

Re: [Intel-gfx] Panic after S3 resume and modeset with MST

2017-03-30 Thread Lyude Paul
On Thu, 2017-03-30 at 20:50 +0200, Takashi Iwai wrote: > > Sure, if we get a proper stack dump, we can analyze it somehow.  You > can use addr2line, or even check objdump output manually. > But in this case, as already mentioned, it was impossible to get any > sensible stack trace on my machine

Re: [Intel-gfx] Panic after S3 resume and modeset with MST

2017-03-29 Thread Lyude Paul
On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote: > On Wed, 29 Mar 2017 15:34:15 +0200, > Ville Syrjälä wrote: > > > > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote: > > > On Mon, 27 Mar 2017 18:02:13 +0200, > > > Takashi Iwai wrote: > > > > > > > > Hi, > > > > > > > > the

Re: [Intel-gfx] Panic after S3 resume and modeset with MST

2017-03-27 Thread Lyude Paul
Hi! Just an FYI I am planning on taking a look at this very soon On Mon, 2017-03-27 at 18:02 +0200, Takashi Iwai wrote: > Hi, > > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422 > drm/i915: Call intel_dp_mst_resume() before resuming displays > > seems to trigger a kernel panic

Re: [Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

2017-03-15 Thread Lyude Paul
Acked-by: Lyude On Mon, 2017-03-13 at 17:02 +, Chris Wilson wrote: > In order to prevent accessing the hpd registers outside of the > display > power wells, we should refrain from writing to the registers before > the > display interrupts are enabled. > > [4.740136]

Re: [Intel-gfx] [PATCH i-g-t v2 2/2] chamelium: Add support for VGA frame comparison testing

2017-07-17 Thread Lyude Paul
Just one change for this patch below On Wed, 2017-07-12 at 17:57 +0300, Paul Kocialkowski wrote: > This adds support for VGA frame comparison testing with the reference > generated from cairo. The retrieved frame from the chamelium is first > cropped, as it contains the blanking intervals,

Re: [Intel-gfx] [PATCH i-g-t v4 2/7] chamelium: Calculate CRC from framebuffer instead of hardcoding it

2017-07-17 Thread Lyude Paul
On Wed, 2017-07-12 at 17:50 +0300, Paul Kocialkowski wrote: > This introduces CRC calculation for reference frames, instead of > using > hardcoded values for them. The rendering of reference frames may > differ > from machine to machine, especially due to font rendering, and the > frame itself may

Re: [Intel-gfx] [PATCH i-g-t v4 0/7] CRC testing with Chamelium improvements

2017-07-17 Thread Lyude Paul
The only thing that needs changing is the thing I mentioned on patch #2. After you make sure exiting prematurely doesn't cause the rest of IGT to segfault or something like that, that should hopefully be the last change that will need to be done. Afterwards I will push the whole series at once.

Re: [Intel-gfx] [PATCH i-g-t 0/1] chamelium: Add support for VGA frame comparison testing

2017-07-17 Thread Lyude Paul
Hey! The only changes I need on this is the small fix I mentioned for patch #2, and a nitpick regarding the spellings being used for the functions. I wasn't sure whether or not we should be using analog or analogue (us spelling vs. everyone else) but apparently the answer is to use the US

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

2017-07-11 Thread Lyude Paul
On Mon, 2017-07-10 at 13:27 +0300, Paul Kocialkowski wrote: > On Thu, 2017-07-06 at 17:57 -0400, Lyude Paul wrote: > > --snip-- > > (also sorry this one took a while to get to, had to do a lot of > > thinking because I never really solved the problems mentioned here > &g

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

2017-07-06 Thread Lyude Paul
--snip-- (also sorry this one took a while to get to, had to do a lot of thinking because I never really solved the problems mentioned here when I tried working on this...) On Thu, 2017-07-06 at 16:33 +0300, Paul Kocialkowski wrote: > On Thu, 2017-07-06 at 14:31 +0300, Paul Kocialkowski wrote: >

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

2017-07-06 Thread Lyude Paul
On Thu, 2017-07-06 at 14:35 +0300, Paul Kocialkowski wrote: > On Thu, 2017-07-06 at 10:41 +0300, Martin Peres wrote: > > On 06/07/17 00:44, Lyude Paul wrote: > > > On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote: > > > > When a CRC comparison error occ

Re: [Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

2017-07-06 Thread Lyude Paul
On Thu, 2017-07-06 at 16:14 +0300, Paul Kocialkowski wrote: > On Wed, 2017-07-05 at 16:34 -0400, Lyude Paul wrote: > > So a couple of notes here that will make it a lot easier for me to > > review these in the future > > > >  * When you're doing a new revision of a

Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules

2017-07-18 Thread Lyude Paul
Acked-by: Lyude On Tue, 2017-07-18 at 18:00 +0200, Daniel Vetter wrote: > There's a bunch of reasons why I think we should formalize and > enforce > our review rules for igt patches: > > - We have a lot of new engineers joining and review helps enormously > with mentoring

Re: [Intel-gfx] [PATCH i-g-t 0/2] Unrelated hotplug uevent masking out actual test result

2017-07-18 Thread Lyude Paul
For the whole series Reviewed-by: Lyude will push in just a sec On Tue, 2017-07-18 at 18:16 +0300, Paul Kocialkowski wrote: > This patch introduces a workaround for a case where a uevent is > issued > by the kernel because of DP link training failing on a connector >

Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements

2017-07-19 Thread Lyude Paul
Thank you for all of the great work you're doing! This looks perfect, so for the whole series Reviewed-by: Lyude I've pushed everything upstream, congrats! On Wed, 2017-07-19 at 16:46 +0300, Paul Kocialkowski wrote: > Changes since v4: > * Moved igt_get_cairo_surface out of

Re: [Intel-gfx] [PATCH i-g-t v3 0/2] Analogue/VGA frame comparison support

2017-07-19 Thread Lyude Paul
For both patches once you squash the configure.ac changes into the first one: Reviewed-by: Lyude Once you post the new versions I'll just go ahead and push them On Wed, 2017-07-19 at 16:48 +0300, Paul Kocialkowski wrote: > Changes since v2: > * Changed analogue in favor of

Re: [Intel-gfx] [PATCH i-g-t 3/3] configure.ac: Make gsl dependency and dependent code optional

2017-07-19 Thread Lyude Paul
R-B for the first two, I've already pushed them. For this one I'd prefer it if you just squashed it into the series where you add analog frame comparison support. Otherwise, looks good. On Wed, 2017-07-19 at 17:59 +0300, Paul Kocialkowski wrote: > This adds automake instructions, with matching

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests/chamelium: Skip suspend/resume test with unreliable hotplug event

2017-07-19 Thread Lyude Paul
On Wed, 2017-07-19 at 11:31 +0300, Paul Kocialkowski wrote: > On Tue, 2017-07-18 at 22:21 +0100, Chris Wilson wrote: > > Quoting Paul Kocialkowski (2017-07-18 16:16:26) > > > It may occur that a hotplug uevent is detected at resume, even > > > though it > > > does not indicate that an actual

Re: [Intel-gfx] [PATCH i-g-t v4 0/2] Analogue/VGA frame comparison support

2017-07-20 Thread Lyude Paul
For the whole series: Reviewed-by: Lyude I've also just pushed them, cheers! On Thu, 2017-07-20 at 18:13 +0300, Paul Kocialkowski wrote: > Changes since v3: > * Squashed configure.ac changes in this series > > Changes since v2: > * Changed analogue in favor of analog > *

Re: [Intel-gfx] [PATCH i-g-t 1/2] lib/igt_core: Move all config-related parsing to common_init_config

2017-07-20 Thread Lyude Paul
For the whole series: Reviewed-by: Lyude And pushed On Thu, 2017-07-20 at 17:11 +0300, Paul Kocialkowski wrote: > This moves all the pieces related to config parsing to the dedicated > function for this purpose, renamed common_init_config for > consistency. > > It allows

Re: [Intel-gfx] [PATCH i-g-t v3] tests/chamelium: Detect analog bridges and handle EDID accordingly

2017-07-21 Thread Lyude Paul
On Fri, 2017-07-21 at 11:19 +0300, Paul Kocialkowski wrote: > On Wed, 2017-07-19 at 16:50 +0300, Paul Kocialkowski wrote: > > Nowadays, many VGA connectors are not actually native VGA but use a > > discrete bridge to a digital connector. These bridges usually > > enforce > > their own EDID instead

Re: [Intel-gfx] [PATCH i-g-t 3/3] README: Add information about chamelium dependencies

2017-07-25 Thread Lyude Paul
R-b'd and pushed, thanks! On Tue, 2017-07-25 at 15:48 +0300, Paul Kocialkowski wrote: > This adds a list of dependencies required to build chamelium support, > so that what needs to be installed to get it going is more obvious. > > As done previously in the file, the list is relevant for Debian

Re: [Intel-gfx] [PATCH i-g-t 1/3] configure.ac: Make udev a dependency for chamelium

2017-07-25 Thread Lyude Paul
R-b'd and pushed, thanks! On Tue, 2017-07-25 at 15:48 +0300, Paul Kocialkowski wrote: > Chamelium testing has a hard dependency on udev. This makes this > dependency explicit in configure instead of failing the build when it > is missing. > > Signed-off-by: Paul Kocialkowski

Re: [Intel-gfx] [PATCH i-g-t 2/3] configure.ac: Disable chamelium by default and add enable argument

2017-07-25 Thread Lyude Paul
I like this patch, however there's a mistake in it: On Tue, 2017-07-25 at 15:48 +0300, Paul Kocialkowski wrote: > Since the chamelium is not a very usual piece of hardware and > requires > pulling-in lots of specific dependencies, it makes sense to keep it > disabled by default. > > An explicit

Re: [Intel-gfx] [PATCH i-g-t v2] configure.ac: Disable chamelium by default and add enable argument

2017-07-26 Thread Lyude Paul
r-b'd and pushed, thanks! On Wed, 2017-07-26 at 11:11 +0300, Paul Kocialkowski wrote: > Since the chamelium is not a very usual piece of hardware and > requires > pulling-in lots of specific dependencies, it makes sense to keep it > disabled by default. > > An explicit --enable-chamelium

Re: [Intel-gfx] [PATCH i-g-t v4 2/3] chamelium: Remove init reset duplicate in favor of per-test reset

2017-07-06 Thread Lyude Paul
RB'd and pushed On Tue, 2017-07-04 at 16:33 +0300, Paul Kocialkowski wrote: > Since most tests are already doing a reset, there is no need to > duplicate it at init time. This removes that duplicate reset and adds > a call to reset_state where in-test resets where not done previously. > >

Re: [Intel-gfx] [PATCH i-g-t v4 3/3] Make igtrc configuration common, with configurable suspend/resume delay

2017-07-06 Thread Lyude Paul
RB'd and pushed, thanks! On Tue, 2017-07-04 at 16:33 +0300, Paul Kocialkowski wrote: > This adds support for configurable suspend/resume delay and takes the > occasion to move igtrc configuation from igt_chamelium to igt_core. > This way, suspend/resume delay configuration can be used for all >

Re: [Intel-gfx] [PATCH i-g-t v4 1/3] tests/chamelium: Update connector state without reprobe when possible

2017-07-06 Thread Lyude Paul
On Tue, 2017-07-04 at 16:33 +0300, Paul Kocialkowski wrote: > This renames the reprobe_connector function to update_connector and > ensures that full reprobe of the connector is only done when really > necessary (e.g. when changing the EDID). > > A full reprobe takes time and is not required for

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

2017-07-05 Thread Lyude Paul
On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote: > When a CRC comparison error occurs, it is quite useful to get a dump > of both the frame obtained from the chamelium and the reference in > order > to compare them. > > This implements the frame dump, with a configurable path that

Re: [Intel-gfx] [PATCH i-g-t v2 7/7] Make igtrc configuration common, with configurable suspend/resume delay

2017-06-27 Thread Lyude Paul
On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote: > This adds support for configurable suspend/resume delay and takes the > occasion to move igtrc configuation from igt_chamelium to igt_core. > This way, suspend/resume delay configuration can be used for all > tests. > >

Re: [Intel-gfx] [PATCH i-g-t v2 6/7] tests/chamelium: Disconnect connectors without extra reset

2017-06-27 Thread Lyude Paul
NAK, I'd rather just go with the idea you had with removing the connector reset in chamelium_init() On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote: > This removes the reset call from the reset_state function and renames > it > to disconnect_connector. Since a call to reset is already

Re: [Intel-gfx] [PATCH i-g-t v2 1/7] lib/igt_aux: Use provided autoresume delay for rtc wake

2017-06-27 Thread Lyude Paul
FYI: I reviewed and pushed patches 1-4 of this series, thanks! On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote: > This stores the autoresume delay provided via > igt_set_autoresume_delay > for use during suspend via rtc wake scheduling. This delay was > previously only used for pm_test

Re: [Intel-gfx] [PATCH i-g-t v2 5/7] tests/chamelium: Update connector state without reprobe when possible

2017-06-27 Thread Lyude Paul
I -think- this one might be okay but I just got reminded of a rather not-obvious part of the DRM spec for hotplugging, and I need to check that this doesn't actually break that. will get back to you in a bit with an actual review :) On Tue, 2017-06-27 at 13:53 +0300, Paul Kocialkowski wrote: >

Re: [Intel-gfx] [PATCH i-g-t v3 3/4] lib/igt_chamelium: Add support for dumping chamelium frames to a png

2017-07-05 Thread Lyude Paul
On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote: > This introduces a chamelium_write_frame_to_png function that saves a > Chamelium frame dump to a png file. This should be useful when a > frame > comparison with a reference fails. > > Signed-off-by: Paul Kocialkowski

Re: [Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

2017-07-05 Thread Lyude Paul
On Wed, 2017-07-05 at 16:34 -0400, Lyude Paul wrote: > So a couple of notes here that will make it a lot easier for me to > review these in the future > >  * When you're doing a new revision of a patch series, it's helpful > to >    keep it in the same email thread as the o

Re: [Intel-gfx] [PATCH i-g-t v3 2/4] tests/ chamelium: Remove the frame dump tests

2017-07-05 Thread Lyude Paul
NAK. You're right that these don't actually give us any advantage over just using CRCs and are just slower, however I left these tests in here moreso just so we had something to actually test the frame dumping functions so that we could avoid regressing them by accident since we're the only users

Re: [Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

2017-07-05 Thread Lyude Paul
So a couple of notes here that will make it a lot easier for me to review these in the future * When you're doing a new revision of a patch series, it's helpful to keep it in the same email thread as the original v1 so it's easier to keep track of in people's mail clients (as well as

Re: [Intel-gfx] [PATCH i-g-t] tests/Makefile.am: Wrap audio test with dedicated conditional

2017-08-22 Thread Lyude Paul
r-b'd and pushed, thanks! On Tue, 2017-08-22 at 11:26 +0300, Paul Kocialkowski wrote: > This uses the dedicated HAVE_AUDIO conditional, that depends on both > ALSA and GSL, for wrapping the audio test. This makes the wrapping > consistent with what is done for the chamelium test. > >

Re: [Intel-gfx] [PATCH i-g-t 4/7] lib/igt_chamelium: Add support for configurable DUT suspend/resume delay

2017-06-26 Thread Lyude Paul
> > > > Fair enough, but at this point, only lib/igt_chamelium.c is using > > igtrc and all > > the parsing is implemented there. > > > > So one course of action here would be to move igtrc parsing outside > > of > > igt_chamelium (maybe to igt_core?) and use some global variable for > > storing

Re: [Intel-gfx] [PATCH i-g-t 2/7] tests/chamelium: Check all connectors state for basic hotplug

2017-06-26 Thread Lyude Paul
rb'd and pushed, thanks! On Mon, 2017-06-26 at 16:59 +0300, Paul Kocialkowski wrote: > Without doing a full reprobe, hpd toggles are sent without much delay > between them. With a VGA connector attached, the reset occurring > before > the test will toggle its state, with a delay (inherent to hpd

  1   2   3   4   >