Re: [Intel-gfx] linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

On Thu, 3 Nov 2016 17:19:58 + Liviu Dudau  wrote:
>
> I have revamped the mali-dp tree and rebased it on the newer
> version of drm-next (which includes the drm-misc change) and pushed the
> updated patch in my tree.

Thanks for that.  However, several of the commits in your tree now have
no Signed-off-by from you as the committer :-(

-- 
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 04/12] drm/i915: return EACCES for check_cmd() failures

[sourab gupta]

On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> check_cmd() is checking whether a command adheres to certain
> restrictions that ensure it's safe to execute within a privileged batch
> buffer. Returning false implies a privilege problem, not that the
> command is invalid.
> 
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.
> 
> In a case where userspace may want to test whether it can successfully
> write to a register that needs privileges the distinction may be
> important and an EINVAL error may be considered fatal.
> 
> In particular this is currently true for Mesa, which includes a test for
> whether OACONTROL can be written too, but Mesa treats any error when
> flushing a batch buffer as fatal, calling exit(1).
> 
> As it is currently Mesa can gracefully handle a failure to write to
> OACONTROL if the command parser is disabled, but if we were to remove
> OACONTROL from the parser's whitelist then the returned EINVAL would
> break Mesa applications as they attempt an OACONTROL write.
> 
> This bumps the command parser version from 7 to 8, as the change is
> visible to userspace.
> 
> Signed-off-by: Robert Bragg 
> Reviewed-by: Matthew Auld 
Well, looks reasonable to me.

Reviewed-by: Sourab Gupta 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Update connector status for DP MST hotplugs

[kbuild test robot]

Hi Dhinakaran,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.9-rc3 next-20161028]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dhinakaran-Pandiyan/drm-i915-dp-Update-connector-status-for-DP-MST-hotplugs/20161104-113409
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x010-201644 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_dp_mst.c: In function 'intel_dp_mst_hotplug':
>> drivers/gpu/drm/i915/intel_dp_mst.c:509:4: error: 'changed' undeclared 
>> (first use in this function)
   changed = true;
   ^~~
   drivers/gpu/drm/i915/intel_dp_mst.c:509:4: note: each undeclared identifier 
is reported only once for each function it appears in
>> drivers/gpu/drm/i915/intel_dp_mst.c:496:7: warning: unused variable 'change' 
>> [-Wunused-variable]
 bool change = false;
  ^~

vim +/changed +509 drivers/gpu/drm/i915/intel_dp_mst.c

   490  static void intel_dp_mst_hotplug(struct drm_dp_mst_topology_mgr *mgr)
   491  {
   492  struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, 
mst_mgr);
   493  struct intel_digital_port *intel_dig_port = 
dp_to_dig_port(intel_dp);
   494  struct drm_device *dev = intel_dig_port->base.base.dev;
   495  struct intel_connector *intel_connector;
 > 496  bool change = false;
   497  enum drm_connector_status old_status;
   498  
   499  for_each_intel_connector(dev, intel_connector) {
   500  struct drm_connector *connector = 
&(intel_connector->base);
   501  
   502  if (intel_connector->mst_port != intel_dp)
   503  continue;
   504  
   505  old_status = connector->status;
   506  connector->status = connector->funcs->detect(connector, 
false);
   507  
   508  if (old_status != connector->status)
 > 509  changed = true;
   510  }
   511  
   512  if (changed)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: Update connector status for DP MST hotplugs (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Update connector status for DP MST hotplugs (rev2)
URL   : https://patchwork.freedesktop.org/series/14821/
State : warning

== Summary ==

Series 14821v2 drm/i915/dp: Update connector status for DP MST hotplugs
https://patchwork.freedesktop.org/api/1.0/series/14821/revisions/2/mbox/

Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> DMESG-WARN (fi-snb-2520m)
Subgroup force-load-detect:
dmesg-warn -> PASS   (fi-snb-2520m)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:241  pass:188  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:208  dwarn:1   dfail:0   fail:0   skip:32 
fi-snb-2600  total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-byt-n2820 failed to collect. IGT log at Patchwork_2901/fi-byt-n2820/igt.log

21f242e536b5077c046df785a8c4c28374941c15 drm-intel-nightly: 
2016y-11m-03d-21h-01m-03s UTC integration manifest
bc09ce1 drm/i915/dp: Update connector status for DP MST hotplugs

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2901/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: Update connector status for DP MST hotplugs

[Dhinakaran Pandiyan]

Hotplugging a monitor in DP MST configuration triggers short pulses.
Although the short pulse handling path ends up in the MST hotplug function,
we do not perform a detect before sending the hotplug uvent. This leads to
the connector status not being updated when the userspace calls
DRM_IOCTL_MODE_GETCONNECTOR.

So, let's call the connector function ->detect() to update the connector
status before sending the uevent.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..80810c9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -492,8 +492,25 @@ static void intel_dp_mst_hotplug(struct 
drm_dp_mst_topology_mgr *mgr)
struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct intel_connector *intel_connector;
+   bool changed = false;
+   enum drm_connector_status old_status;
+
+   for_each_intel_connector(dev, intel_connector) {
+   struct drm_connector *connector = &(intel_connector->base);
+
+   if (intel_connector->mst_port != intel_dp)
+   continue;
+
+   old_status = connector->status;
+   connector->status = connector->funcs->detect(connector, false);
+
+   if (old_status != connector->status)
+   changed = true;
+   }
 
-   drm_kms_helper_hotplug_event(dev);
+   if (changed)
+   drm_kms_helper_hotplug_event(dev);
 }
 
 static const struct drm_dp_mst_topology_cbs mst_cbs = {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: Update connector status for DP MST hotplugs

[Dhinakaran Pandiyan]

Hotplugging a monitor in DP MST configuration triggers short pulses.
Although the short pulse handling path ends up in the MST hotplug function,
we do not perform a detect before sending the hotplug uvent. This leads to
the connector status not being updated when the userspace calls
DRM_IOCTL_MODE_GETCONNECTOR.

So, let's call the connector function ->detect() to update the connector
status before sending the uevent.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..a28b12b 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -492,8 +492,25 @@ static void intel_dp_mst_hotplug(struct 
drm_dp_mst_topology_mgr *mgr)
struct intel_dp *intel_dp = container_of(mgr, struct intel_dp, mst_mgr);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct intel_connector *intel_connector;
+   bool change = false;
+   enum drm_connector_status old_status;
+
+   for_each_intel_connector(dev, intel_connector) {
+   struct drm_connector *connector = &(intel_connector->base);
+
+   if (intel_connector->mst_port != intel_dp)
+   continue;
+
+   old_status = connector->status;
+   connector->status = connector->funcs->detect(connector, false);
+
+   if (old_status != connector->status)
+   changed = true;
+   }
 
-   drm_kms_helper_hotplug_event(dev);
+   if (changed)
+   drm_kms_helper_hotplug_event(dev);
 }
 
 static const struct drm_dp_mst_topology_cbs mst_cbs = {
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 10/12] drm/i915: add oa_event_min_timer_exponent sysctl

[Robert Bragg]

On Wed, Nov 2, 2016 at 6:29 AM, sourab gupta  wrote:

> On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> > The minimal sampling period is now configurable via a
> > dev.i915.oa_min_timer_exponent sysctl parameter.
> >
> > Following the precedent set by perf, the default is the minimum that
> > won't (on its own) exceed the default kernel.perf_event_max_sample_rate
> > default of 10 samples/s.
> >
> > Signed-off-by: Robert Bragg 
> > Reviewed-by: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_perf.c | 42 --
> --
> >  1 file changed, 30 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > index 4e42073..e3c6f51 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -82,6 +82,22 @@ static u32 i915_perf_stream_paranoid = true;
> >  #define INVALID_CTX_ID 0x
> >
> >
> > +/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
> > +static int oa_exponent_max = OA_EXPONENT_MAX;
> > +
> > +/* Theoretically we can program the OA unit to sample every 160ns but
> don't
> > + * allow that by default unless root...
> > + *
> > + * The period is derived from the exponent as:
> > + *
> > + *   period = 80ns * 2^(exponent + 1)
> > + *
> > + * Referring to perf's kernel.perf_event_max_sample_rate for a
> precedent
> > + * (10 by default); with an OA exponent of 6 we get a period of
> 10.240
> > + * microseconds - just under 10Hz
> > + */
> > +static u32 i915_oa_min_timer_exponent = 6;
>
> For HSW, the timestamp period is 80ns, so the exponent of 6 translates
> to sampling rate of ~10Hz. But the timestamp period may change for
> other platforms, leading to different values of oa_min_timer_exponent
> corresponding to sampling rate of ~10Hz. Do we plan to have this
> value platform specific subsequently, or the guidance value of ~10Hz
> min sampling rate needn't be strictly followed?
>

actually it's bothered me a bit that I've been lazy with not having this
adapt for gen9+ in later patches

I think it would probably be better to make this a Hz based threshold for
userspace, otherwise any userspace policy here needs to be adapted for each
system with a different timestamp frequency which isn't great.

I've updated the patch locally to make this an oa_max_sample_rate parameter
in Hz, which I'll aim to test on haswell tomorrow and send out.

Thanks,
- Robert
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

[Daniel Vetter]

On Sat, Oct 1, 2016 at 2:22 AM, Jerome Anand  wrote:
> Legacy Hdmi audio drivers are added.
> Added support for audio/ gfx interface using irq chip framework

Just discussed this with Rakesh here at LPC and also with Mark Brown
and since earlier this years there's no a standard way to do this in
include/sound/hdmi-codec.h. I think it'd be good to port this over to
this new interface before merging. And if it makes sense (and ofc
afterwards when there's time) to port over the existing
i915_component.h to hdmi-codec.h.

Cheers, Daniel

>
> Jerome Anand (8):
>   drm/i915: setup bridge for HDMI LPE audio driver
>   ALSA: add shell for Intel HDMI LPE audio driver
>   ALSA: Add support for hdmi audio driver
>   drm/i915: Add support for enabling/disabling hdmi audio interrupts
>   drm/i915: Add support for audio driver notifications
>   hdmi_audio: Improve position reporting Using a hw register to
> calculate sub-period position reports.
>   hdmi_audio: Fixup some monitor
>   hdmi_audio: continue audio playback even when display resolution
> changes
>
>  drivers/gpu/drm/i915/Makefile  |3 +
>  drivers/gpu/drm/i915/i915_drv.c|   13 +-
>  drivers/gpu/drm/i915/i915_drv.h|   22 +
>  drivers/gpu/drm/i915/i915_irq.c|   83 ++
>  drivers/gpu/drm/i915/i915_reg.h|3 +
>  drivers/gpu/drm/i915/intel_audio.c |8 +
>  drivers/gpu/drm/i915/intel_drv.h   |2 +
>  drivers/gpu/drm/i915/intel_hdmi.c  |   18 +-
>  drivers/gpu/drm/i915/intel_lpe_audio.c |  406 +++
>  include/drm/intel_lpe_audio.h  |   46 +
>  sound/Kconfig  |2 +
>  sound/Makefile |2 +-
>  sound/x86/Kconfig  |   16 +
>  sound/x86/Makefile |   10 +
>  sound/x86/intel_hdmi_audio.c   | 1929 
> 
>  sound/x86/intel_hdmi_audio.h   |  201 
>  sound/x86/intel_hdmi_audio_if.c|  551 +
>  sound/x86/intel_hdmi_lpe_audio.c   |  626 +++
>  sound/x86/intel_hdmi_lpe_audio.h   |  692 
>  19 files changed, 4629 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_lpe_audio.c
>  create mode 100644 include/drm/intel_lpe_audio.h
>  create mode 100644 sound/x86/Kconfig
>  create mode 100644 sound/x86/Makefile
>  create mode 100644 sound/x86/intel_hdmi_audio.c
>  create mode 100644 sound/x86/intel_hdmi_audio.h
>  create mode 100644 sound/x86/intel_hdmi_audio_if.c
>  create mode 100644 sound/x86/intel_hdmi_lpe_audio.c
>  create mode 100644 sound/x86/intel_hdmi_lpe_audio.h
>
> --
> 2.9.3
>
> base-commit: 2fbc239494fa3883e164cc89d35f54d22f0c9e1f
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Make sure engines are idle during GPU idling in LR mode

[Chris Wilson]

On Thu, Nov 03, 2016 at 10:57:23PM +0200, Imre Deak wrote:
> On Thu, 2016-11-03 at 18:59 +, Chris Wilson wrote:
> > On Thu, Nov 03, 2016 at 06:19:37PM +0200, Imre Deak wrote:
> > > We assume that the GPU is idle once receiving the seqno via the last
> > > request's user interrupt. In execlist mode the corresponding context
> > > completed interrupt can be delayed though and until this latter
> > > interrupt arrives we consider the request to be pending on the ELSP
> > > submit port. This can cause a problem during system suspend where this
> > > last request will be seen by the resume code as still pending. Such
> > > pending requests are normally replayed after a GPU reset, but during
> > > resume we reset both SW and HW tracking of the ring head/tail pointers,
> > > so replaying the pending request with its stale tale pointer will leave
> > > the ring in an inconsistent state. A subsequent request submission can
> > > lead then to the GPU executing from uninitialized area in the ring
> > > behind the above stale tail pointer.
> > > 
> > > Fix this by making sure any pending request on the ELSP port is
> > > completed before suspending. I used a polling wait since the completion
> > > time I measured was <1ms and since normally we only need to wait during
> > > system suspend. GPU idling during runtime suspend is scheduled with a
> > > delay (currently 50-100ms) after the retirement of the last request at
> > > which point the context completed interrupt must have arrived already.
> > > 
> > > The chance of this bug was increased by
> > > 
> > > commit 1c777c5d1dcdf8fa0223fcff35fb387b5bb9517a
> > > Author: Imre Deak 
> > > Date:   Wed Oct 12 17:46:37 2016 +0300
> > > 
> > > drm/i915/hsw: Fix GPU hang during resume from S3-devices state
> > > 
> > > but it could happen even without the explicit GPU reset, since we
> > > disable interrupts afterwards during the suspend sequence.
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Mika Kuoppala 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c  |  3 +++
> > >  drivers/gpu/drm/i915/intel_lrc.c | 12 
> > >  drivers/gpu/drm/i915/intel_lrc.h |  1 +
> > >  3 files changed, 16 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 1f995ce..5ff02b5 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -2766,6 +2766,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
> > >   if (dev_priv->gt.active_requests)
> > >   goto out_unlock;
> > >  
> > > + if (i915.enable_execlists)
> > > + intel_lr_wait_engines_idle(dev_priv);
> > 
> > Idle work handler... So runtime suspend.
> > Anyway this is not an ideal place for a stall under struct_mutex (even if
> > 16x10us, it's the principle!).
> 
> During runtime suspend this won't add any overhead since the context
> done interrupt happened already (unless there is a bug somewhere else).

Where is that guaranteed? I thought we only serialised with the pm
interrupts. Remember this happens before rpm suspend, since
gem_idle_work_handler is responsible for dropping the GPU wakelock.
 
> > Move this to before the first READ_ONCE(dev_priv->gt.active_requests);
> > so we stall before taking the lock, and skip if any new requests arrive
> > whilst waiting.
> > 
> > (Also i915.enable_execlists is forbidden. But meh)
> > 
> > static struct drm_i915_gem_request *
> > execlists_active_port(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_gem_request *request;
> > 
> > request = READ_ONCE(engine->execlist_port[1]);
> > if (request)
> > return request;
> > 
> > return READ_ONCE(engine->execlist_port[0]);
> > }
> > 
> > /* Wait for execlists to settle, but bail if any new requests come in */
> > for_each_engine(engine, dev_priv, id) {
> > struct drm_i915_gem_request *request;
> > 
> > request = execlists_active_port(engine);
> > if (!request)
> > continue;
> > 
> > if (wait_for(execlists_active_port(engine) != request, 10))
> > DRM_ERROR("Timeout waiting for %s to idle\n", engine->name);
> > }
> 
> Hm, but we still need to re-check and bail out if not idle with
> struct_mutex held, since gt.active_requests could go 0->1->0 before
> taking struct_mutex? I can rewrite things with that check added, using
> the above.

Hmm, apparently we don't care ;) If the context-done interrupt is
serialised with runtime suspend, then we don't need a wait here at all.
On the system path there are no new requests and we are just flushing
the idle worker.

But yes, for the sake of correctness do both an unlocked wait followed
by a locked wait.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix test on inputs for vma_compare()

[Chris Wilson]

On Thu, Nov 03, 2016 at 08:45:31PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix test on inputs for vma_compare()
> URL   : https://patchwork.freedesktop.org/series/14798/
> State : success
> 
> == Summary ==
> 
> Series 14798v1 drm/i915: Fix test on inputs for vma_compare()
> https://patchwork.freedesktop.org/api/1.0/series/14798/revisions/1/mbox/
> 
> Test kms_force_connector_basic:
> Subgroup prune-stale-modes:
> skip   -> PASS   (fi-snb-2600)

All quiet. No GEM_BUG_ON here...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Make sure engines are idle during GPU idling in LR mode

[Imre Deak]

On Thu, 2016-11-03 at 18:59 +, Chris Wilson wrote:
> On Thu, Nov 03, 2016 at 06:19:37PM +0200, Imre Deak wrote:
> > We assume that the GPU is idle once receiving the seqno via the last
> > request's user interrupt. In execlist mode the corresponding context
> > completed interrupt can be delayed though and until this latter
> > interrupt arrives we consider the request to be pending on the ELSP
> > submit port. This can cause a problem during system suspend where this
> > last request will be seen by the resume code as still pending. Such
> > pending requests are normally replayed after a GPU reset, but during
> > resume we reset both SW and HW tracking of the ring head/tail pointers,
> > so replaying the pending request with its stale tale pointer will leave
> > the ring in an inconsistent state. A subsequent request submission can
> > lead then to the GPU executing from uninitialized area in the ring
> > behind the above stale tail pointer.
> > 
> > Fix this by making sure any pending request on the ELSP port is
> > completed before suspending. I used a polling wait since the completion
> > time I measured was <1ms and since normally we only need to wait during
> > system suspend. GPU idling during runtime suspend is scheduled with a
> > delay (currently 50-100ms) after the retirement of the last request at
> > which point the context completed interrupt must have arrived already.
> > 
> > The chance of this bug was increased by
> > 
> > commit 1c777c5d1dcdf8fa0223fcff35fb387b5bb9517a
> > Author: Imre Deak 
> > Date:   Wed Oct 12 17:46:37 2016 +0300
> > 
> > drm/i915/hsw: Fix GPU hang during resume from S3-devices state
> > 
> > but it could happen even without the explicit GPU reset, since we
> > disable interrupts afterwards during the suspend sequence.
> > 
> > Cc: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c  |  3 +++
> >  drivers/gpu/drm/i915/intel_lrc.c | 12 
> >  drivers/gpu/drm/i915/intel_lrc.h |  1 +
> >  3 files changed, 16 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 1f995ce..5ff02b5 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2766,6 +2766,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >     if (dev_priv->gt.active_requests)
> >     goto out_unlock;
> >  
> > +   if (i915.enable_execlists)
> > +   intel_lr_wait_engines_idle(dev_priv);
> 
> Idle work handler... So runtime suspend.
> Anyway this is not an ideal place for a stall under struct_mutex (even if
> 16x10us, it's the principle!).

During runtime suspend this won't add any overhead since the context
done interrupt happened already (unless there is a bug somewhere else).

> Move this to before the first READ_ONCE(dev_priv->gt.active_requests);
> so we stall before taking the lock, and skip if any new requests arrive
> whilst waiting.
> 
> (Also i915.enable_execlists is forbidden. But meh)
> 
> static struct drm_i915_gem_request *
> execlists_active_port(struct intel_engine_cs *engine)
> {
>   struct drm_i915_gem_request *request;
> 
>   request = READ_ONCE(engine->execlist_port[1]);
>   if (request)
>   return request;
> 
>   return READ_ONCE(engine->execlist_port[0]);
> }
> 
> /* Wait for execlists to settle, but bail if any new requests come in */
> for_each_engine(engine, dev_priv, id) {
>   struct drm_i915_gem_request *request;
> 
>   request = execlists_active_port(engine);
>   if (!request)
>   continue;
> 
>   if (wait_for(execlists_active_port(engine) != request, 10))
>   DRM_ERROR("Timeout waiting for %s to idle\n", engine->name);
> }

Hm, but we still need to re-check and bail out if not idle with
struct_mutex held, since gt.active_requests could go 0->1->0 before
taking struct_mutex? I can rewrite things with that check added, using
the above.

--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix test on inputs for vma_compare()

[Patchwork]

== Series Details ==

Series: drm/i915: Fix test on inputs for vma_compare()
URL   : https://patchwork.freedesktop.org/series/14798/
State : success

== Summary ==

Series 14798v1 drm/i915: Fix test on inputs for vma_compare()
https://patchwork.freedesktop.org/api/1.0/series/14798/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
skip   -> PASS   (fi-snb-2600)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:241  pass:188  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 

3933917d03ccd442dd67d5142ed6f2988dd1ee4e drm-intel-nightly: 
2016y-11m-03d-19h-58m-54s UTC integration manifest
93f207a drm/i915: Fix test on inputs for vma_compare()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2900/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix test on inputs for vma_compare()

[Matthew Auld]

On 3 November 2016 at 20:08, Chris Wilson  wrote:
> When supplying a view to vma_compare() it is required that the supplied
> i915_address_space is the global GTT. I tested the VMA instead (which is
> the current position in the rbtree and maybe from any address space).
>
> Reported-by: Matthew Auld 
> Tested-by: Matthew Auld 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98579
> Fixes: db6c2b4151f2 ("drm/i915: Store the vma in an rbtree...")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Matthew Auld 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix test on inputs for vma_compare()

[Chris Wilson]

When supplying a view to vma_compare() it is required that the supplied
i915_address_space is the global GTT. I tested the VMA instead (which is
the current position in the rbtree and maybe from any address space).

Reported-by: Matthew Auld 
Tested-by: Matthew Auld 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98579
Fixes: db6c2b4151f2 ("drm/i915: Store the vma in an rbtree...")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 7a6a7454f321..dd6df1af25a1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3425,7 +3425,7 @@ static inline long vma_compare(struct i915_vma *vma,
   struct i915_address_space *vm,
   const struct i915_ggtt_view *view)
 {
-   GEM_BUG_ON(view && !i915_vma_is_ggtt(vma));
+   GEM_BUG_ON(view && !i915_is_ggtt(vm));
 
if (vma->vm != vm)
return vma->vm - vm;
-- 
2.10.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/12] drm/i915/guc: Cache the client mapping

[Chris Wilson]

On Thu, Nov 03, 2016 at 04:37:24PM +, Tvrtko Ursulin wrote:
> 
> On 02/11/2016 17:50, Chris Wilson wrote:
> >Use i915_gem_object_pin_map() for the guc client's lifetime to replace
> >the peristent kmap + frequent kmap_atomic with a permanent vmapping.
> >This avoids taking the obj->mm.lock mutex whilst inside irq context
> >later.
> >
> >Signed-off-by: Chris Wilson 

> Looks OK, I thought we've done this months ago. :)

:)
> Reviewed-by: Tvrtko Ursulin 

Pulled this in to close
https://bugs.freedesktop.org/show_bug.cgi?id=98571
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/12] drm/i915/scheduler: Execute requests in order of priorities

[Chris Wilson]

On Thu, Nov 03, 2016 at 04:21:25PM +, Tvrtko Ursulin wrote:
> >+static void update_priorities(struct i915_priotree *pt, int prio)
> >+{
> >+struct drm_i915_gem_request *request =
> >+container_of(pt, struct drm_i915_gem_request, priotree);
> >+struct intel_engine_cs *engine = request->engine;
> >+struct i915_dependency *dep;
> >+
> >+if (prio <= READ_ONCE(pt->priority))
> >+return;
> >+
> >+/* Recursively bump all dependent priorities to match the new request */
> >+list_for_each_entry(dep, >pre_list, pre_link)
> >+update_priorities(dep->signal, prio);
> 
> John got in trouble from recursion in his scheduler, used for the
> same thing AFAIR. Or was it the priority bumping? Either way, it
> could be imperative to avoid it.

static void update_priority(struct i915_priotree *pt, int prio)
{
struct drm_i915_gem_request *request =
container_of(pt, struct drm_i915_gem_request, priotree);
struct intel_engine_cs *engine = request->engine;

spin_lock_irq(>timeline->lock);
if (prio > pt->priority) {
pt->priority = prio;
if (!RB_EMPTY_NODE(>node)) {
rb_erase(>node, >execlist_queue);
if (insert_request(pt, >execlist_queue))
engine->execlist_first = >node;
}
}
spin_unlock_irq(>timeline->lock);
}

static void execlists_schedule(struct drm_i915_gem_request *request, int prio)
{
struct i915_dependency *dep, *p;
LIST_HEAD(dfs);

if (prio <= READ_ONCE(request->priotree.priority))
return;

/* Need BKL in order to use the temporary link inside i915_dependency */
lockdep_assert_held(>i915->drm.struct_mutex);

/* Recursively bump all dependent priorities to match the new request */
list_for_each_entry(dep, >priotree.pre_list, pre_link)
if (prio > READ_ONCE(dep->signal->priority))
list_add_tail(>dfs_link, );

list_for_each_entry(dep, , dfs_link) {
list_for_each_entry(p, >signal->pre_list, pre_link) {
GEM_BUG_ON(p == dep);
if (prio > READ_ONCE(p->signal->priority))
list_move_tail(>dfs_link, );
}
}

/* Fifo and depth-first replacement ensure our deps execute before us */
list_for_each_entry_safe_reverse(dep, p, , dfs_link) {
update_priority(dep->signal, prio);
INIT_LIST_HEAD(>dfs_link);
}
update_priority(>priotree, prio);

/* XXX Do we need to preempt to make room for us and our deps? */
}

Still ugh. I think that we don't chase beyond the priorities we need to
bump is its only saving grace.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add assert for no pending GPU requests during resume in LR mode

[Chris Wilson]

On Thu, Nov 03, 2016 at 06:19:38PM +0200, Imre Deak wrote:
> During resume we will reset the SW/HW tracking for each ring head/tail
> pointers and so are not prepared to replay any pending requests (as
> opposed to GPU reset time). Add an assert for this.

A bit belated. You could just put WARN_ON(dev_priv->gt.awake) in
i915_gem_resume() to mirror the assertions that we are idle on suspend.
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index ee4aaf1..ae46345 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -2158,6 +2158,8 @@ void intel_lr_context_resume(struct drm_i915_private 
> *dev_priv)
>   if (WARN_ON(IS_ERR(reg)))
>   continue;
>  
> + WARN_ON(!execlists_elsp_idle(engine));

I don't think this check here documents the assumption of touching the
context. What you want is this assertion in suspend.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Decode system memory bandwidth

[Paulo Zanoni]

Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> This patch adds support to decode system memory bandwidth
> which will be used for arbitrated display memory percentage
> calculation in GEN9 based system.
> 
> Changes from v1:
>  - Address comments from Paulo
>  - implement decode function for SKL/KBL also

Again, my understanding of these registers is not good so I will ask
some questions that will help me properly understand and review the
code. I may also end up asking some questions that don't make sense.
Please correct me in case any of my assumptions is wrong.

Perhaps answers to my questions could become code comments since I
suppose most of the gfx team is not super familiar with the memory
regs, and we're going to have to maintain the code.


> 
> Signed-off-by: "Kumar, Mahesh" 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 170
> 
>  drivers/gpu/drm/i915/i915_drv.h |  14 
>  drivers/gpu/drm/i915/i915_reg.h |  38 +
>  3 files changed, 222 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 89d3222..b5f601c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -979,6 +979,170 @@ static void intel_sanitize_options(struct
> drm_i915_private *dev_priv)
>   DRM_DEBUG_DRIVER("use GPU sempahores? %s\n",
> yesno(i915.semaphores));
>  }
>  
> +static inline void skl_memdev_info_fill(struct memdev_info *info,
> uint32_t val)
> +{
> + uint8_t channel_width, rank;
> +
> + info->rank_valid = true;
> + channel_width = (val >> SKL_DRAM_CHANNEL_WIDTH_SHIFT) &
> + SKL_DRAM_CHANNEL_WIDTH_MASK;

Why are we looking at the L bits instead of the S bits? What's the
difference between them?


> + if (channel_width == SKL_DRAM_WIDTH_1)
> + info->channel_width_bytes = 1;
> + else if (channel_width == SKL_DRAM_WIDTH_2)
> + info->channel_width_bytes = 2;
> + else
> + info->channel_width_bytes = 4;

This is not checking for the invalid value of 0x3. Perhaps a switch()
instead of an if() ladder would be better here.

> +
> + rank = (val >> SKL_DRAM_RANK_SHIFT) & SKL_DRAM_RANK_MASK;
> + if (rank == SKL_DRAM_RANK_SINGLE)
> + info->rank = DRAM_RANK_SINGLE;
> + else
> + info->rank = DRAM_RANK_DUAL;
> +}
> +
> +static int
> +skl_get_memdev_info(struct drm_i915_private *dev_priv)
> +{
> + uint32_t val = 0;
> + uint32_t mem_speed = 0;
> + struct memdev_info *memdev_info = _priv->memdev_info;
> +
> + val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
> + mem_speed = div_u64((uint64_t) (val & SKL_REQ_DATA_MASK) *
> + SKL_MEMORY_FREQ_MULTIPLIER, 1000);

But but but isn't it possible to have more than 2GHz in SKL? I think I
have a big SKL machine with more than 2GHz here... I'll check it later.
Also, don't we need to check FREQ_TYPE and ODD_RATIO?

Some digging suggests that maybe we need to figure out somehow if we're
using DCLK or QCLK and multiply accordingly (based on the BIOS_REQ
register instead of BIOS_DATA).

I'd really need some clarification on how all of this works.

Also, it looks like there's no need for this to be a 64bit calculation
due to the mask limit.


> +
> + if (mem_speed == 0)
> + return -EINVAL;
> +
> + memdev_info->valid = true;
> + memdev_info->mem_speed_khz = mem_speed;
> + memdev_info->num_channels  = 0;
> +
> + memdev_info->rank_valid = false;
> + val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> +
> + if (val != 0x) {
> + memdev_info->num_channels++;
> + skl_memdev_info_fill(memdev_info, val);
> + }
> +
> + val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> +
> + if (val != 0x) {
> + memdev_info->num_channels++;
> + if (!memdev_info->rank_valid)
> + skl_memdev_info_fill(memdev_info, val);
> + }

A simple iteration over the two register addresses would have saved
some code :).

Also, isn't it possible to have channels with different width/rank?
Shouldn't our code be sanity-checking this? Perhaps grab the width/rank
for each channel and compare. When the specs are unclear or don't
exist, it's probably better if our code is able to check/validate its
own assumptions.


> +
> + if (memdev_info->num_channels == 0)
> + memdev_info->valid = false;
> + return 0;
> +}
> +
> +static int
> +bxt_get_memdev_info(struct drm_i915_private *dev_priv)
> +{
> + struct memdev_info *memdev_info = _priv->memdev_info;
> + uint32_t dram_channel;
> + uint32_t mem_speed, val;
> + uint8_t num_channel, dram_type;
> + int i;
> +
> + val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0);
> + mem_speed = div_u64((uint64_t) (val & BXT_REQ_DATA_MASK) *
> + SKL_MEMORY_FREQ_MULTIPLIER, 1000);

AFAIU, there's 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Make sure engines are idle during GPU idling in LR mode

[Chris Wilson]

On Thu, Nov 03, 2016 at 06:19:37PM +0200, Imre Deak wrote:
> We assume that the GPU is idle once receiving the seqno via the last
> request's user interrupt. In execlist mode the corresponding context
> completed interrupt can be delayed though and until this latter
> interrupt arrives we consider the request to be pending on the ELSP
> submit port. This can cause a problem during system suspend where this
> last request will be seen by the resume code as still pending. Such
> pending requests are normally replayed after a GPU reset, but during
> resume we reset both SW and HW tracking of the ring head/tail pointers,
> so replaying the pending request with its stale tale pointer will leave
> the ring in an inconsistent state. A subsequent request submission can
> lead then to the GPU executing from uninitialized area in the ring
> behind the above stale tail pointer.
> 
> Fix this by making sure any pending request on the ELSP port is
> completed before suspending. I used a polling wait since the completion
> time I measured was <1ms and since normally we only need to wait during
> system suspend. GPU idling during runtime suspend is scheduled with a
> delay (currently 50-100ms) after the retirement of the last request at
> which point the context completed interrupt must have arrived already.
> 
> The chance of this bug was increased by
> 
> commit 1c777c5d1dcdf8fa0223fcff35fb387b5bb9517a
> Author: Imre Deak 
> Date:   Wed Oct 12 17:46:37 2016 +0300
> 
> drm/i915/hsw: Fix GPU hang during resume from S3-devices state
> 
> but it could happen even without the explicit GPU reset, since we
> disable interrupts afterwards during the suspend sequence.
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  |  3 +++
>  drivers/gpu/drm/i915/intel_lrc.c | 12 
>  drivers/gpu/drm/i915/intel_lrc.h |  1 +
>  3 files changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1f995ce..5ff02b5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2766,6 +2766,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
>   if (dev_priv->gt.active_requests)
>   goto out_unlock;
>  
> + if (i915.enable_execlists)
> + intel_lr_wait_engines_idle(dev_priv);

Idle work handler... So runtime suspend. Anyway this is not an
ideal place for a stall under struct_mutex (even if 16x10us, it's the
principle!).

Move this to before the first READ_ONCE(dev_priv->gt.active_requests);
so we stall before taking the lock, and skip if any new requests arrive
whilst waiting.

(Also i915.enable_execlists is forbidden. But meh)

static struct drm_i915_gem_request *
execlists_active_port(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *request;

request = READ_ONCE(engine->execlist_port[1]);
if (request)
return request;

return READ_ONCE(engine->execlist_port[0]);
}

/* Wait for execlists to settle, but bail if any new requests come in */
for_each_engine(engine, dev_priv, id) {
struct drm_i915_gem_request *request;

request = execlists_active_port(engine);
if (!request)
continue;

if (wait_for(execlists_active_port(engine) != request, 10))
DRM_ERROR("Timeout waiting for %s to idle\n", engine->name);
}

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

[Rob Clark]

On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 
> ---
>
> I moved the main bits to be the first diffs, shouldn't affect anything
> when applying the patch, but I wanted to ask:
> I don't like the hard-coded `32` the appears in both kmalloc() and
> snprintf(), what do you think? If you don't like it either, what would
> you suggest? Should I #define it?
>
> Second question is about the patch mail itself: should I send this kind
> of patch separated by module, with a note requesting them to be squashed
> when applying? It has to land as a single patch, but for review it might
> be easier if people only see the bits they each care about, as well as
> to collect ack's/r-b's.
>
> Cheers,
>   Eric
>
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  6 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  6 ++--
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  6 ++--
>  drivers/gpu/drm/drm_atomic.c|  5 ++--
>  drivers/gpu/drm/drm_crtc.c  | 21 -
>  drivers/gpu/drm/drm_fourcc.c| 17 ++-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  6 ++--
>  drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
>  drivers/gpu/drm/i915/intel_atomic_plane.c   |  6 ++--
>  drivers/gpu/drm/i915/intel_display.c| 39 
> -
>  drivers/gpu/drm/radeon/atombios_crtc.c  | 12 +---
>  include/drm/drm_fourcc.h|  2 +-
>  12 files changed, 89 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 0645c85..38216a1 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -39,16 +39,14 @@ static char printable_char(int c)
>   * drm_get_format_name - return a string for drm fourcc format
>   * @format: format to compute name of
>   *
> - * Note that the buffer used by this function is globally shared and owned by
> - * the function itself.
> - *
> - * FIXME: This isn't really multithreading safe.
> + * Note that the buffer returned by this function is owned by the caller
> + * and will need to be freed.
>   */
>  const char *drm_get_format_name(uint32_t format)
>  {
> -   static char buf[32];
> +   char *buf = kmalloc(32, GFP_KERNEL);


hmm, I guess I wasn't paying attention at the time this patch came by,
but unfortunately this makes drm_get_format_name() no longer safe in
atomic contexts :-/

We should probably either revert this or have two variants of
drm_get_format_name()?  (ie. one that is not thread safe but is good
enough for debugging)

BR,
-R

> -   snprintf(buf, sizeof(buf),
> +   snprintf(buf, 32,
>  "%c%c%c%c %s-endian (0x%08x)",
>  printable_char(format & 0xff),
>  printable_char((format >> 8) & 0xff),
> @@ -73,6 +71,8 @@ EXPORT_SYMBOL(drm_get_format_name);
>  void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
>   int *bpp)
>  {
> +   const char *format_name;
> +
> switch (format) {
> case DRM_FORMAT_C8:
> case DRM_FORMAT_RGB332:
> @@ -127,8 +127,9 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int 
> *depth,
> *bpp = 32;
> break;
> default:
> -   DRM_DEBUG_KMS("unsupported pixel format %s\n",
> - drm_get_format_name(format));
> +   format_name = drm_get_format_name(format);
> +   DRM_DEBUG_KMS("unsupported pixel format %s\n", format_name);
> +   kfree(format_name);
> *depth = 0;
> *bpp = 0;
> break;
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 7f90a39..030d22d 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -32,6 +32,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
>  int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
> -const char *drm_get_format_name(uint32_t format);
> +const char *drm_get_format_name(uint32_t format) __malloc;
>
>  #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index c1b04e9..0bf8959 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2071,6 +2071,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> +   const char *format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> @@ -2182,8 +2183,9 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc 
> *crtc,
>  

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

[David Weinehall]

On Thu, Nov 03, 2016 at 11:42:38AM -0400, Lyude wrote:
> Now that we don't run the connector reprobing from i915_drm_resume(), we
> need to make it so we don't have to wait for reprobing to finish so that
> we actually speed things up. In order to do this, we need to make sure
> that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
> while trying to acquire the mode_config lock that
> drm_kms_helper_poll_enable() needs to acquire.
> 
> The easiest way to do this is to just enable polling before hpd. This
> shouldn't break anything since at that point we have everything else we
> need for polling enabled.
> 
> As well, this should result in a rather significant improvement in how
> quickly we can resume the system.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 

Tested-by: David Weinehall 
Reviewed-by: David Weinehall 
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 532cc0f..f605dde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1595,6 +1595,8 @@ static int i915_drm_resume(struct drm_device *dev)
>  
>   intel_display_resume(dev);
>  
> + drm_kms_helper_poll_enable(dev);
> +
>   /*
>* ... but also need to make sure that hotplug processing
>* doesn't cause havoc. Like in the driver load code we don't
> @@ -1614,7 +1616,6 @@ static int i915_drm_resume(struct drm_device *dev)
>   intel_opregion_notify_adapter(dev_priv, PCI_D0);
>  
>   intel_autoenable_gt_powersave(dev_priv);
> - drm_kms_helper_poll_enable(dev);
>  
>   enable_rpm_wakeref_asserts(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[David Weinehall]

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 a lengthy one for good reason, we don't need to
> hold up the entire suspend/resume process while we wait for it to
> finish. Luckily as it turns out, we already trigger a full connector
> reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> i915_drm_resume() entirely.
> 
> This won't lead to less time spent resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 

Tested-by: David Weinehall 
Reviewed-by: David Weinehall 
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bfb2efd..532cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
>* notifications.
>* */
>   intel_hpd_init(dev_priv);
> - /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);
>  
>   intel_opregion_register(dev_priv);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 07:55:20PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 03, 2016 at 03:45:43PM -0200, Paulo Zanoni wrote:
> > Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> > > On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> > > > 
> > > > Signed-off-by: Maarten Lankhorst  > > > >
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> > > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > index faa67624e1ed..0028335fc1bb 100644
> > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct
> > > > drm_i915_private *dev_priv,
> > > >  
> > > >     mutex_lock(>lock);
> > > >  
> > > > -   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > > >     if (fbc->crtc == to_intel_crtc(crtc)) {
> > > >     fbc_crtc_present = true;
> > > >     break;
> > > > @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct
> > > > drm_i915_private *dev_priv,
> > > >      * plane. We could go for fancier schemes such as checking
> > > > the plane
> > > >      * size, but this would just affect the few platforms that
> > > > don't tie FBC
> > > >      * to pipe or plane A. */
> > > > -   for_each_plane_in_state(state, plane, plane_state, i) {
> > > > +   for_each_new_plane_in_state(state, plane, plane_state, i)
> > > > {
> > > >     struct intel_plane_state *intel_plane_state =
> > > >     to_intel_plane_state(plane_state);
> > > >  
> > > >     if (!intel_plane_state->base.visible)
> > > >     continue;
> > > 
> > > Unrelated but this thing looks somewhat bogus. FBC is tied to the
> > > primary plane only, so why do we care about the visibility of the
> > > other
> > > planes? Adding Paulo to Cc...
> > 
> > Looks like you've found a bug... Thanks! We should really be iterating
> > over primary planes only. Adding to the TODO list.
> > 
> > > 
> > > > 
> > > >  
> > > > -   for_each_crtc_in_state(state, crtc, crtc_state, j)
> > > > {
> > > > +   for_each_new_crtc_in_state(state, crtc,
> > > > crtc_state, j) {
> > > 
> > > Also, can't this inner loop be replaced with a simple
> > > crtc = plane_state->crtc ?
> > 
> > Is there a way to get the proposed crtc_state without the loop?
> 
> ...get_existing_crtc_state(plane_state->crtc);
> 
> since the plane is part of the state the crtc should be too, I think.

Well, I guess Maarten wants to change it to get_new_state() soon enough.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 03:45:43PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> > On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> > > 
> > > Signed-off-by: Maarten Lankhorst  > > >
> > > ---
> > >  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index faa67624e1ed..0028335fc1bb 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct
> > > drm_i915_private *dev_priv,
> > >  
> > >   mutex_lock(>lock);
> > >  
> > > - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > >   if (fbc->crtc == to_intel_crtc(crtc)) {
> > >   fbc_crtc_present = true;
> > >   break;
> > > @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct
> > > drm_i915_private *dev_priv,
> > >    * plane. We could go for fancier schemes such as checking
> > > the plane
> > >    * size, but this would just affect the few platforms that
> > > don't tie FBC
> > >    * to pipe or plane A. */
> > > - for_each_plane_in_state(state, plane, plane_state, i) {
> > > + for_each_new_plane_in_state(state, plane, plane_state, i)
> > > {
> > >   struct intel_plane_state *intel_plane_state =
> > >   to_intel_plane_state(plane_state);
> > >  
> > >   if (!intel_plane_state->base.visible)
> > >   continue;
> > 
> > Unrelated but this thing looks somewhat bogus. FBC is tied to the
> > primary plane only, so why do we care about the visibility of the
> > other
> > planes? Adding Paulo to Cc...
> 
> Looks like you've found a bug... Thanks! We should really be iterating
> over primary planes only. Adding to the TODO list.
> 
> > 
> > > 
> > >  
> > > - for_each_crtc_in_state(state, crtc, crtc_state, j)
> > > {
> > > + for_each_new_crtc_in_state(state, crtc,
> > > crtc_state, j) {
> > 
> > Also, can't this inner loop be replaced with a simple
> > crtc = plane_state->crtc ?
> 
> Is there a way to get the proposed crtc_state without the loop?

...get_existing_crtc_state(plane_state->crtc);

since the plane is part of the state the crtc should be too, I think.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Use new atomic iterator macros in wm code

[Paulo Zanoni]

Em Qui, 2016-11-03 às 18:49 +0200, Ville Syrjälä escreveu:
> On Mon, Oct 17, 2016 at 02:37:16PM +0200, Maarten Lankhorst wrote:
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 2df06b703e3d..163b73b493bf 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3227,7 +3227,7 @@ skl_get_total_relative_data_rate(struct
> > intel_crtc_state *intel_cstate)
> >     return 0;
> >  
> >     /* Calculate and cache data rate for each plane */
> > -   for_each_plane_in_state(state, plane, pstate, i) {
> > +   for_each_new_plane_in_state(state, plane, pstate, i) {
> 
> Looks like this patch needs a refresh due to my tardiness in
> reviewing
> it.
> 
> Also unrelated, but I recently noticed that
> skl_get_total_relative_data_rate() doesn't exclude the cursor plane
> from the calculation. I'm thinking it should. Adding some Cc:s...

It seems we're safe because skl_plane_relative_data_rate() returns 0
for cursor. But an explicitly check at the caller would probably be
much much better instead of hidden deep in the code. OTOH, Matt's plans
to exclude cursor case-handling would remove this need again.

> 
> > 
> >     id = skl_wm_plane_id(to_intel_plane(plane));
> >     intel_plane = to_intel_plane(plane);
> >  
> > @@ -3364,14 +3364,14 @@ skl_allocate_pipe_ddb(struct
> > intel_crtc_state *cstate,
> >     alloc_size -= cursor_blocks;
> >  
> >     /* 1. Allocate the mininum required blocks for each active
> > plane */
> > -   for_each_plane_in_state(state, plane, pstate, i) {
> > +   for_each_new_plane_in_state(state, plane, pstate, i) {
> >     intel_plane = to_intel_plane(plane);
> >     id = skl_wm_plane_id(intel_plane);
> >  
> >     if (intel_plane->pipe != pipe)
> >     continue;
> >  
> > -   if (!to_intel_plane_state(pstate)->base.visible) {
> > +   if (!pstate->visible) {
> >     minimum[id] = 0;
> >     y_minimum[id] = 0;
> >     continue;
> > @@ -3933,7 +3933,7 @@ pipes_modified(struct drm_atomic_state
> > *state)
> >     struct drm_crtc_state *cstate;
> >     uint32_t i, ret = 0;
> >  
> > -   for_each_crtc_in_state(state, crtc, cstate, i)
> > +   for_each_new_crtc_in_state(state, crtc, cstate, i)
> >     ret |= drm_crtc_mask(crtc);
> >  
> >     return ret;
> > @@ -4048,7 +4048,7 @@ skl_compute_wm(struct drm_atomic_state
> > *state)
> >      * since any racing commits that want to update them would
> > need to
> >      * hold _all_ CRTC state mutexes.
> >      */
> > -   for_each_crtc_in_state(state, crtc, cstate, i)
> > +   for_each_new_crtc_in_state(state, crtc, cstate, i)
> >     changed = true;
> >     if (!changed)
> >     return 0;
> > @@ -4070,7 +4070,7 @@ skl_compute_wm(struct drm_atomic_state
> > *state)
> >      * should allow skl_update_pipe_wm() to return failure in
> > cases where
> >      * no suitable watermark values can be found.
> >      */
> > -   for_each_crtc_in_state(state, crtc, cstate, i) {
> > +   for_each_new_crtc_in_state(state, crtc, cstate, i) {
> >     struct intel_crtc *intel_crtc =
> > to_intel_crtc(crtc);
> >     struct intel_crtc_state *intel_cstate =
> >     to_intel_crtc_state(cstate);
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Paulo Zanoni]

Em Qui, 2016-11-03 às 18:45 +0200, Ville Syrjälä escreveu:
> On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index faa67624e1ed..0028335fc1bb 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> >  
> >     mutex_lock(>lock);
> >  
> > -   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> >     if (fbc->crtc == to_intel_crtc(crtc)) {
> >     fbc_crtc_present = true;
> >     break;
> > @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct
> > drm_i915_private *dev_priv,
> >      * plane. We could go for fancier schemes such as checking
> > the plane
> >      * size, but this would just affect the few platforms that
> > don't tie FBC
> >      * to pipe or plane A. */
> > -   for_each_plane_in_state(state, plane, plane_state, i) {
> > +   for_each_new_plane_in_state(state, plane, plane_state, i)
> > {
> >     struct intel_plane_state *intel_plane_state =
> >     to_intel_plane_state(plane_state);
> >  
> >     if (!intel_plane_state->base.visible)
> >     continue;
> 
> Unrelated but this thing looks somewhat bogus. FBC is tied to the
> primary plane only, so why do we care about the visibility of the
> other
> planes? Adding Paulo to Cc...

Looks like you've found a bug... Thanks! We should really be iterating
over primary planes only. Adding to the TODO list.

> 
> > 
> >  
> > -   for_each_crtc_in_state(state, crtc, crtc_state, j)
> > {
> > +   for_each_new_crtc_in_state(state, crtc,
> > crtc_state, j) {
> 
> Also, can't this inner loop be replaced with a simple
> crtc = plane_state->crtc ?

Is there a way to get the proposed crtc_state without the loop?


> 
> > 
> >     struct intel_crtc_state *intel_crtc_state
> > =
> >     to_intel_crtc_state(crtc_state);
> >  
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/12] drm/i915/scheduler: Execute requests in order of priorities

[Chris Wilson]

On Thu, Nov 03, 2016 at 04:21:25PM +, Tvrtko Ursulin wrote:
> >+rb = rb_next(rb);
> >+rb_erase(>priotree.node, >execlist_queue);
> >+RB_CLEAR_NODE(>priotree.node);
> >+cursor->priotree.priority = INT_MAX;
> >+
> >+/* We keep the previous context alive until we retire the
> >+ * following request. This ensures that any the context object
> >+ * is still pinned for any residual writes the HW makes into
> >+ * it on the context switch into the next object following the
> >+ * breadcrumb. Otherwise, we may retire the context too early.
> >+ */
> >+cursor->previous_context = engine->last_context;
> >+engine->last_context = cursor->ctx;
> >+
> 
> Will we will need a knob to control the amount of context merging?
> Until preemption that is, similar to GuC queue depth "nerfing" from
> the other patch.

Right, timeslicing + preemption is the perhaps the best answer here. A
knob here would be one of those policy decisions that we want to avoid
:) Not quite sure how we would go about autotuning it. A GL workload
looks quite different to a VK workload and quite different again to a CL
workload. One can only imagine the horrors on the transcode side :)

Making those decisions is the real heart of a scheduler.

This code should be more like:

while (req = scheduler.next_request()) {
if (!is_compatible(port, req)) {
if (port++)
break;
}

finish_request(req);
scheduler.remove_request(req);

port = req;
}

Given that at least this block of code is duplicated for the guc, maybe
it is worth starting. I was trying to avoid doing that because in my
mind it is the preemption that is the complex part and should drive the
next steps.

> >+static void update_priorities(struct i915_priotree *pt, int prio)
> >+{
> >+struct drm_i915_gem_request *request =
> >+container_of(pt, struct drm_i915_gem_request, priotree);
> >+struct intel_engine_cs *engine = request->engine;
> >+struct i915_dependency *dep;
> >+
> >+if (prio <= READ_ONCE(pt->priority))
> >+return;
> >+
> >+/* Recursively bump all dependent priorities to match the new request */
> >+list_for_each_entry(dep, >pre_list, pre_link)
> >+update_priorities(dep->signal, prio);
> 
> John got in trouble from recursion in his scheduler, used for the
> same thing AFAIR. Or was it the priority bumping? Either way, it
> could be imperative to avoid it.

Yup. I haven't thrown a 100,000 requests at it for this very reason.

Hmm, if I put an additional struct list_head into i915_dependency, we
can build a search list using it (praise be to the BKL).
 
> >+/* Fifo and depth-first replacement ensure our deps execute before us */
> >+spin_lock_irq(>timeline->lock);
> >+pt->priority = prio;
> >+if (!RB_EMPTY_NODE(>node)) {
> >+rb_erase(>node, >execlist_queue);
> >+if (insert_request(pt, >execlist_queue))
> >+engine->execlist_first = >node;
> >+}
> >+spin_unlock_irq(>timeline->lock);
> >+}
> >+
> >+static void execlists_schedule(struct drm_i915_gem_request *request, int 
> >prio)
> >+{
> >+/* Make sure that our entire dependency chain shares our prio */
> >+update_priorities(>priotree, prio);
> >+
> >+/* XXX Do we need to preempt to make room for us and our deps? */
> >+}
> 
> Hm, why isn't scheduling backend agnostic? Makes it much simpler to
> do the first implementation like this?

The scheduling is? The scheduling is just the policy. But we do need
entry points to call into the scheduler, such as change in the request
tree (here), completion of a request (context-switch interrupt) or
completion of a time slice. engine->schedule() is not the best name,
perhaps schedule_request(). Using engine is mostly a placeholder (a
convenient place to store a vfunc), but I do think we will end up with
different interactions with the scheduler based on the backend (in
particular feeding the GuC with dependency information). So, yes, this
is the easy route that should evolve as the need changes, and just
pencil the different callbacks as entry points where the backend and
scheduler should collude.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Liviu Dudau]

On Tue, Oct 25, 2016 at 11:20:44AM +1100, Stephen Rothwell wrote:
> Hi Liviu,

Hi Stephen,

> 
> Today's linux-next merge of the mali-dp tree got a conflict in:
> 
>   drivers/gpu/drm/arm/malidp_planes.c
> 
> between commit:
> 
>   ea0e1ce20f73 ("drm/arm: Use per-plane rotation property")
> 
> from the drm-misc tree and commit:
> 
>   9ebb89762c30 ("drm: mali-dp: Refactor plane initialisation")
> 
> from the mali-dp tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Sorry for delay in answering, I was on holiday.

I have revamped the mali-dp tree and rebased it on the newer
version of drm-next (which includes the drm-misc change) and pushed the
updated patch in my tree.

Best regards,
Liviu


> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/arm/malidp_planes.c
> index abaca03b9d36,9020c0d8399c..
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@@ -254,23 -284,33 +284,30 @@@ int malidp_de_planes_init(struct drm_de
>   if (ret < 0)
>   goto cleanup;
>   
> + drm_plane_helper_add(>base,
> +  _de_plane_helper_funcs);
> + plane->hwdev = malidp->dev;
> + plane->layer = >layers[i];
> + 
> + /* Skip the features which the SMART layer doesn't have */
> + if (id == DE_SMART)
> + continue;
> + 
>  -if (!drm->mode_config.rotation_property) {
>  +/* SMART layer can't be rotated */
>  +if (id != DE_SMART) {
>   unsigned long flags = DRM_ROTATE_0 |
> DRM_ROTATE_90 |
> DRM_ROTATE_180 |
> DRM_ROTATE_270 |
> DRM_REFLECT_X |
> DRM_REFLECT_Y;
>  -drm->mode_config.rotation_property =
>  -drm_mode_create_rotation_property(drm, flags);
>  +drm_plane_create_rotation_property(>base,
>  +   DRM_ROTATE_0,
>  +   flags);
>   }
>   
> - drm_plane_helper_add(>base,
> -  _de_plane_helper_funcs);
> - plane->hwdev = malidp->dev;
> - plane->layer = >layers[i];
>  -if (drm->mode_config.rotation_property)
>  -drm_object_attach_property(>base.base,
>  -   
> drm->mode_config.rotation_property,
>  -   DRM_ROTATE_0);
>  -
> + malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT,
> + plane->layer->base + MALIDP_LAYER_COMPOSE);
>   }
>   
>   kfree(formats);
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 19/19] drm/atomic: Rename atomic oldnew iterator

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:18PM +0200, Maarten Lankhorst wrote:
> With the old users of for_each_obj_in_state gone, we can rename
> for_each_oldnew_obj_in_state back to that name. It's slightly less
> ugly.
> 
> Signed-off-by: Maarten Lankhorst 

Simple sed/coccinelle job I presume. Assuming the tool works
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 34 
> ++---
>  drivers/gpu/drm/drm_blend.c |  4 ++--
>  drivers/gpu/drm/i915/intel_display.c| 16 +++---
>  drivers/gpu/drm/imx/imx-drm-core.c  |  2 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 +-
>  drivers/gpu/drm/msm/msm_atomic.c|  2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
>  drivers/gpu/drm/vc4/vc4_kms.c   |  2 +-
>  include/drm/drm_atomic.h| 30 +++--
>  9 files changed, 35 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c8aba493fc17..8fb955181641 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -241,7 +241,7 @@ steal_encoder(struct drm_atomic_state *state,
>   struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i;
>  
> - for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
> + for_each_connector_in_state(state, connector, old_connector_state, 
> new_connector_state, i) {
>   struct drm_crtc *encoder_crtc;
>  
>   if (new_connector_state->best_encoder != encoder)
> @@ -482,7 +482,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i, ret;
>  
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
>   if (!drm_mode_equal(_crtc_state->mode, 
> _crtc_state->mode)) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
>crtc->base.id, crtc->name);
> @@ -510,7 +510,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> - for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
> + for_each_connector_in_state(state, connector, old_connector_state, 
> new_connector_state, i) {
>   /*
>* This only sets crtc->connectors_changed for routing changes,
>* drivers must set crtc->connectors_changed themselves when
> @@ -529,7 +529,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>* configuration. This must be done before calling mode_fixup in case a
>* crtc only changed its mode but has the same set of connectors.
>*/
> - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
>   bool has_connectors =
>   !!new_crtc_state->connector_mask;
>  
> @@ -685,7 +685,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   int i;
>  
> - for_each_oldnew_connector_in_state(old_state, connector, 
> old_conn_state, new_conn_state, i) {
> + for_each_connector_in_state(old_state, connector, old_conn_state, 
> new_conn_state, i) {
>   const struct drm_encoder_helper_funcs *funcs;
>   struct drm_encoder *encoder;
>  
> @@ -733,7 +733,7 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   drm_bridge_post_disable(encoder->bridge);
>   }
>  
> - for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + for_each_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, 
> i) {
>   const struct drm_crtc_helper_funcs *funcs;
>  
>   /* Shut down everything that needs a full modeset. */
> @@ -785,7 +785,7 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
> drm_device *dev,
>   int i;
>  
>   /* clear out existing links and update dpms */
> - for_each_oldnew_connector_in_state(old_state, connector, 
> old_conn_state, new_conn_state, i) {
> + for_each_connector_in_state(old_state, connector, old_conn_state, 
> new_conn_state, i) {
>   if (connector->encoder) {
>   WARN_ON(!connector->encoder->crtc);
>  
> @@ -1074,7 +1074,7 @@ bool drm_atomic_helper_framebuffer_changed(struct 
> drm_device *dev,
>   struct drm_plane_state *old_plane_state, *new_plane_state;
>   int 

Re: [Intel-gfx] [PATCH 15/19] drm/i915: Use new atomic iterator macros in ddi

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:14PM +0200, Maarten Lankhorst wrote:
> Also make the function static, it's only used inside intel_ddi.c
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
>  drivers/gpu/drm/i915/intel_drv.h | 2 --
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 15d47c87def6..0e79c84e14e0 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -740,7 +740,7 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
>   return ret;
>  }
>  
> -struct intel_encoder *
> +static struct intel_encoder *
>  intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> @@ -753,7 +753,7 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
> *crtc_state)
>  
>   state = crtc_state->base.state;
>  
> - for_each_connector_in_state(state, connector, connector_state, i) {
> + for_each_new_connector_in_state(state, connector, connector_state, i) {
>   if (connector_state->crtc != crtc_state->base.crtc)
>   continue;

Reviewed-by: Ville Syrjälä 

>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 8fd16adf069b..588d8af68043 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1156,8 +1156,6 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
> *intel_dp);
>  bool intel_ddi_connector_get_hw_state(struct intel_connector 
> *intel_connector);
>  void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config);
> -struct intel_encoder *
> -intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);
>  
>  void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
>  void intel_ddi_clock_get(struct intel_encoder *encoder,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 18/19] drm/i915: Use new atomic iterator macros in display code

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:17PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 156 
> ++-
>  1 file changed, 80 insertions(+), 76 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3bd3f6a93c12..d310abace86a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3510,7 +3510,12 @@ __intel_display_resume(struct drm_device *dev,
>   if (!state)
>   return 0;
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + /*
> +  * We've duplicated the state, pointers to the old state are invalid.
> +  *
> +  * Don't attempt to use the old state until we commit the duplicated 
> state.
> +  */
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   /*
>* Force recalculation even if we restore
>* current state. With fast modeset this may not result
> @@ -5078,13 +5083,12 @@ static void intel_post_plane_update(struct 
> intel_crtc_state *old_crtc_state)
>   }
>  }
>  
> -static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
> +static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
> +struct intel_crtc_state *pipe_config)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_crtc_state *pipe_config =
> - to_intel_crtc_state(crtc->base.state);
>   struct drm_atomic_state *old_state = old_crtc_state->base.state;
>   struct drm_plane *primary = crtc->base.primary;
>   struct drm_plane_state *old_pri_state =
> @@ -5186,12 +5190,11 @@ static void intel_encoders_pre_pll_enable(struct 
> drm_crtc *crtc,
> struct intel_crtc_state *crtc_state,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_connector_state *old_conn_state;
> + struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct drm_connector_state *conn_state = conn->state;
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(conn_state->best_encoder);
>  
> @@ -5207,12 +5210,11 @@ static void intel_encoders_pre_enable(struct drm_crtc 
> *crtc,
> struct intel_crtc_state *crtc_state,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_connector_state *old_conn_state;
> + struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct drm_connector_state *conn_state = conn->state;
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(conn_state->best_encoder);
>  
> @@ -5228,12 +5230,11 @@ static void intel_encoders_enable(struct drm_crtc 
> *crtc,
> struct intel_crtc_state *crtc_state,
> struct drm_atomic_state *old_state)
>  {
> - struct drm_connector_state *old_conn_state;
> + struct drm_connector_state *conn_state;
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct drm_connector_state *conn_state = conn->state;
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(conn_state->best_encoder);
>  
> @@ -5253,7 +5254,7 @@ static void intel_encoders_disable(struct drm_crtc 
> *crtc,
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> + for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(old_conn_state->best_encoder);
>  
> @@ -5273,7 +5274,7 @@ static void intel_encoders_post_disable(struct drm_crtc 
> *crtc,
>   struct drm_connector *conn;
>   int i;
>  
> - for_each_connector_in_state(old_state, conn, old_conn_state, i) {
> + for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
>   struct intel_encoder *encoder =
>   to_intel_encoder(old_conn_state->best_encoder);
>  
> @@ -5293,7 +5294,7 

Re: [Intel-gfx] [PATCH 07/12] drm/i915/scheduler: Boost priorities for flips

[Chris Wilson]

On Thu, Nov 03, 2016 at 04:29:52PM +, Tvrtko Ursulin wrote:
> 
> On 02/11/2016 17:50, Chris Wilson wrote:
> >Boost the priority of any rendering required to show the next pageflip
> >as we want to avoid missing the vblank by being delayed by invisible
> >workload. We prioritise avoiding jank and jitter in the GUI over
> >starving background tasks.
> >
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/i915_drv.h  |  5 
> > drivers/gpu/drm/i915/i915_gem.c  | 50 
> > 
> > drivers/gpu/drm/i915/intel_display.c |  2 ++
> > 3 files changed, 57 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 61fee0b0c302..738ec44fe6af 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -3416,6 +3416,11 @@ int i915_gem_object_wait(struct drm_i915_gem_object 
> >*obj,
> >  unsigned int flags,
> >  long timeout,
> >  struct intel_rps_client *rps);
> >+int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
> >+  unsigned int flags,
> >+  int priority);
> >+#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
> >+
> > int __must_check
> > i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
> >   bool write);
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 4697848ecfd9..4287c51fb461 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -433,6 +433,56 @@ i915_gem_object_wait_reservation(struct 
> >reservation_object *resv,
> > return timeout;
> > }
> >
> >+static void fence_set_priority(struct dma_fence *fence, int prio)
> >+{
> >+struct drm_i915_gem_request *rq;
> >+struct intel_engine_cs *engine;
> >+
> >+if (!dma_fence_is_i915(fence))
> >+return;
> >+
> >+rq = to_request(fence);
> >+engine = rq->engine;
> >+if (!engine->schedule)
> >+return;
> >+
> >+engine->schedule(rq, prio);
> 
> This will be inefficient with reservation objects containing
> multiple i915 fences.

We recursively walk a list of lists, inefficiency is its middle name!

> Instead you could update just a single priority and then rebalance
> the tree at the end.
> 
> Not sure how much work that would be. Perhaps it can be improved
> later on. Or we don't expect this scenario to occur here?

I don't think it will be so bad as to be noticeable. The principle being
that much of the dependency tree of the multiple fences are likely the
same and so we end up completing the walk much earlier. What is more
worrying is that we can get non-i915 fences and not bump the i915
dependencies beneath. The most likely of these is fence-array.
fence-array at least we can extend fence_set_priority (but nouveau-i915
interdependencies will be left behind).

Anyway I don't think calling engine->schedule() on each request is as
bad the ->schedule() implementation itself.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:15PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index faa67624e1ed..0028335fc1bb 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>  
>   mutex_lock(>lock);
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (fbc->crtc == to_intel_crtc(crtc)) {
>   fbc_crtc_present = true;
>   break;
> @@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>* plane. We could go for fancier schemes such as checking the plane
>* size, but this would just affect the few platforms that don't tie FBC
>* to pipe or plane A. */
> - for_each_plane_in_state(state, plane, plane_state, i) {
> + for_each_new_plane_in_state(state, plane, plane_state, i) {
>   struct intel_plane_state *intel_plane_state =
>   to_intel_plane_state(plane_state);
>  
>   if (!intel_plane_state->base.visible)
>   continue;

Unrelated but this thing looks somewhat bogus. FBC is tied to the
primary plane only, so why do we care about the visibility of the other
planes? Adding Paulo to Cc...

>  
> - for_each_crtc_in_state(state, crtc, crtc_state, j) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, j) {

Also, can't this inner loop be replaced with a simple
crtc = plane_state->crtc ?

>   struct intel_crtc_state *intel_crtc_state =
>   to_intel_crtc_state(crtc_state);
>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Make sure engines are idle during GPU idling in LR mode

[Tvrtko Ursulin]

On 03/11/2016 16:19, Imre Deak wrote:

We assume that the GPU is idle once receiving the seqno via the last
request's user interrupt. In execlist mode the corresponding context
completed interrupt can be delayed though and until this latter
interrupt arrives we consider the request to be pending on the ELSP
submit port. This can cause a problem during system suspend where this
last request will be seen by the resume code as still pending. Such
pending requests are normally replayed after a GPU reset, but during
resume we reset both SW and HW tracking of the ring head/tail pointers,
so replaying the pending request with its stale tale pointer will leave
the ring in an inconsistent state. A subsequent request submission can
lead then to the GPU executing from uninitialized area in the ring
behind the above stale tail pointer.

Fix this by making sure any pending request on the ELSP port is
completed before suspending. I used a polling wait since the completion
time I measured was <1ms and since normally we only need to wait during
system suspend. GPU idling during runtime suspend is scheduled with a
delay (currently 50-100ms) after the retirement of the last request at
which point the context completed interrupt must have arrived already.

The chance of this bug was increased by

commit 1c777c5d1dcdf8fa0223fcff35fb387b5bb9517a
Author: Imre Deak 
Date:   Wed Oct 12 17:46:37 2016 +0300

drm/i915/hsw: Fix GPU hang during resume from S3-devices state

but it could happen even without the explicit GPU reset, since we
disable interrupts afterwards during the suspend sequence.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem.c  |  3 +++
 drivers/gpu/drm/i915/intel_lrc.c | 12 
 drivers/gpu/drm/i915/intel_lrc.h |  1 +
 3 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1f995ce..5ff02b5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2766,6 +2766,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (dev_priv->gt.active_requests)
goto out_unlock;

+   if (i915.enable_execlists)
+   intel_lr_wait_engines_idle(dev_priv);
+
for_each_engine(engine, dev_priv, id)
i915_gem_batch_pool_fini(>batch_pool);

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fa3012c..ee4aaf1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -522,6 +522,18 @@ static bool execlists_elsp_idle(struct intel_engine_cs 
*engine)
return !engine->execlist_port[0].request;
 }

+void intel_lr_wait_engines_idle(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, dev_priv, id) {
+   if (wait_for(execlists_elsp_idle(engine), 10))
+   DRM_ERROR("Timeout waiting for engine %s to idle\n",
+ engine->name);


Just noticed engine names are currently like "render ring",etc, so you 
can drop the 'engine' from the message.



+   }
+}
+
 static bool execlists_elsp_ready(struct intel_engine_cs *engine)
 {
int port;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 4fed816..bf3775e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -87,6 +87,7 @@ void intel_lr_context_unpin(struct i915_gem_context *ctx,

 struct drm_i915_private;

+void intel_lr_wait_engines_idle(struct drm_i915_private *dev_priv);
 void intel_lr_context_resume(struct drm_i915_private *dev_priv);
 uint64_t intel_lr_context_descriptor(struct i915_gem_context *ctx,
 struct intel_engine_cs *engine);



Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Use new atomic iterator macros in wm code

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:16PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 2df06b703e3d..163b73b493bf 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3227,7 +3227,7 @@ skl_get_total_relative_data_rate(struct 
> intel_crtc_state *intel_cstate)
>   return 0;
>  
>   /* Calculate and cache data rate for each plane */
> - for_each_plane_in_state(state, plane, pstate, i) {
> + for_each_new_plane_in_state(state, plane, pstate, i) {

Looks like this patch needs a refresh due to my tardiness in reviewing
it.

Also unrelated, but I recently noticed that
skl_get_total_relative_data_rate() doesn't exclude the cursor plane
from the calculation. I'm thinking it should. Adding some Cc:s...

>   id = skl_wm_plane_id(to_intel_plane(plane));
>   intel_plane = to_intel_plane(plane);
>  
> @@ -3364,14 +3364,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   alloc_size -= cursor_blocks;
>  
>   /* 1. Allocate the mininum required blocks for each active plane */
> - for_each_plane_in_state(state, plane, pstate, i) {
> + for_each_new_plane_in_state(state, plane, pstate, i) {
>   intel_plane = to_intel_plane(plane);
>   id = skl_wm_plane_id(intel_plane);
>  
>   if (intel_plane->pipe != pipe)
>   continue;
>  
> - if (!to_intel_plane_state(pstate)->base.visible) {
> + if (!pstate->visible) {
>   minimum[id] = 0;
>   y_minimum[id] = 0;
>   continue;
> @@ -3933,7 +3933,7 @@ pipes_modified(struct drm_atomic_state *state)
>   struct drm_crtc_state *cstate;
>   uint32_t i, ret = 0;
>  
> - for_each_crtc_in_state(state, crtc, cstate, i)
> + for_each_new_crtc_in_state(state, crtc, cstate, i)
>   ret |= drm_crtc_mask(crtc);
>  
>   return ret;
> @@ -4048,7 +4048,7 @@ skl_compute_wm(struct drm_atomic_state *state)
>* since any racing commits that want to update them would need to
>* hold _all_ CRTC state mutexes.
>*/
> - for_each_crtc_in_state(state, crtc, cstate, i)
> + for_each_new_crtc_in_state(state, crtc, cstate, i)
>   changed = true;
>   if (!changed)
>   return 0;
> @@ -4070,7 +4070,7 @@ skl_compute_wm(struct drm_atomic_state *state)
>* should allow skl_update_pipe_wm() to return failure in cases where
>* no suitable watermark values can be found.
>*/
> - for_each_crtc_in_state(state, crtc, cstate, i) {
> + for_each_new_crtc_in_state(state, crtc, cstate, i) {
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_crtc_state *intel_cstate =
>   to_intel_crtc_state(cstate);
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/19] drm/msm: Use new atomic iterator macros

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:11PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  4 ++--
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  6 +++---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  3 ++-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  4 ++--
>  drivers/gpu/drm/msm/msm_atomic.c  | 16 
>  5 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index 571a91ee9607..d18d0a0e0a35 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -113,7 +113,7 @@ static void mdp4_prepare_commit(struct msm_kms *kms, 
> struct drm_atomic_state *st
>   mdp4_enable(mdp4_kms);
>  
>   /* see 119ecb7fd */
> - for_each_crtc_in_state(state, crtc, crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
>   drm_crtc_vblank_get(crtc);
>  }
>  
> @@ -125,7 +125,7 @@ static void mdp4_complete_commit(struct msm_kms *kms, 
> struct drm_atomic_state *s
>   struct drm_crtc_state *crtc_state;
>  
>   /* see 119ecb7fd */
> - for_each_crtc_in_state(state, crtc, crtc_state, i)
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
>   drm_crtc_vblank_put(crtc);

post-swap, but crtc_state not used in either. So lgtm.

I wonder if you should go all in and try to rename all the foo_state variables
as new_foo_state and old_foo_state to make sure you didn't miss any uses which
might not agree with your new choice if iterator macro? Eg. if in this
case crtc_state was actually used but you failed notice it you would have
just broken something by using the _new_ iterator.

>  
>   mdp4_disable(mdp4_kms);
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index ed7143d35b25..7cfeb0455039 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -82,10 +82,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, 
> struct drm_atomic_state *s
>   int i;
>   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
>   struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *old_state, *new_state;
>  
> - for_each_plane_in_state(state, plane, plane_state, i)
> - mdp5_plane_complete_commit(plane, plane_state);
> + for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i)
> + mdp5_plane_complete_commit(plane, old_state, new_state);
>  
>   mdp5_disable(mdp5_kms);
>  }
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> index 03738927be10..90e80619fc54 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
> @@ -198,7 +198,8 @@ void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
>  uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
>  void mdp5_plane_complete_flip(struct drm_plane *plane);
>  void mdp5_plane_complete_commit(struct drm_plane *plane,
> - struct drm_plane_state *state);
> + struct drm_plane_state *old_state,
> + struct drm_plane_state *new_state);
>  enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
>  struct drm_plane *mdp5_plane_init(struct drm_device *dev,
>   enum mdp5_pipe pipe, bool private_plane,
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 951c002b05df..19c44b968f4e 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -859,13 +859,13 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
>  
>  /* called after vsync in thread context */
>  void mdp5_plane_complete_commit(struct drm_plane *plane,
> - struct drm_plane_state *state)
> + struct drm_plane_state *old_state, struct drm_plane_state *new_state)
>  {
>   struct mdp5_kms *mdp5_kms = get_kms(plane);
>   struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
>   enum mdp5_pipe pipe = mdp5_plane->pipe;
>  
> - if (!plane_enabled(plane->state) && mdp5_kms->smp) {
> + if (!plane_enabled(new_state) && mdp5_kms->smp) {
>   DBG("%s: free SMP", mdp5_plane->name);
>   mdp5_smp_release(mdp5_kms->smp, pipe);
>   }

Doesn't look like this guy actually needs the old state. Not sure why it
was getting passed in. The replacement for plane->state looks correct
nonetheless.

> diff --git a/drivers/gpu/drm/msm/msm_atomic.c 
> b/drivers/gpu/drm/msm/msm_atomic.c
> index db193f835298..333c379e6561 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -89,8 +89,8 @@ static void msm_atomic_wait_for_commit_done(struct 
> drm_device *dev,
>   struct msm_kms *kms = 

Re: [Intel-gfx] [PATCH i-g-t 3/4 v5] tests/drv_module_reload: Convert sh script to C version.

[Jani Nikula]

On Thu, 03 Nov 2016, Marius Vlad  wrote:
> v5:
> - reworked gem_info to gem_sanitychecks (Chris Wilson)
> - remove subgroups/subtests for gem_exec_store and gem_sanitycheck
> (Chris Wilson)
>
> v4:
> - adjust test to make use of lib/igt_kmod
> - replaced SW_FINISH with SET_CACHEING (Chris Wilson)
>
> v3:
> - fix passing boolean value as flags to igt_kmod_unload().
>
> v2:
> - embedded gem_alive and gem_exec_store into test (Chris Wilson)
> - int main() to igt_main (Chris Wilson)
> - moved tests/gem_alive -> tools/gem_info (Chris Wilson)
> - added to intel-ci/fast-feedback.testlist (Petri Latvala)
> - added hda_dynamic_debug() (Petri Latvala)
> - renamed from tests/drv_module_reload_basic to tests/drv_module_reload
> (all subtests are basic and have been added to fast-feedback.testlist)
>
> Signed-off-by: Marius Vlad 

I'd like the merging of this patch be postponed until we have confidence
that the snd_hda_intel module reload works in CI. It has been failing
sporadically, so seeing just a couple of passing rounds after the latest
fixes is not enough.

BR,
Jani.


> ---
>  tests/Makefile.am |   1 -
>  tests/Makefile.sources|   2 +-
>  tests/drv_module_reload.c | 332 
> ++
>  tests/drv_module_reload_basic | 111 
>  tests/gem_alive.c |  35 
>  tests/intel-ci/fast-feedback.testlist |   4 +-
>  tools/Makefile.sources|   1 +
>  tools/intel_gem_info.c|  35 
>  8 files changed, 372 insertions(+), 149 deletions(-)
>  create mode 100644 tests/drv_module_reload.c
>  delete mode 100755 tests/drv_module_reload_basic
>  delete mode 100644 tests/gem_alive.c
>  create mode 100644 tools/intel_gem_info.c
>
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index a408126..14a41ae 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -26,7 +26,6 @@ noinst_PROGRAMS = \
>   $(NULL)
>  
>  pkglibexec_PROGRAMS = \
> - gem_alive \
>   gem_stress \
>   $(TESTS_progs) \
>   $(TESTS_progs_M) \
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 6d081c3..b1511c6 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -211,6 +211,7 @@ TESTS_progs = \
>   kms_pwrite_crc \
>   kms_sink_crc_basic \
>   prime_udl \
> + drv_module_reload \
>   $(NULL)
>  
>  # IMPORTANT: The ZZ_ tests need to be run last!
> @@ -221,7 +222,6 @@ TESTS_scripts_M = \
>  TESTS_scripts = \
>   debugfs_emon_crash \
>   drv_debugfs_reader \
> - drv_module_reload_basic \
>   kms_sysfs_edid_timing \
>   sysfs_l3_parity \
>   test_rte_check \
> diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
> new file mode 100644
> index 000..31ec2ec
> --- /dev/null
> +++ b/tests/drv_module_reload.c
> @@ -0,0 +1,332 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +#include "igt.h"
> +#include "igt_debugfs.h"
> +#include "igt_aux.h"
> +#include "igt_kmod.h"
> +#include "igt_sysfs.h"
> +#include "igt_core.h"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
> +#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> +
> +#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> +
> +static void store_dword(int fd, unsigned ring)
> +{
> + const int gen = intel_gen(intel_get_drm_devid(fd));
> + struct drm_i915_gem_exec_object2 obj[2];
> + struct drm_i915_gem_relocation_entry reloc;
> + struct drm_i915_gem_execbuffer2 execbuf;
> + uint32_t batch[16];
> + int i;
> +
> + if (!gem_has_ring(fd, ring))
> + 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Make sure engines are idle during GPU idling in LR mode

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Make sure engines are idle during 
GPU idling in LR mode
URL   : https://patchwork.freedesktop.org/series/14789/
State : warning

== Summary ==

Series 14789v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14789/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:241  pass:188  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 

8a1c897ee1d0d93b8e70991becb6f9f8488dba1b drm-intel-nightly: 
2016y-11m-03d-13h-53m-22s UTC integration manifest
48b2b9f drm/i915: Add assert for no pending GPU requests during resume in LR 
mode
f38c913 drm/i915: Make sure engines are idle during GPU idling in LR mode

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2899/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[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:
> > > > 
> > > > 
> > > > 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 a lengthy one for good reason, we don't need
> > > > > to
> > > > > hold up the entire suspend/resume process while we wait for it to
> > > > > finish. Luckily as it turns out, we already trigger a full connector
> > > > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing
> > > > > in
> > > > > i915_drm_resume() entirely.
> > > > > 
> > > > > This won't lead to less time spent resuming just yet since now the
> > > > > bottleneck will be waiting for the mode_config lock in
> > > > > drm_kms_helper_poll_enable(), since that will be held as long as
> > > > > i915_hpd_poll_init_work() is reprobing all of the connectors. But
> > > > > we'll
> > > > > address that in the next patch.
> > > > > 
> > > > > Signed-off-by: Lyude 
> > > > > Cc: David Weinehall 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > > index bfb2efd..532cc0f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device
> > > > > *dev)
> > > > >    * notifications.
> > > > >    * */
> > > > >   intel_hpd_init(dev_priv);
> > > > > - /* Config may have changed between suspend and resume */
> > > > > - drm_helper_hpd_irq_event(dev);
> > > > 
> > > > The comment is still apt. This code is known to be broken since it
> > > > doesn't detect a change in monitors (e.g. a change in external
> > > > connectors
> > > > from docking) between suspend and resend. We still have to send the
> > > > uevent.
> > > > 
> > > > +   drm_kms_helper_hotplug_event(dev);
> > > 
> > > I might not have explained myself very well. The way things should look
> > > with
> > > this patch is like this:
> > > 
> > > i915_drm_resume()
> > >  -> intel_hpd_init()
> > >    -> sets dev_priv->hotplug.poll_enabled to true
> > Whoops, s/true/false/
> > 
> > > 
> > >    -> schedules dev_priv->hotplug.poll_init_work
> > >  -> continue resume…
> > > 
> > > at the same time:
> > > 
> > > i915_hpd_poll_init_work() gets scheduled and starts
> > >  -> since dev_priv->hotplug.poll_enabled == false,
> > > drm_helper_hpd_irq_event()
> > > is called
> > >   -> drm_helper_hpd_irq_event() reprobes connectors
> > >    -> if anything changed, drm_kms_helper_hotplug_event() gets called.
> 
> drm_helper_hpd_irq_event() does not detect a change in monitors, for
> example, so there is no uevent in that case.

I still think you're mistaken (and I wouldn't blame you,
drm_helper_hpd_irq_event() has a rather misleading name). Contents
of drm_helper_hpd_irq_event()

bool drm_helper_hpd_irq_event(struct drm_device *dev)
{
struct drm_connector *connector;
enum drm_connector_status old_status;
bool changed = false;

if (!dev->mode_config.poll_enabled)
return false;

mutex_lock(>mode_config.mutex);
drm_for_each_connector(connector, dev) {

/* Only handle HPD capable connectors. */
if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;

old_status = connector->status;

connector->status = connector->funcs->detect(connector, false);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s\n",
  connector->base.id,
  connector->name,
  drm_get_connector_status_name(old_status),
  drm_get_connector_status_name(connector->status));
if (old_status != connector->status)
changed = true;
}

mutex_unlock(>mode_config.mutex);

if (changed)
drm_kms_helper_hotplug_event(dev);

return changed;
}

Unless I made a mistake somewhere down the line of writing these: poll_enabled
will be set to true (due to the change done in the second patch where we move
the call for enabling polling up so that it gets called before
intel_hpd_init()), which causes it to go through all the connectors and call
connector->funcs->detect() (which will be intel_dp_detect(),
intel_hdmi_detect(), etc. And then send a uevent if their 

Re: [Intel-gfx] [PATCH 14/19] drm/mediatek: Use new atomic iterator macros

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:13PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 

Patches 13-14
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index db61aa5f32ef..414e848d8cbf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -50,8 +50,8 @@ static void mtk_atomic_wait_for_fences(struct 
> drm_atomic_state *state)
>   struct drm_plane_state *plane_state;
>   int i;
>  
> - for_each_plane_in_state(state, plane, plane_state, i)
> - mtk_fb_wait(plane->state->fb);
> + for_each_new_plane_in_state(state, plane, plane_state, i)
> + mtk_fb_wait(plane_state->fb);
>  }
>  
>  static void mtk_atomic_complete(struct mtk_drm_private *private,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/12] drm/i915/guc: Cache the client mapping

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

Use i915_gem_object_pin_map() for the guc client's lifetime to replace
the peristent kmap + frequent kmap_atomic with a permanent vmapping.
This avoids taking the obj->mm.lock mutex whilst inside irq context
later.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 38 +++---
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b31573a825fa..bab0c2fc3bce 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -220,7 +220,7 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
struct guc_context_desc desc;
size_t len;

-   doorbell = client->client_base + client->doorbell_offset;
+   doorbell = client->vaddr + client->doorbell_offset;

if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
test_bit(client->doorbell_id, doorbell_bitmap)) {
@@ -326,7 +326,7 @@ static void guc_proc_desc_init(struct intel_guc *guc,
 {
struct guc_process_desc *desc;

-   desc = client->client_base + client->proc_desc_offset;
+   desc = client->vaddr + client->proc_desc_offset;

memset(desc, 0, sizeof(*desc));

@@ -413,8 +413,8 @@ static void guc_ctx_desc_init(struct intel_guc *guc,
gfx_addr = i915_ggtt_offset(client->vma);
desc.db_trigger_phy = sg_dma_address(client->vma->pages->sgl) +
client->doorbell_offset;
-   desc.db_trigger_cpu = (uintptr_t)client->client_base +
-   client->doorbell_offset;
+   desc.db_trigger_cpu =
+   (uintptr_t)client->vaddr + client->doorbell_offset;
desc.db_trigger_uk = gfx_addr + client->doorbell_offset;
desc.process_desc = gfx_addr + client->proc_desc_offset;
desc.wq_addr = gfx_addr + client->wq_offset;
@@ -465,7 +465,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
 {
const size_t wqi_size = sizeof(struct guc_wq_item);
struct i915_guc_client *gc = request->i915->guc.execbuf_client;
-   struct guc_process_desc *desc = gc->client_base + gc->proc_desc_offset;
+   struct guc_process_desc *desc = gc->vaddr + gc->proc_desc_offset;
u32 freespace;
int ret;

@@ -506,10 +506,9 @@ static void guc_wq_item_append(struct i915_guc_client *gc,
struct intel_engine_cs *engine = rq->engine;
struct guc_process_desc *desc;
struct guc_wq_item *wqi;
-   void *base;
-   u32 freespace, tail, wq_off, wq_page;
+   u32 freespace, tail, wq_off;

-   desc = gc->client_base + gc->proc_desc_offset;
+   desc = gc->vaddr + gc->proc_desc_offset;

/* Free space is guaranteed, see i915_guc_wq_reserve() above */
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
@@ -539,10 +538,7 @@ static void guc_wq_item_append(struct i915_guc_client *gc,
gc->wq_rsvd -= wqi_size;

/* WQ starts from the page after doorbell / process_desc */
-   wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT;
-   wq_off &= PAGE_SIZE - 1;
-   base = kmap_atomic(i915_gem_object_get_page(gc->vma->obj, wq_page));
-   wqi = (struct guc_wq_item *)((char *)base + wq_off);
+   wqi = gc->vaddr + wq_off + GUC_DB_SIZE;

/* Now fill in the 4-word work queue item */
wqi->header = WQ_TYPE_INORDER |
@@ -555,8 +551,6 @@ static void guc_wq_item_append(struct i915_guc_client *gc,

wqi->ring_tail = tail << WQ_RING_TAIL_SHIFT;
wqi->fence_id = rq->global_seqno;
-
-   kunmap_atomic(base);
 }

 static int guc_ring_doorbell(struct i915_guc_client *gc)
@@ -566,7 +560,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
union guc_doorbell_qw *db;
int attempt = 2, ret = -EAGAIN;

-   desc = gc->client_base + gc->proc_desc_offset;
+   desc = gc->vaddr + gc->proc_desc_offset;

/* Update the tail so it is visible to GuC */
desc->tail = gc->wq_tail;
@@ -582,7 +576,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
db_exc.cookie = 1;

/* pointer of current doorbell cacheline */
-   db = gc->client_base + gc->doorbell_offset;
+   db = gc->vaddr + gc->doorbell_offset;

while (attempt--) {
/* lets ring the doorbell */
@@ -729,14 +723,14 @@ guc_client_free(struct drm_i915_private *dev_priv,
 * Be sure to drop any locks
 */

-   if (client->client_base) {
+   if (client->vaddr) {
/*
 * If we got as far as setting up a doorbell, make sure we
 * shut it down before unmapping & deallocating the memory.
 */
guc_disable_doorbell(guc, client);

-   

Re: [Intel-gfx] [PATCH 07/12] drm/i915/scheduler: Boost priorities for flips

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

Boost the priority of any rendering required to show the next pageflip
as we want to avoid missing the vblank by being delayed by invisible
workload. We prioritise avoiding jank and jitter in the GUI over
starving background tasks.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 
 drivers/gpu/drm/i915/i915_gem.c  | 50 
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 3 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 61fee0b0c302..738ec44fe6af 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3416,6 +3416,11 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 unsigned int flags,
 long timeout,
 struct intel_rps_client *rps);
+int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int priority);
+#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
+
 int __must_check
 i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
  bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4697848ecfd9..4287c51fb461 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -433,6 +433,56 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
return timeout;
 }

+static void fence_set_priority(struct dma_fence *fence, int prio)
+{
+   struct drm_i915_gem_request *rq;
+   struct intel_engine_cs *engine;
+
+   if (!dma_fence_is_i915(fence))
+   return;
+
+   rq = to_request(fence);
+   engine = rq->engine;
+   if (!engine->schedule)
+   return;
+
+   engine->schedule(rq, prio);


This will be inefficient with reservation objects containing multiple 
i915 fences.


Instead you could update just a single priority and then rebalance the 
tree at the end.


Not sure how much work that would be. Perhaps it can be improved later 
on. Or we don't expect this scenario to occur here?



+}
+
+int
+i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int prio)
+{
+   struct dma_fence *excl;
+
+   if (flags & I915_WAIT_ALL) {
+   struct dma_fence **shared;
+   unsigned int count, i;
+   int ret;
+
+   ret = reservation_object_get_fences_rcu(obj->resv,
+   , , );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < count; i++) {
+   fence_set_priority(shared[i], prio);
+   dma_fence_put(shared[i]);
+   }
+
+   kfree(shared);
+   } else {
+   excl = reservation_object_get_excl_rcu(obj->resv);
+   }
+
+   if (excl) {
+   fence_set_priority(excl, prio);
+   dma_fence_put(excl);
+   }
+   return 0;
+}
+
 /**
  * Waits for rendering to the object to be completed
  * @obj: i915 gem object
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 97589102442c..8df9554432a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14761,6 +14761,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
  GFP_KERNEL);
if (ret < 0)
return ret;
+
+   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
}

if (plane->type == DRM_PLANE_TYPE_CURSOR &&



Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

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:
> > > 
> > > 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 a lengthy one for good reason, we don't need to
> > > > hold up the entire suspend/resume process while we wait for it to
> > > > finish. Luckily as it turns out, we already trigger a full connector
> > > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> > > > i915_drm_resume() entirely.
> > > > 
> > > > This won't lead to less time spent resuming just yet since now the
> > > > bottleneck will be waiting for the mode_config lock in
> > > > drm_kms_helper_poll_enable(), since that will be held as long as
> > > > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> > > > address that in the next patch.
> > > > 
> > > > Signed-off-by: Lyude 
> > > > Cc: David Weinehall 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index bfb2efd..532cc0f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
> > > >      * notifications.
> > > >      * */
> > > >     intel_hpd_init(dev_priv);
> > > > -   /* Config may have changed between suspend and resume */
> > > > -   drm_helper_hpd_irq_event(dev);
> > > 
> > > The comment is still apt. This code is known to be broken since it
> > > doesn't detect a change in monitors (e.g. a change in external connectors
> > > from docking) between suspend and resend. We still have to send the 
> > > uevent.
> > > 
> > > + drm_kms_helper_hotplug_event(dev);
> > 
> > I might not have explained myself very well. The way things should look with
> > this patch is like this:
> > 
> > i915_drm_resume()
> >  -> intel_hpd_init()
> >    -> sets dev_priv->hotplug.poll_enabled to true
> Whoops, s/true/false/
> 
> >    -> schedules dev_priv->hotplug.poll_init_work
> >  -> continue resume…
> > 
> > at the same time:
> > 
> > i915_hpd_poll_init_work() gets scheduled and starts
> >  -> since dev_priv->hotplug.poll_enabled == false, 
> > drm_helper_hpd_irq_event()
> > is called
> >   -> drm_helper_hpd_irq_event() reprobes connectors
> >    -> if anything changed, drm_kms_helper_hotplug_event() gets called.

drm_helper_hpd_irq_event() does not detect a change in monitors, for
example, so there is no uevent in that case.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 3/4 v5] tests/drv_module_reload: Convert sh script to C version.

[Marius Vlad]

v5:
- reworked gem_info to gem_sanitychecks (Chris Wilson)
- remove subgroups/subtests for gem_exec_store and gem_sanitycheck
(Chris Wilson)

v4:
- adjust test to make use of lib/igt_kmod
- replaced SW_FINISH with SET_CACHEING (Chris Wilson)

v3:
- fix passing boolean value as flags to igt_kmod_unload().

v2:
- embedded gem_alive and gem_exec_store into test (Chris Wilson)
- int main() to igt_main (Chris Wilson)
- moved tests/gem_alive -> tools/gem_info (Chris Wilson)
- added to intel-ci/fast-feedback.testlist (Petri Latvala)
- added hda_dynamic_debug() (Petri Latvala)
- renamed from tests/drv_module_reload_basic to tests/drv_module_reload
(all subtests are basic and have been added to fast-feedback.testlist)

Signed-off-by: Marius Vlad 
---
 tests/Makefile.am |   1 -
 tests/Makefile.sources|   2 +-
 tests/drv_module_reload.c | 332 ++
 tests/drv_module_reload_basic | 111 
 tests/gem_alive.c |  35 
 tests/intel-ci/fast-feedback.testlist |   4 +-
 tools/Makefile.sources|   1 +
 tools/intel_gem_info.c|  35 
 8 files changed, 372 insertions(+), 149 deletions(-)
 create mode 100644 tests/drv_module_reload.c
 delete mode 100755 tests/drv_module_reload_basic
 delete mode 100644 tests/gem_alive.c
 create mode 100644 tools/intel_gem_info.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index a408126..14a41ae 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -26,7 +26,6 @@ noinst_PROGRAMS = \
$(NULL)
 
 pkglibexec_PROGRAMS = \
-   gem_alive \
gem_stress \
$(TESTS_progs) \
$(TESTS_progs_M) \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..b1511c6 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -211,6 +211,7 @@ TESTS_progs = \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
+   drv_module_reload \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
@@ -221,7 +222,6 @@ TESTS_scripts_M = \
 TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
-   drv_module_reload_basic \
kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
new file mode 100644
index 000..31ec2ec
--- /dev/null
+++ b/tests/drv_module_reload.c
@@ -0,0 +1,332 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#include "igt.h"
+#include "igt_debugfs.h"
+#include "igt_aux.h"
+#include "igt_kmod.h"
+#include "igt_sysfs.h"
+#include "igt_core.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
+#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+
+#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
+static void store_dword(int fd, unsigned ring)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   uint32_t batch[16];
+   int i;
+
+   if (!gem_has_ring(fd, ring))
+   return;
+
+   if (gen == 6 && (ring & ~(3<<13)) == I915_EXEC_BSD)
+   return;
+
+   intel_detect_and_clear_missed_interrupts(fd);
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = (uintptr_t)obj;
+   execbuf.buffer_count = 2;
+   execbuf.flags = ring;
+   if (gen < 6)
+   execbuf.flags |= I915_EXEC_SECURE;
+
+   memset(obj, 0, sizeof(obj));
+   obj[0].handle = gem_create(fd, 4096);
+   obj[1].handle = gem_create(fd, 4096);
+
+   memset(, 0, 

[Intel-gfx] [PATCH i-g-t 4/4 v5] tests/kms_sysfs_edid_timing: Convert sh to C version.

[Marius Vlad]

v3:
- use igt_mean for accounting (Chris Wilson)
- make it Intel-agnostic when searching for connectors (Chris Wilson)

v2:
- don't read cached values (Chris Wilson)
- warn on per connector, and fail per mean (Chris Wilson)

These are synthetic: 10ms per connector, and 50ms for all.

Signed-off-by: Marius Vlad 
---
 tests/Makefile.sources|  2 +-
 tests/kms_sysfs_edid_timing   | 25 ---
 tests/kms_sysfs_edid_timing.c | 96 +++
 3 files changed, 97 insertions(+), 26 deletions(-)
 delete mode 100755 tests/kms_sysfs_edid_timing
 create mode 100644 tests/kms_sysfs_edid_timing.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b1511c6..8af455a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -212,6 +212,7 @@ TESTS_progs = \
kms_sink_crc_basic \
prime_udl \
drv_module_reload \
+   kms_sysfs_edid_timing \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
@@ -222,7 +223,6 @@ TESTS_scripts_M = \
 TESTS_scripts = \
debugfs_emon_crash \
drv_debugfs_reader \
-   kms_sysfs_edid_timing \
sysfs_l3_parity \
test_rte_check \
tools_test \
diff --git a/tests/kms_sysfs_edid_timing b/tests/kms_sysfs_edid_timing
deleted file mode 100755
index 46ea540..000
--- a/tests/kms_sysfs_edid_timing
+++ /dev/null
@@ -1,25 +0,0 @@
-#!/bin/bash
-#
-# This check the time we take to read the content of all the possible 
connectors.
-# Without the edid -ENXIO patch 
(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083),
-# we sometimes take a *really* long time. So let's just check for some 
reasonable timing here
-#
-
-DRM_LIB_ALLOW_NO_MASTER=1
-
-SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_lib.sh
-
-TIME1=$(date +%s%N)
-cat $(find /sys/devices/|grep drm | grep /status) > /dev/null
-TIME2=$(date +%s%N)
-
-# time in ms
-RES=$(((TIME2 - TIME1) / 100))
-
-if [ $RES -gt 600 ]; then
-   echo "Talking to outputs took ${RES}ms, something is wrong"
-   exit $IGT_EXIT_FAILURE
-fi
-
-exit $IGT_EXIT_SUCCESS
diff --git a/tests/kms_sysfs_edid_timing.c b/tests/kms_sysfs_edid_timing.c
new file mode 100644
index 000..b56a147
--- /dev/null
+++ b/tests/kms_sysfs_edid_timing.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+#include "igt.h"
+
+#include 
+#include 
+#include 
+
+#define THRESHOLD_PER_CONNECTOR10
+#define THRESHOLD_TOTAL50
+#define CHECK_TIMES15
+
+IGT_TEST_DESCRIPTION("This check the time we take to read the content of all "
+"the possible connectors. Without the edid -ENXIO patch "
+
"(http://permalink.gmane.org/gmane.comp.video.dri.devel/62083), "
+"we sometimes take a *really* long time. "
+"So let's just check for some reasonable timing here");
+
+
+igt_simple_main
+{
+   DIR *dirp;
+   struct dirent *de;
+
+   dirp = opendir("/sys/class/drm");
+   igt_assert(dirp != NULL);
+
+   while ((de = readdir(dirp))) {
+   struct igt_mean mean = {};
+   struct stat st;
+   char path[PATH_MAX];
+   int i;
+
+   if (*de->d_name == '.')
+   continue;;
+
+   snprintf(path, sizeof(path), "/sys/class/drm/%s/status",
+   de->d_name);
+
+   if (stat(path, ))
+   continue;
+
+   igt_mean_init();
+   for (i = 0; i < CHECK_TIMES; i++) {
+   struct timespec ts = {};
+   int fd;
+
+   igt_nsec_elapsed();
+   fd = open(path, O_WRONLY);
+   igt_ignore_warn(write(fd, "detect\n", 7));
+
+ 

[Intel-gfx] [PATCH i-g-t 1/4 v5] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to lib/igt_aux, lib/igt_kmod.

[Marius Vlad]

lib/igt_aux: Added igt_pkill helper.
lib/igt_kmod: Added load/unload kmod helpers.

v5:
- added igt_i915_driver_{load/unload}.
- added kick_snd_hda_intel() to match current tests/drv_module_reload_basic and
integrated into igt_i915_driver_load/unload.
- added gtk-doc section for lib/igt_kmod

v4:
- decided to split libkmod helpers into their own file as there's
another user lib/igt_gvt or tests/gvt_basic.
- fixed some gtk-doc documentation.

v3:
- return -errno (igt_pkill()) in case of failure (Cris Wilson)
- return bool for igt_kmod_is_loaded(), replaced strncasecmp with strncmp
(Chris Wilson)
- use igt_debug() instead of igt_info() for igt_kmod_load()/
igt_kmod_unload() and return -err directly from libkmod (Chris Wilson)

v2:
- Renamed libkmod helpers (Chris Wilson)
- Removed SIGTERM/SIGKILL case where we repeatedly tried to terminate the
process: just call kill(2) once (Chris Wilson)
- Removed redundant check in igt_kmod_unload(), igt_module_in_use() (Chris
Wilson)
- Pass flags to igt_kmod_unload() from the caller (Chris Wilson)
- Removed useless function igt_kill() which acts just as kill(2) (Chris
Wilson)

Signed-off-by: Marius Vlad 
---
 configure.ac   |   2 +
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.am|   2 +
 lib/Makefile.sources   |   2 +
 lib/igt_aux.c  |  40 
 lib/igt_aux.h  |   2 +
 lib/igt_gvt.c  |  43 +---
 lib/igt_kmod.c | 260 +
 lib/igt_kmod.h |  38 +++
 lib/igt_sysfs.c| 106 +
 lib/igt_sysfs.h|   3 +
 11 files changed, 458 insertions(+), 41 deletions(-)
 create mode 100644 lib/igt_kmod.c
 create mode 100644 lib/igt_kmod.h

diff --git a/configure.ac b/configure.ac
index 735cfd5..2c6e49d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -121,6 +121,8 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 
 PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
+PKG_CHECK_MODULES(KMOD, [libkmod])
+PKG_CHECK_MODULES(PROCPS, [libprocps])
 
 case "$target_cpu" in
x86*|i?86)
diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml 
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index c862f2a..39061a8 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -22,6 +22,7 @@
 
 
 
+
 
 
 
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 4c0893d..e1737bd 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -34,6 +34,8 @@ AM_CFLAGS += $(CAIRO_CFLAGS)
 libintel_tools_la_LIBADD = \
$(DRM_LIBS) \
$(PCIACCESS_LIBS) \
+   $(PROCPS_LIBS) \
+   $(KMOD_LIBS) \
$(CAIRO_LIBS) \
$(LIBUDEV_LIBS) \
$(LIBUNWIND_LIBS) \
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index e8e277b..2205c86 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -77,6 +77,8 @@ lib_source_list = \
igt_pm.h\
uwildmat/uwildmat.h \
uwildmat/uwildmat.c \
+   igt_kmod.c  \
+   igt_kmod.h  \
$(NULL)
 
 .PHONY: version.h.tmp
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 421f6d4..a8c5662 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -51,6 +51,8 @@
 #include 
 #include 
 
+#include 
+
 #include "drmtest.h"
 #include "i915_drm.h"
 #include "intel_chipset.h"
@@ -1193,6 +1195,44 @@ void igt_set_module_param_int(const char *name, int val)
igt_set_module_param(name, str);
 }
 
+/**
+ * igt_pkill:
+ * @sig: Signal to send
+ * @comm: Name of process in the form found in /proc/pid/comm (limited to 15
+ * chars)
+ *
+ * Returns: 0 in case the process is not found running or the signal has been
+ * sent successfully or -errno otherwise.
+ *
+ * This function sends the signal @sig for a process found in process table
+ * with name @comm.
+ */
+int
+igt_pkill(int sig, const char *comm)
+{
+   PROCTAB *proc;
+   proc_t *proc_info;
+   int err = 0;
+
+   proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
+   igt_assert(proc != NULL);
+
+   while ((proc_info = readproc(proc, NULL))) {
+   if (!strncasecmp(proc_info->cmd, comm, sizeof(proc_info->cmd))) 
{
+
+   if (kill(proc_info->tid, sig) < 0)
+   err = -errno;
+
+   freeproc(proc_info);
+   break;
+   }
+   freeproc(proc_info);
+   }
+
+   closeproc(proc);
+   return err;
+}
+
 static struct igt_siglatency {
timer_t timer;
struct timespec target;
diff --git 

[Intel-gfx] [PATCH i-g-t 2/4 v5] lib/igt_gvt: Make use of libkmod helpers and fix reading gvt parameter.

[Marius Vlad]

v2:
- use igt_sysfs_get_boolean() to get gvt status (Chris Wilson)
- do not hard-fail when i915 module could not be loaded/unloaded (Chris
Wilson)

Signed-off-by: Marius Vlad 
---
 lib/igt_gvt.c | 37 ++---
 tests/gvt_basic.c |  2 +-
 2 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c
index 8bbf9bd..4ab7433 100644
--- a/lib/igt_gvt.c
+++ b/lib/igt_gvt.c
@@ -24,35 +24,30 @@
 #include "igt.h"
 #include "igt_gvt.h"
 #include "igt_sysfs.h"
+#include "igt_kmod.h"
 
+#include 
 #include 
 #include 
 #include 
 
 static bool is_gvt_enabled(void)
 {
-   FILE *file;
-   int value;
bool enabled = false;
+   int dir, fd;
 
-   file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
-   if (!file)
+   fd = __drm_open_driver(DRIVER_INTEL);
+   dir = igt_sysfs_open_parameters(fd);
+   if (dir < 0)
return false;
 
-   if (fscanf(file, "%d", ) == 1)
-   enabled = value;
-   fclose(file);
+   enabled = igt_sysfs_get_boolean(dir, "enable_gvt");
 
-   errno = 0;
-   return enabled;
-}
+   close(dir);
+   close(fd);
 
-static void unload_i915(void)
-{
-   kick_fbcon(false);
-   /* pkill alsact */
+   return enabled;
 
-   igt_ignore_warn(system("/sbin/modprobe -s -r i915"));
 }
 
 bool igt_gvt_load_module(void)
@@ -60,8 +55,11 @@ bool igt_gvt_load_module(void)
if (is_gvt_enabled())
return true;
 
-   unload_i915();
-   igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=1"));
+   if (igt_i915_driver_unload())
+   return false;
+
+   if (igt_i915_driver_load("enable_gvt=1"))
+   return false;
 
return is_gvt_enabled();
 }
@@ -71,8 +69,9 @@ void igt_gvt_unload_module(void)
if (!is_gvt_enabled())
return;
 
-   unload_i915();
-   igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=0"));
+   igt_i915_driver_unload();
+
+   igt_i915_driver_load(NULL);
 
igt_assert(!is_gvt_enabled());
 }
diff --git a/tests/gvt_basic.c b/tests/gvt_basic.c
index 48b853a..4e909a5 100644
--- a/tests/gvt_basic.c
+++ b/tests/gvt_basic.c
@@ -32,7 +32,7 @@ igt_main
 
igt_fixture {
igt_require(igt_gvt_load_module());
-   fd = drm_open_driver(DRIVER_INTEL);
+   fd = __drm_open_driver(DRIVER_INTEL);
}
 
igt_subtest_f("invalid-placeholder-test");
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 0/4 v5] Convert sh scripts to C variants.

[Marius Vlad]

Changes since last version include rebasing to account for modifications in
tests/drv_module_reload_basic and address comments.

This series adds some library support to help converting sh scripts to C
version. Based on that I've converted drv_module_reload_basic and
kms_sysfs_edid_timing.  Other tests should follow. drv_module_reload requires
the most boilerplate code.

The reason for so many changes is the fact that some code got moved so other
users can use it. Secondly wrappers around libkmod in lib/igt_kmod and procps
in lib/igt_aux.  Thirdly drv_module_reload has embedded tools/gem_info and
tests/gem_exec_store in it, with minor modifications to allow running them as
subtests. Finally, C is more verbose than sh.

Changes since v4:
- rebased to include unbinding snd_hda_intel
- added igt_i915_driver_load/unload so it can used in lib/igt_gvt
and tests/drv_module_reload (Cris Wilson)
- do not hard fail when loading/reloading in lib/igt_gvt (Chris Wilson)
- remove subgroups in tests/drv_module_reload (Chris Wilson)
- make tests/kms_sysfs_edid_timing intel-agnostic when searching
for connectors and use igt_mean (Chris Wilson)

Changes since v3:
- lib/igt_kmod: added libkmod helpers into their own file. There seems to be
another user for it: lib/igt_gvt. Fixed a issue with lib/igt_gvt while at
it and converted to make use of lib/igt_kmod.
- lib/{igt_kmod, igt_aux}: Fixed gtk-doc documentation formatting (Daniel 
Vetter)
- tests/drv_module_reload: Re-worked reload() method by splitting into
load() and unload() and asserting more.
- replaced SW_FINISH with SET_CACHEING in tests/drv_module_reload (Chris Wilson)

Changes since v2:
- lib/igt_aux: Addressed comments from Chris Wilson
- tests/drv_module_reload: Passed incorrectly boolean instead of uint as flags 
to
igt_kmod_unload().

Changes since v1:
- lib/igt_aux: Addressed comments from Chris Wilson
- tests/drv_module_reload: Addressed comments from Chris Wilson and Petri 
Latvala
- tests/kms_sysfs_edid_timing: Addressed comments from Chris Wilson
- (Hopefully): Addressed comments from Jani Nikula.

Marius Vlad (4):
  lib/{igt_sysfs,igt_aux}: Make available to other users kick_fbcon()   
 (unbind_fbcon()), and added helpers to lib/igt_aux, lib/igt_kmod.
  lib/igt_gvt: Make use of libkmod helpers and fix reading gvt
parameter.
  tests/drv_module_reload: Convert sh script to C version.
  tests/kms_sysfs_edid_timing: Convert sh to C version.

 configure.ac   |   2 +
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.am|   2 +
 lib/Makefile.sources   |   2 +
 lib/igt_aux.c  |  40 +++
 lib/igt_aux.h  |   2 +
 lib/igt_gvt.c  |  78 ++---
 lib/igt_kmod.c | 260 
 lib/igt_kmod.h |  38 +++
 lib/igt_sysfs.c| 106 +++
 lib/igt_sysfs.h|   3 +
 tests/Makefile.am  |   1 -
 tests/Makefile.sources |   4 +-
 tests/drv_module_reload.c  | 332 +
 tests/drv_module_reload_basic  | 111 ---
 tests/gem_alive.c  |  35 ---
 tests/gvt_basic.c  |   2 +-
 tests/intel-ci/fast-feedback.testlist  |   4 +-
 tests/kms_sysfs_edid_timing|  25 --
 tests/kms_sysfs_edid_timing.c  |  96 ++
 tools/Makefile.sources |   1 +
 tools/intel_gem_info.c |  35 +++
 22 files changed, 945 insertions(+), 235 deletions(-)
 create mode 100644 lib/igt_kmod.c
 create mode 100644 lib/igt_kmod.h
 create mode 100644 tests/drv_module_reload.c
 delete mode 100755 tests/drv_module_reload_basic
 delete mode 100644 tests/gem_alive.c
 delete mode 100755 tests/kms_sysfs_edid_timing
 create mode 100644 tests/kms_sysfs_edid_timing.c
 create mode 100644 tools/intel_gem_info.c

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/19] drm/atomic: Fix atomic helpers to use the new iterator macros.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:06PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 302 
> +++-
>  1 file changed, 157 insertions(+), 145 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index fcb6e5b55217..c8aba493fc17 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -103,7 +103,7 @@ static int handle_conflicting_encoders(struct 
> drm_atomic_state *state,
>* part of the state. If the same encoder is assigned to multiple
>* connectors bail out.
>*/
> - for_each_connector_in_state(state, connector, conn_state, i) {
> + for_each_new_connector_in_state(state, connector, conn_state, i) {
>   const struct drm_connector_helper_funcs *funcs = 
> connector->helper_private;
>   struct drm_encoder *new_encoder;
>  
> @@ -238,22 +238,22 @@ steal_encoder(struct drm_atomic_state *state,
>  {
>   struct drm_crtc_state *crtc_state;
>   struct drm_connector *connector;
> - struct drm_connector_state *connector_state;
> + struct drm_connector_state *old_connector_state, *new_connector_state;
>   int i;
>  
> - for_each_connector_in_state(state, connector, connector_state, i) {
> + for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
>   struct drm_crtc *encoder_crtc;
>  
> - if (connector_state->best_encoder != encoder)
> + if (new_connector_state->best_encoder != encoder)
>   continue;
>  
> - encoder_crtc = connector->state->crtc;
> + encoder_crtc = old_connector_state->crtc;
>  
>   DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
> stealing it\n",
>encoder->base.id, encoder->name,
>encoder_crtc->base.id, encoder_crtc->name);
>  
> - set_best_encoder(state, connector_state, NULL);
> + set_best_encoder(state, new_connector_state, NULL);
>  
>   crtc_state = drm_atomic_get_existing_crtc_state(state, 
> encoder_crtc);
>   crtc_state->connectors_changed = true;
> @@ -265,7 +265,8 @@ steal_encoder(struct drm_atomic_state *state,
>  static int
>  update_connector_routing(struct drm_atomic_state *state,
>struct drm_connector *connector,
> -  struct drm_connector_state *connector_state)
> +  struct drm_connector_state *old_connector_state,
> +  struct drm_connector_state *new_connector_state)
>  {
>   const struct drm_connector_helper_funcs *funcs;
>   struct drm_encoder *new_encoder;
> @@ -275,24 +276,24 @@ update_connector_routing(struct drm_atomic_state *state,
>connector->base.id,
>connector->name);
>  
> - if (connector->state->crtc != connector_state->crtc) {
> - if (connector->state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state, 
> connector->state->crtc);
> + if (old_connector_state->crtc != new_connector_state->crtc) {
> + if (old_connector_state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state, 
> old_connector_state->crtc);
>   crtc_state->connectors_changed = true;
>   }
>  
> - if (connector_state->crtc) {
> - crtc_state = drm_atomic_get_existing_crtc_state(state, 
> connector_state->crtc);
> + if (new_connector_state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state, 
> new_connector_state->crtc);
>   crtc_state->connectors_changed = true;
>   }
>   }
>  
> - if (!connector_state->crtc) {
> + if (!new_connector_state->crtc) {
>   DRM_DEBUG_ATOMIC("Disabling [CONNECTOR:%d:%s]\n",
>   connector->base.id,
>   connector->name);
>  
> - set_best_encoder(state, connector_state, NULL);
> + set_best_encoder(state, new_connector_state, NULL);
>  
>   return 0;
>   }
> @@ -301,7 +302,7 @@ update_connector_routing(struct drm_atomic_state *state,
>  
>   if (funcs->atomic_best_encoder)
>   new_encoder = funcs->atomic_best_encoder(connector,
> -  connector_state);
> +  new_connector_state);
>   else if (funcs->best_encoder)
>   new_encoder = funcs->best_encoder(connector);
>   else
> @@ -314,33 +315,33 @@ update_connector_routing(struct drm_atomic_state *state,
>   return -EINVAL;
>   

Re: [Intel-gfx] [PATCH 06/12] drm/i915/scheduler: Execute requests in order of priorities

[Tvrtko Ursulin]

Hi,

1st pass comments only for now.

On 02/11/2016 17:50, Chris Wilson wrote:

Track the priority of each request and use it to determine the order in
which we submit requests to the hardware via execlists.

The priority of the request is determined by the user (eventually via
the context) but may be overridden at any time by the driver. When we set
the priority of the request, we bump the priority of all of its
dependencies to match - so that a high priority drawing operation is not
stuck behind a background task.

When the request is ready to execute (i.e. we have signaled the submit
fence following completion of all its dependencies, including third
party fences), we put the request into a priority sorted rbtree to be
submitted to the hardware. If the request is higher priority than all
pending requests, it will be submitted on the next context-switch
interrupt as soon as the hardware has completed the current request. We
do not currently preempt any current execution to immediately run a very
high priority request, at least not yet.

One more limitation, is that this is first implementation is for
execlists only so currently limited to gen8/gen9.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   7 +-
 drivers/gpu/drm/i915/i915_gem.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_request.c|   4 ++
 drivers/gpu/drm/i915/i915_gem_request.h|   6 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 ++
 drivers/gpu/drm/i915/intel_engine_cs.c |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 104 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|   3 +-
 8 files changed, 109 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3cb96d260dfb..dac435680e98 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -631,8 +631,9 @@ static void print_request(struct seq_file *m,
  struct drm_i915_gem_request *rq,
  const char *prefix)
 {
-   seq_printf(m, "%s%x [%x:%x] @ %d: %s\n", prefix,
+   seq_printf(m, "%s%x [%x:%x] prio=%d @ %dms: %s\n", prefix,


Noticed this is quite unreadable due the range of INT_MIN to INT_MAX. Do 
we need such granularity or could use something smaller so it looks 
nicer here? I know, the argument is quite poor. :)



   rq->global_seqno, rq->ctx->hw_id, rq->fence.seqno,
+  rq->priotree.priority,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
   rq->timeline->common->name);
 }
@@ -3218,6 +3219,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)

if (i915.enable_execlists) {
u32 ptr, read, write;
+   struct rb_node *rb;

seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3257,7 +3259,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();

spin_lock_irq(>timeline->lock);
-   list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
+   rq = rb_entry(rb, typeof(*rq), priotree.node);
print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(>timeline->lock);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cf28666021f8..4697848ecfd9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2687,10 +2687,11 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)

if (i915.enable_execlists) {
spin_lock_irq(>timeline->lock);
-   INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
+   engine->execlist_queue = RB_ROOT;
+   engine->execlist_first = NULL;
spin_unlock_irq(>timeline->lock);
}
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 13090f226203..5f0068fac3e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -141,6 +141,8 @@ i915_priotree_fini(struct i915_priotree *pt)
 {
struct i915_dependency *dep, *next;

+   GEM_BUG_ON(!RB_EMPTY_NODE(>node));
+
/* Everyone we depended upon should retire before us and remove
 * themselves from our list. However, retirement is run independently
 * on each 

[Intel-gfx] [PATCH 1/2] drm/i915: Make sure engines are idle during GPU idling in LR mode

[Imre Deak]

We assume that the GPU is idle once receiving the seqno via the last
request's user interrupt. In execlist mode the corresponding context
completed interrupt can be delayed though and until this latter
interrupt arrives we consider the request to be pending on the ELSP
submit port. This can cause a problem during system suspend where this
last request will be seen by the resume code as still pending. Such
pending requests are normally replayed after a GPU reset, but during
resume we reset both SW and HW tracking of the ring head/tail pointers,
so replaying the pending request with its stale tale pointer will leave
the ring in an inconsistent state. A subsequent request submission can
lead then to the GPU executing from uninitialized area in the ring
behind the above stale tail pointer.

Fix this by making sure any pending request on the ELSP port is
completed before suspending. I used a polling wait since the completion
time I measured was <1ms and since normally we only need to wait during
system suspend. GPU idling during runtime suspend is scheduled with a
delay (currently 50-100ms) after the retirement of the last request at
which point the context completed interrupt must have arrived already.

The chance of this bug was increased by

commit 1c777c5d1dcdf8fa0223fcff35fb387b5bb9517a
Author: Imre Deak 
Date:   Wed Oct 12 17:46:37 2016 +0300

drm/i915/hsw: Fix GPU hang during resume from S3-devices state

but it could happen even without the explicit GPU reset, since we
disable interrupts afterwards during the suspend sequence.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem.c  |  3 +++
 drivers/gpu/drm/i915/intel_lrc.c | 12 
 drivers/gpu/drm/i915/intel_lrc.h |  1 +
 3 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1f995ce..5ff02b5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2766,6 +2766,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (dev_priv->gt.active_requests)
goto out_unlock;
 
+   if (i915.enable_execlists)
+   intel_lr_wait_engines_idle(dev_priv);
+
for_each_engine(engine, dev_priv, id)
i915_gem_batch_pool_fini(>batch_pool);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index fa3012c..ee4aaf1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -522,6 +522,18 @@ static bool execlists_elsp_idle(struct intel_engine_cs 
*engine)
return !engine->execlist_port[0].request;
 }
 
+void intel_lr_wait_engines_idle(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, dev_priv, id) {
+   if (wait_for(execlists_elsp_idle(engine), 10))
+   DRM_ERROR("Timeout waiting for engine %s to idle\n",
+ engine->name);
+   }
+}
+
 static bool execlists_elsp_ready(struct intel_engine_cs *engine)
 {
int port;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 4fed816..bf3775e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -87,6 +87,7 @@ void intel_lr_context_unpin(struct i915_gem_context *ctx,
 
 struct drm_i915_private;
 
+void intel_lr_wait_engines_idle(struct drm_i915_private *dev_priv);
 void intel_lr_context_resume(struct drm_i915_private *dev_priv);
 uint64_t intel_lr_context_descriptor(struct i915_gem_context *ctx,
 struct intel_engine_cs *engine);
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Add assert for no pending GPU requests during resume in LR mode

[Imre Deak]

During resume we will reset the SW/HW tracking for each ring head/tail
pointers and so are not prepared to replay any pending requests (as
opposed to GPU reset time). Add an assert for this.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_lrc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ee4aaf1..ae46345 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2158,6 +2158,8 @@ void intel_lr_context_resume(struct drm_i915_private 
*dev_priv)
if (WARN_ON(IS_ERR(reg)))
continue;
 
+   WARN_ON(!execlists_elsp_idle(engine));
+
reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
reg[CTX_RING_HEAD+1] = 0;
reg[CTX_RING_TAIL+1] = 0;
-- 
2.5.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Small fixes to speed up resume

[Patchwork]

== Series Details ==

Series: Small fixes to speed up resume
URL   : https://patchwork.freedesktop.org/series/14787/
State : success

== Summary ==

Series 14787v1 Small fixes to speed up resume
https://patchwork.freedesktop.org/api/1.0/series/14787/revisions/1/mbox/


fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:241  pass:188  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 

8a1c897ee1d0d93b8e70991becb6f9f8488dba1b drm-intel-nightly: 
2016y-11m-03d-13h-53m-22s UTC integration manifest
643b3b8 drm/i915: Reinit polling before hpd when resuming
3f36aca drm/i915: Remove redundant reprobe in i915_drm_resume

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2898/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[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 process pointed
> > > out a lot of the time in suspend/resume is being spent reprobing. While
> > > the reprobing process is a lengthy one for good reason, we don't need to
> > > hold up the entire suspend/resume process while we wait for it to
> > > finish. Luckily as it turns out, we already trigger a full connector
> > > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> > > i915_drm_resume() entirely.
> > > 
> > > This won't lead to less time spent resuming just yet since now the
> > > bottleneck will be waiting for the mode_config lock in
> > > drm_kms_helper_poll_enable(), since that will be held as long as
> > > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> > > address that in the next patch.
> > > 
> > > Signed-off-by: Lyude 
> > > Cc: David Weinehall 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index bfb2efd..532cc0f 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
> > >    * notifications.
> > >    * */
> > >   intel_hpd_init(dev_priv);
> > > - /* Config may have changed between suspend and resume */
> > > - drm_helper_hpd_irq_event(dev);
> > 
> > The comment is still apt. This code is known to be broken since it
> > doesn't detect a change in monitors (e.g. a change in external connectors
> > from docking) between suspend and resend. We still have to send the uevent.
> > 
> > +   drm_kms_helper_hotplug_event(dev);
> 
> I might not have explained myself very well. The way things should look with
> this patch is like this:
> 
> i915_drm_resume()
>  -> intel_hpd_init()
>    -> sets dev_priv->hotplug.poll_enabled to true
Whoops, s/true/false/

>    -> schedules dev_priv->hotplug.poll_init_work
>  -> continue resume…
> 
> at the same time:
> 
> i915_hpd_poll_init_work() gets scheduled and starts
>  -> since dev_priv->hotplug.poll_enabled == false, drm_helper_hpd_irq_event()
> is called
>   -> drm_helper_hpd_irq_event() reprobes connectors
>    -> if anything changed, drm_kms_helper_hotplug_event() gets called.
> 
> So we're still polling the connectors when coming out of resume just like
> before, except now we're doing it without needlessly making the whole resume
> process stall until we're done. We're also no longer reprobing display
> connectors twice…
> 
> > 
> > 
> > which also depends upon us actually reseting the connector->status to
> > unknown in drm_mode_config_reset(), Daniel!
> > -Chris
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[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 a lengthy one for good reason, we don't need to
> > hold up the entire suspend/resume process while we wait for it to
> > finish. Luckily as it turns out, we already trigger a full connector
> > reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> > i915_drm_resume() entirely.
> > 
> > This won't lead to less time spent resuming just yet since now the
> > bottleneck will be waiting for the mode_config lock in
> > drm_kms_helper_poll_enable(), since that will be held as long as
> > i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> > address that in the next patch.
> > 
> > Signed-off-by: Lyude 
> > Cc: David Weinehall 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index bfb2efd..532cc0f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
> >      * notifications.
> >      * */
> >     intel_hpd_init(dev_priv);
> > -   /* Config may have changed between suspend and resume */
> > -   drm_helper_hpd_irq_event(dev);
> 
> The comment is still apt. This code is known to be broken since it
> doesn't detect a change in monitors (e.g. a change in external connectors
> from docking) between suspend and resend. We still have to send the uevent.
> 
> + drm_kms_helper_hotplug_event(dev);

I might not have explained myself very well. The way things should look with
this patch is like this:

i915_drm_resume()
 -> intel_hpd_init()
   -> sets dev_priv->hotplug.poll_enabled to true
   -> schedules dev_priv->hotplug.poll_init_work
 -> continue resume…

at the same time:

i915_hpd_poll_init_work() gets scheduled and starts
 -> since dev_priv->hotplug.poll_enabled == false, drm_helper_hpd_irq_event() 
is called
  -> drm_helper_hpd_irq_event() reprobes connectors
   -> if anything changed, drm_kms_helper_hotplug_event() gets called.

So we're still polling the connectors when coming out of resume just like
before, except now we're doing it without needlessly making the whole resume
process stall until we're done. We're also no longer reprobing display
connectors twice…

> 
> which also depends upon us actually reseting the connector->status to
> unknown in drm_mode_config_reset(), Daniel!
> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

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 a lengthy one for good reason, we don't need to
> hold up the entire suspend/resume process while we wait for it to
> finish. Luckily as it turns out, we already trigger a full connector
> reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
> i915_drm_resume() entirely.
> 
> This won't lead to less time spent resuming just yet since now the
> bottleneck will be waiting for the mode_config lock in
> drm_kms_helper_poll_enable(), since that will be held as long as
> i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
> address that in the next patch.
> 
> Signed-off-by: Lyude 
> Cc: David Weinehall 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index bfb2efd..532cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
>* notifications.
>* */
>   intel_hpd_init(dev_priv);
> - /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);

The comment is still apt. This code is known to be broken since it
doesn't detect a change in monitors (e.g. a change in external connectors
from docking) between suspend and resend. We still have to send the uevent.

+   drm_kms_helper_hotplug_event(dev);

which also depends upon us actually reseting the connector->status to
unknown in drm_mode_config_reset(), Daniel!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Thu, Nov 3, 2016 at 1:47 PM, Sharma, Shashank
 wrote:
> Hi Ville,
> (-dri-devel)
> I would appreciate an internal discussion before going to dri-devel.

Nack on internal discssion. We do development in the open.

> What did this patch break ?
> This is exposed in the same way, as the 3D flags.
> The information is already available in form of flags, all you have to do in 
> userspace is read and print that. Its already being done in Android.

Yeah, the patch is missing details on the bug report and how it falls
apart, but if that's added revert might be the appropriate thing to do
here. Maintainer-ack on the revert if that crucial information is
added.
-Daniel

> NACK until we get to the right reason.
>
> Regards
> Shashank
> -Original Message-
> From: ville.syrj...@linux.intel.com [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, November 3, 2016 6:02 PM
> To: dri-de...@lists.freedesktop.org
> Cc: Sharma, Shashank ; Lin; Jia, Lin A 
> ; Sharma, Akashdeep ; Jim 
> Bride ; Jose Abreu ; 
> Daniel Vetter ; Emil Velikov 
> 
> Subject: [PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM 
> layer"
>
> From: Ville Syrjälä 
>
> This reverts commit a68362fe3e84fcbedd49939aa200519aa5410135.
>
> Adding new mode flags willy nilly breaks existing userspace. We need to 
> coordinate this better, potentially with a new client cap that only exposes 
> the aspect ratio flags when userspace is prepared for them (similar to what 
> we do with stereo 3D modes).
>
> Cc: Shashank Sharma 
> Cc: Lin, Jia 
> Cc: Akashdeep Sharma 
> Cc: Jim Bride 
> Cc: Jose Abreu 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_modes.c | 12   include/uapi/drm/drm_mode.h | 
>  6 --
>  2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 
> f64ac86deb84..725faa6409aa 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1513,12 +1513,6 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
> case HDMI_PICTURE_ASPECT_16_9:
> out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> break;
> -   case HDMI_PICTURE_ASPECT_64_27:
> -   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> -   break;
> -   case DRM_MODE_PICTURE_ASPECT_256_135:
> -   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> -   break;
> case HDMI_PICTURE_ASPECT_RESERVED:
> default:
> out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1580,12 +1574,6 
> @@ int drm_mode_convert_umode(struct drm_display_mode *out,
> case DRM_MODE_FLAG_PIC_AR_16_9:
> out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> break;
> -   case DRM_MODE_FLAG_PIC_AR_64_27:
> -   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> -   break;
> -   case DRM_MODE_FLAG_PIC_AR_256_135:
> -   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> -   break;
> default:
> out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> break;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 
> 084b50a02dc5..5c142b1387ac 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -81,8 +81,6 @@ extern "C" {
>  #define DRM_MODE_PICTURE_ASPECT_NONE   0
>  #define DRM_MODE_PICTURE_ASPECT_4_31
>  #define DRM_MODE_PICTURE_ASPECT_16_9   2
> -#define DRM_MODE_PICTURE_ASPECT_64_27  3
> -#define DRM_MODE_PICTURE_ASPECT_256_1354
>
>  /* Aspect ratio flag bitmask (4 bits 22:19) */
>  #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
> @@ -92,10 +90,6 @@ extern "C" {
> (DRM_MODE_PICTURE_ASPECT_4_3<<19)
>  #define  DRM_MODE_FLAG_PIC_AR_16_9 \
> (DRM_MODE_PICTURE_ASPECT_16_9<<19)
> -#define  DRM_MODE_FLAG_PIC_AR_64_27 \
> -   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
> -#define  DRM_MODE_FLAG_PIC_AR_256_135 \
> -   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
>
>  /* DPMS flags */
>  /* bit compatible with the xorg definitions. */
> --
> 2.7.4
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 06/19] drm/atomic: Use new atomic iterator macros.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:05PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 1915ec44f7eb..6672ea93ee73 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1369,7 +1369,7 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>  
>   DRM_DEBUG_ATOMIC("checking %p\n", state);
>  
> - for_each_plane_in_state(state, plane, plane_state, i) {
> + for_each_new_plane_in_state(state, plane, plane_state, i) {
>   ret = drm_atomic_plane_check(plane, plane_state);
>   if (ret) {
>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic core check 
> failed\n",
> @@ -1378,7 +1378,7 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   }
>   }
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   ret = drm_atomic_crtc_check(crtc, crtc_state);
>   if (ret) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] atomic core check 
> failed\n",
> @@ -1391,7 +1391,7 @@ int drm_atomic_check_only(struct drm_atomic_state 
> *state)
>   ret = config->funcs->atomic_check(state->dev, state);
>  
>   if (!state->allow_modeset) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (drm_atomic_crtc_needs_modeset(crtc_state)) {
>   DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requires full 
> modeset\n",
>crtc->base.id, crtc->name);

All part of the check phase. Check.

> @@ -1732,7 +1732,7 @@ retry:
>   }
>  
>   if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   struct drm_pending_vblank_event *e;
>  
>   e = create_vblank_event(dev, file_priv, NULL,
> @@ -1768,7 +1768,7 @@ out:
>* for TEST_ONLY too.
>*/
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
>   if (!crtc_state->event)
>   continue;

This latter one runs after the commit, but since it's only executed when
the check/commit failed, we wouldn't have swapped the state yet.

Reviewed-by: Ville Syrjälä 

>  
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/2] Small fixes to speed up resume

[Lyude]

Recently David Weinehall has been investigating how we can make the resume
process in i915 faster, and poked me to take a look at why we were taking so
long while reprobing. As it turns out the main issue is just that we hold up
the entire resume process while we reprobe connectors, which isn't really
necessary. This fixes things so we can actually run the connector reprobing on
resume asynchronously.

Cc: David Weinehall 

Lyude (2):
  drm/i915: Remove redundant reprobe in i915_drm_resume
  drm/i915: Reinit polling before hpd when resuming

 drivers/gpu/drm/i915/i915_drv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Lyude]

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 a lengthy one for good reason, we don't need to
hold up the entire suspend/resume process while we wait for it to
finish. Luckily as it turns out, we already trigger a full connector
reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
i915_drm_resume() entirely.

This won't lead to less time spent resuming just yet since now the
bottleneck will be waiting for the mode_config lock in
drm_kms_helper_poll_enable(), since that will be held as long as
i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
address that in the next patch.

Signed-off-by: Lyude 
Cc: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bfb2efd..532cc0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1602,8 +1602,6 @@ static int i915_drm_resume(struct drm_device *dev)
 * notifications.
 * */
intel_hpd_init(dev_priv);
-   /* Config may have changed between suspend and resume */
-   drm_helper_hpd_irq_event(dev);
 
intel_opregion_register(dev_priv);
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Reinit polling before hpd when resuming

[Lyude]

Now that we don't run the connector reprobing from i915_drm_resume(), we
need to make it so we don't have to wait for reprobing to finish so that
we actually speed things up. In order to do this, we need to make sure
that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
while trying to acquire the mode_config lock that
drm_kms_helper_poll_enable() needs to acquire.

The easiest way to do this is to just enable polling before hpd. This
shouldn't break anything since at that point we have everything else we
need for polling enabled.

As well, this should result in a rather significant improvement in how
quickly we can resume the system.

Signed-off-by: Lyude 
Cc: David Weinehall 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 532cc0f..f605dde 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1595,6 +1595,8 @@ static int i915_drm_resume(struct drm_device *dev)
 
intel_display_resume(dev);
 
+   drm_kms_helper_poll_enable(dev);
+
/*
 * ... but also need to make sure that hotplug processing
 * doesn't cause havoc. Like in the driver load code we don't
@@ -1614,7 +1616,6 @@ static int i915_drm_resume(struct drm_device *dev)
intel_opregion_notify_adapter(dev_priv, PCI_D0);
 
intel_autoenable_gt_powersave(dev_priv);
-   drm_kms_helper_poll_enable(dev);
 
enable_rpm_wakeref_asserts(dev_priv);
 
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/19] drm/atomic: Make add_affected_connectors look at crtc_state.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:04PM +0200, Maarten Lankhorst wrote:
> This kills another dereference of connector->state. connector_mask
> holds all unchanged connectors at least and any changed connectors
> are already in state anyway.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 120775fcfb70..1915ec44f7eb 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1230,8 +1230,13 @@ drm_atomic_add_affected_connectors(struct 
> drm_atomic_state *state,
>   struct drm_mode_config *config = >dev->mode_config;
>   struct drm_connector *connector;
>   struct drm_connector_state *conn_state;
> + struct drm_crtc_state *crtc_state;
>   int ret;
>  
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
>   ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
>   if (ret)
>   return ret;
> @@ -1240,11 +1245,11 @@ drm_atomic_add_affected_connectors(struct 
> drm_atomic_state *state,
>crtc->base.id, crtc->name, state);
>  
>   /*
> -  * Changed connectors are already in @state, so only need to look at the
> -  * current configuration.
> +  * Changed connectors are already in @state, so only need to look
> +  * at the connector_mask in crtc_state.
>*/
>   drm_for_each_connector(connector, state->dev) {
> - if (connector->state->crtc != crtc)
> + if (!(crtc_state->connector_mask & (1 << 
> drm_connector_index(connector
>   continue;

So this being the new crtc state, connector_mask will include all newly enabled
connectors (these will have been already added to the top level state), and
also any connector that was already enabled and isn't getting disabled (these
are the ones we need to explicitly add to the top level state here).

/me wishes the top level state would be renamed to drm_atomic_transaction or 
something...

Any connector that is getting disabled will already have been added to
the top level state as well, so them not being included in the new crtc
state's connectors_mask is fine.

Reviewed-by: Ville Syrjälä 

>  
>   conn_state = drm_atomic_get_connector_state(state, connector);
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/19] drm/blend: Use new atomic iterator macros.

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:37:03PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 

Patches 02-04 looks sane to me, so for them
Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_blend.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 85172a977bf3..70c03eb032fc 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -367,27 +367,27 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
> struct drm_atomic_state *state)
>  {
>   struct drm_crtc *crtc;
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>   struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   int i, ret = 0;
>  
> - for_each_plane_in_state(state, plane, plane_state, i) {
> - crtc = plane_state->crtc;
> + for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
> new_plane_state, i) {
> + crtc = new_plane_state->crtc;
>   if (!crtc)
>   continue;
> - if (plane->state->zpos != plane_state->zpos) {
> - crtc_state =
> + if (old_plane_state->zpos != new_plane_state->zpos) {
> + new_crtc_state =
>   drm_atomic_get_existing_crtc_state(state, crtc);
> - crtc_state->zpos_changed = true;
> + new_crtc_state->zpos_changed = true;
>   }
>   }
>  
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (crtc_state->plane_mask != crtc->state->plane_mask ||
> - crtc_state->zpos_changed) {
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + if (old_crtc_state->plane_mask != new_crtc_state->plane_mask ||
> + new_crtc_state->zpos_changed) {
>   ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
> - crtc_state);
> + 
> new_crtc_state);
>   if (ret)
>   return ret;
>   }
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Ville Syrjälä]

On Wed, Nov 02, 2016 at 09:28:46AM +0100, Maarten Lankhorst wrote:
> Op 01-11-16 om 14:41 schreef Ville Syrjälä:
> > On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
> >> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
> >>> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
>  Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
>  replace the old for_each_xxx_in_state ones. This is useful for >1 flip
>  depth and getting rid of all xxx->state dereferences.
> 
>  Signed-off-by: Maarten Lankhorst 
>  ---
>   drivers/gpu/drm/drm_atomic.c |  6 +++
>   drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
>   drivers/gpu/drm/i915/intel_display.c | 11 ++---
>   include/drm/drm_atomic.h | 81 
>  ++--
>   include/drm/drm_atomic_helper.h  |  3 ++
>   5 files changed, 142 insertions(+), 11 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>  index 5dd70540219c..120775fcfb70 100644
>  --- a/drivers/gpu/drm/drm_atomic.c
>  +++ b/drivers/gpu/drm/drm_atomic.c
>  @@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state 
>  *state,
>   return ERR_PTR(-ENOMEM);
>   
>   state->crtcs[index].state = crtc_state;
>  +state->crtcs[index].old_state = crtc->state;
>  +state->crtcs[index].new_state = crtc_state;
>   state->crtcs[index].ptr = crtc;
>   crtc_state->state = state;
>   
>  @@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state 
>  *state,
>   
>   state->planes[index].state = plane_state;
>   state->planes[index].ptr = plane;
>  +state->planes[index].old_state = plane->state;
>  +state->planes[index].new_state = plane_state;
>   plane_state->state = state;
>   
>   DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
>  @@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct 
>  drm_atomic_state *state,
>   
>   drm_connector_reference(connector);
>   state->connectors[index].state = connector_state;
>  +state->connectors[index].old_state = connector->state;
>  +state->connectors[index].new_state = connector_state;
>   state->connectors[index].ptr = connector;
>   connector_state->state = state;
>   
>  diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>  b/drivers/gpu/drm/drm_atomic_helper.c
>  index 07b432f43b98..fcb6e5b55217 100644
>  --- a/drivers/gpu/drm/drm_atomic_helper.c
>  +++ b/drivers/gpu/drm/drm_atomic_helper.c
>  @@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>    *
>    * See also:
>    * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
>  - * drm_atomic_helper_resume()
>  + * drm_atomic_helper_resume(), 
>  drm_atomic_helper_commit_duplicated_state()
>    */
>   struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device 
>  *dev)
>   {
>  @@ -2536,6 +2536,52 @@ unlock:
>   EXPORT_SYMBOL(drm_atomic_helper_suspend);
>   
>   /**
>  + * drm_atomic_helper_commit_duplicated_state - commit duplicated state
>  + * @state: duplicated atomic state to commit
>  + * @ctx: pointer to acquire_ctx to use for commit.
>  + * @nonblock: commit the state non-blocking.
>  + *
>  + * The state returned by drm_atomic_helper_duplicate_state() and
>  + * drm_atomic_helper_suspend() is partially invalid, and needs to
>  + * be fixed up before commit.
> >>> So the old_state pointers are potentially invalid because whatever->state
> >>> may have changed since we duplicated the state?
> >> Yes when you use drm_atomic_helper_duplicate_state, and commit a different 
> >> state before committing the duplicated state.
> >> This only happens during suspend/resume and gpu reset.
> > Should we maybe have something like drm_atomic_refresh_old_state(state)?
> > Would allow the caller then to check something in the old vs. new state
> > before committing?
> 
> iirc that was the first approach I took, but then you shouldn't do anything 
> with a duplicated state after
> creating a except commit it, so creating a commit_duplicated_state should be 
> enough.
> 
> Can you think of any case where you do the following?
> 
> Duplicate state
> commit different state
> Look at duplicated state, tinker with it, commit it.

Not really. Oh, and we do still run the thing through the check phase
when we commit it, don't we? That sounds like it should let the driver
do whatever it needs to do.

So my only other concern is just the 'bool nonblock' parameter. It's a
bit funny looking that we pass that in, then branch off to the 

Re: [Intel-gfx] [PATCH v3 1/3] lib: add igt_dummyload

[Ville Syrjälä]

On Thu, Nov 03, 2016 at 11:40:36AM +0200, Abdiel Janulgue wrote:
> A lot of igt testcases need some GPU workload to make sure a race
> window is big enough. Unfortunately having a fixed amount of
> workload leads to spurious test failures or overtly long runtimes
> on some fast/slow platforms. This library contains functionality
> to submit GPU workloads that should consume exactly a specific
> amount of time.
> 
> v2 : Add recursive batch feature from Chris
> v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
>  by adding a dummy reloc to the bo as suggested by Ville.
> 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: Chris Wilson 
> Signed-off-by: Abdiel Janulgue 
> ---
>  lib/Makefile.sources |   2 +
>  lib/igt.h|   1 +
>  lib/igt_dummyload.c  | 274 
> +++
>  lib/igt_dummyload.h  |  42 
>  4 files changed, 319 insertions(+)
>  create mode 100644 lib/igt_dummyload.c
>  create mode 100644 lib/igt_dummyload.h
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index e8e277b..7fc5ec2 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -75,6 +75,8 @@ lib_source_list =   \
>   igt_draw.h  \
>   igt_pm.c\
>   igt_pm.h\
> + igt_dummyload.c \
> + igt_dummyload.h \
>   uwildmat/uwildmat.h \
>   uwildmat/uwildmat.c \
>   $(NULL)
> diff --git a/lib/igt.h b/lib/igt.h
> index d751f24..a0028d5 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -32,6 +32,7 @@
>  #include "igt_core.h"
>  #include "igt_debugfs.h"
>  #include "igt_draw.h"
> +#include "igt_dummyload.h"
>  #include "igt_fb.h"
>  #include "igt_gt.h"
>  #include "igt_kms.h"
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> new file mode 100644
> index 000..d37a30b
> --- /dev/null
> +++ b/lib/igt_dummyload.c
> @@ -0,0 +1,274 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include "igt_dummyload.h"
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * SECTION:igt_dummyload
> + * @short_description: Library for submitting GPU workloads
> + * @title: Dummyload
> + * @include: igt.h
> + *
> + * A lot of igt testcases need some GPU workload to make sure a race window 
> is
> + * big enough. Unfortunately having a fixed amount of workload leads to
> + * spurious test failures or overtly long runtimes on some fast/slow 
> platforms.
> + * This library contains functionality to submit GPU workloads that should
> + * consume exactly a specific amount of time.
> + */
> +
> +#define NSEC_PER_SEC 10L
> +
> +#define gettid() syscall(__NR_gettid)
> +#define sigev_notify_thread_id _sigev_un._tid
> +
> +#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
> +#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> +
> +#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> +
> +static void
> +fill_object(struct drm_i915_gem_exec_object2 *obj, uint32_t gem_handle,
> + struct drm_i915_gem_relocation_entry *relocs, uint32_t count)
> +{
> + memset(obj, 0, sizeof(*obj));
> + obj->handle = gem_handle;
> + obj->relocation_count = count;
> + obj->relocs_ptr = (uintptr_t)relocs;
> +}
> +
> +static void
> +fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
> +uint32_t gem_handle, uint32_t offset,
> +uint32_t read_domains, uint32_t write_domains)
> +{
> + reloc->target_handle = gem_handle;
> + reloc->delta = 0;
> + reloc->offset = offset * sizeof(uint32_t);
> + reloc->presumed_offset = 0;
> + reloc->read_domains = read_domains;
> + reloc->write_domain = 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Tidy slab cache allocations (rev2)

[Tvrtko Ursulin]

On 02/11/2016 16:45, Patchwork wrote:

== Series Details ==

Series: drm/i915: Tidy slab cache allocations (rev2)
URL   : https://patchwork.freedesktop.org/series/14731/
State : warning

== Summary ==

Series 14731v2 drm/i915: Tidy slab cache allocations
https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)


Just LSPCON... https://bugs.freedesktop.org/show_bug.cgi?id=98353



fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20
fi-hsw-4770r total:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21
fi-ilk-650   total:241  pass:187  dwarn:0   dfail:0   fail:0   skip:54
fi-ivb-3520m total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23
fi-ivb-3770  total:241  pass:218  dwarn:0   dfail:0   fail:0   skip:23
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21
fi-skl-6770hqtotal:241  pass:226  dwarn:1   dfail:0   fail:0   skip:14
fi-snb-2520m total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33
fi-snb-2600  total:241  pass:207  dwarn:0   dfail:0   fail:0   skip:34

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
eb3aa67 drm/i915: Tidy slab cache allocations



Merged to dinq, thanks for the review!

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Remove engine->execlist_lock

[Tvrtko Ursulin]

On 03/11/2016 12:28, Chris Wilson wrote:

On Thu, Nov 03, 2016 at 10:47:54AM +, Tvrtko Ursulin wrote:


On 02/11/2016 17:50, Chris Wilson wrote:

@@ -600,9 +598,8 @@ static void intel_lrc_irq_handler(unsigned long data)
static void execlists_submit_request(struct drm_i915_gem_request *request)
{
struct intel_engine_cs *engine = request->engine;
-   unsigned long flags;

-   spin_lock_irqsave(>execlist_lock, flags);


Again I am confused why this wasn't just _bh.


We may be in hardirq context here (normally, from just i915, we are
not). At the very least irqs are disabled here making spin_unlock_bh()
veboten.


Blast, I thought softirq are a subset of hardirq. :) On looking at the 
code I see it is not implemented at all like that. Apart from sometimes. :)


Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/12] HACK drm/i915/scheduler: emulate a scheduler for guc

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up after every request to feed new commands into the GuC).


How big is the performance hit? :)

Regards,

Tvrtko


---
 drivers/gpu/drm/i915/i915_guc_submission.c | 83 ++
 drivers/gpu/drm/i915/i915_irq.c|  4 +-
 drivers/gpu/drm/i915/intel_lrc.c   |  3 --
 3 files changed, 75 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bab0c2fc3bce..601b8777d3fd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -469,7 +469,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
u32 freespace;
int ret;

-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
freespace = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size);
freespace -= gc->wq_rsvd;
if (likely(freespace >= wqi_size)) {
@@ -479,7 +479,7 @@ int i915_guc_wq_reserve(struct drm_i915_gem_request 
*request)
gc->no_wq_space++;
ret = -EAGAIN;
}
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);

return ret;
 }
@@ -491,9 +491,9 @@ void i915_guc_wq_unreserve(struct drm_i915_gem_request 
*request)

GEM_BUG_ON(READ_ONCE(gc->wq_rsvd) < wqi_size);

-   spin_lock(>wq_lock);
+   spin_lock_irq(>wq_lock);
gc->wq_rsvd -= wqi_size;
-   spin_unlock(>wq_lock);
+   spin_unlock_irq(>wq_lock);
 }

 /* Construct a Work Item and append it to the GuC's Work Queue */
@@ -658,6 +658,70 @@ static void i915_guc_submit(struct drm_i915_gem_request 
*rq)
spin_unlock(>wq_lock);
 }

+static bool i915_guc_dequeue(struct intel_engine_cs *engine)
+{
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *last = port[0].request;
+   unsigned long flags;
+   struct rb_node *rb;
+   bool submit = false;
+
+   spin_lock_irqsave(>timeline->lock, flags);
+   rb = engine->execlist_first;
+   while (rb) {
+   struct drm_i915_gem_request *cursor =
+   rb_entry(rb, typeof(*cursor), priotree.node);
+
+   if (last && cursor->ctx != last->ctx) {
+   if (port != engine->execlist_port)
+   break;
+
+   i915_gem_request_assign(>request, last);
+   dma_fence_enable_sw_signaling(>fence);
+   port++;
+   }
+
+   rb = rb_next(rb);
+   rb_erase(>priotree.node, >execlist_queue);
+   RB_CLEAR_NODE(>priotree.node);
+   cursor->priotree.priority = INT_MAX;
+
+   i915_guc_submit(cursor);
+   last = cursor;
+   submit = true;
+   }
+   if (submit) {
+   i915_gem_request_assign(>request, last);
+   dma_fence_enable_sw_signaling(>fence);
+   engine->execlist_first = rb;
+   }
+   spin_unlock_irqrestore(>timeline->lock, flags);
+
+   return submit;
+}
+
+static void i915_guc_irq_handler(unsigned long data)
+{
+   struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+   struct execlist_port *port = engine->execlist_port;
+   struct drm_i915_gem_request *rq;
+   bool submit;
+
+   do {
+   rq = port[0].request;
+   while (rq && i915_gem_request_completed(rq)) {
+   i915_gem_request_put(rq);
+   rq = port[1].request;
+   port[0].request = rq;
+   port[1].request = NULL;
+   }
+
+   submit = false;
+   if (!port[1].request)
+   submit = i915_guc_dequeue(engine);
+   } while (submit);
+}
+
 /*
  * Everything below here is concerned with setup & teardown, and is
  * therefore not part of the somewhat time-critical batch-submission
@@ -1524,16 +1588,13 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)

/* Take over from manual control of ELSP (execlists) */
for_each_engine(engine, dev_priv, id) {
-   engine->submit_request = i915_guc_submit;
-   engine->schedule = NULL;
+   tasklet_init(>irq_tasklet,
+i915_guc_irq_handler,
+(unsigned long)engine);

/* Replay the current set of previously submitted requests */
-   list_for_each_entry(request,
-   >timeline->requests, link) {
+   

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Remove engine->execlist_lock

[Chris Wilson]

On Thu, Nov 03, 2016 at 10:47:54AM +, Tvrtko Ursulin wrote:
> 
> On 02/11/2016 17:50, Chris Wilson wrote:
> >@@ -600,9 +598,8 @@ static void intel_lrc_irq_handler(unsigned long data)
> > static void execlists_submit_request(struct drm_i915_gem_request *request)
> > {
> > struct intel_engine_cs *engine = request->engine;
> >-unsigned long flags;
> >
> >-spin_lock_irqsave(>execlist_lock, flags);
> 
> Again I am confused why this wasn't just _bh.

We may be in hardirq context here (normally, from just i915, we are
not). At the very least irqs are disabled here making spin_unlock_bh()
veboten.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

[Chris Wilson]

On Thu, Nov 03, 2016 at 11:03:47AM +, Tvrtko Ursulin wrote:
> 
> On 02/11/2016 17:50, Chris Wilson wrote:
> >The scheduler needs to know the dependencies of each request for the
> >lifetime of the request, as it may choose to reschedule the requests at
> >any time and must ensure the dependency tree is not broken. This is in
> >additional to using the fence to only allow execution after all
> >dependencies have been completed.
> >
> >One option was to extend the fence to support the bidirectional
> >dependency tracking required by the scheduler. However the mismatch in
> >lifetimes between the submit fence and the request essentially meant
> >that we had to build a completely separate struct (and we could not
> >simply reuse the existing waitqueue in the fence for one half of the
> >dependency tracking). The extra dependency tracking simply did not mesh
> >well with the fence, and keeping it separate both keeps the fence
> >implementation simpler and allows us to extend the dependency tracking
> >into a priority tree (whilst maintaining support for reordering the
> >tree).
> >
> >To avoid the additional allocations and list manipulations, the use of
> >the priotree is disabled when there are no schedulers to use it.
> >
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/i915_gem_request.c | 72 
> > -
> > drivers/gpu/drm/i915/i915_gem_request.h | 23 +++
> > 2 files changed, 94 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index 9c8605c834f9..13090f226203 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -113,6 +113,59 @@ i915_gem_request_remove_from_client(struct 
> >drm_i915_gem_request *request)
> > spin_unlock(_priv->mm.lock);
> > }
> >
> >+static int
> >+i915_priotree_add_dependency(struct i915_priotree *pt,
> >+ struct i915_priotree *signal,
> >+ struct i915_dependency *dep)
> >+{
> >+unsigned long flags = 0;
> >+
> >+if (!dep) {
> >+dep = kmalloc(sizeof(*dep), GFP_KERNEL);
> 
> I will mention a dedicated cache again since this could possibly be
> our hottest allocation path. With a dedicated slab I've seen it grow
> to 5-7k objects in some benchmarks, with the request slab around 1k
> at the same time.

I'm open to one. We allocate more of these than we do even for fences. I
was thinking it could be added later, but if we can the api to always
pass in the i915_dependency it will probably work better.
> 
> >+if (!dep)
> >+return -ENOMEM;
> >+
> >+flags |= I915_DEPENDENCY_ALLOC;
> >+}
> 
> Not sure if it would be any nicer to just set the flags after
> allocating to I915_DEPENDENCY_ALLOC and add an else path to set it
> to zero here.

I just tend to avoid if {} else {} if I can help, just a personal
preference.

> >+struct i915_dependency {
> >+struct i915_priotree *signal;
> >+struct list_head pre_link, post_link;
> >+unsigned long flags;
> >+#define I915_DEPENDENCY_ALLOC BIT(0)
> >+};
> >+
> >+struct i915_priotree {
> >+struct list_head pre_list; /* who is before us, we depend upon */
> >+struct list_head post_list; /* who is after us, they depend upon us */
> >+};
> 
> I need a picture to imagine this data structure. :(

The names suck.

\|||/
 \|/
  .
 /|\
/|||\

Googling bidirectional acyclic graph doesn't help that much.

> >+
> > /**
> >  * Request queue structure.
> >  *
> >@@ -89,6 +101,17 @@ struct drm_i915_gem_request {
> > wait_queue_t submitq;
> > wait_queue_t execq;
> >
> >+/* A list of everyone we wait upon, and everyone who waits upon us.
> >+ * Even though we will not be submitted to the hardware before the
> >+ * submit fence is signaled (it waits for all external events as well
> >+ * as our own requests), the scheduler still needs to know the
> >+ * dependency tree for the lifetime of the request (from execbuf
> >+ * to retirement), i.e. bidirectional dependency information for the
> >+ * request not tied to individual fences.
> >+ */
> >+struct i915_priotree priotree;
> >+struct i915_dependency depq;
> 
> Why depq and not dep_node or something? Makes me wonder what am I
> missing about the "q". It is not a queue?!?

Just a pattern was forming. It's just a much of a queue as our
wait_queue_t above :) Point taken.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Defer transfer onto execution timeline to actual hw submission

[Chris Wilson]

On Thu, Nov 03, 2016 at 10:51:14AM +, Chris Wilson wrote:
> Yes. Worse is that the 2 comes from having different paths to this point
> with their own nesting pattern.

Not any more, that was a leftover from one version that managed to nest
signaling/execution.

The issue is 

__i915_gem_request_submit -> fence_signal(rq->execute)

Then if we hook the submit fence onto an earlier execute fence, we hit
submit_notify() and try to acquire the engine->timeline again.

Hindsight says we cannot control the recursion there, so don't hook up
the fences like that (submit is not allowed to listen to execute).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/12] drm/i915/scheduler: Record all dependencies upon request construction

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any time and must ensure the dependency tree is not broken. This is in
additional to using the fence to only allow execution after all
dependencies have been completed.

One option was to extend the fence to support the bidirectional
dependency tracking required by the scheduler. However the mismatch in
lifetimes between the submit fence and the request essentially meant
that we had to build a completely separate struct (and we could not
simply reuse the existing waitqueue in the fence for one half of the
dependency tracking). The extra dependency tracking simply did not mesh
well with the fence, and keeping it separate both keeps the fence
implementation simpler and allows us to extend the dependency tracking
into a priority tree (whilst maintaining support for reordering the
tree).

To avoid the additional allocations and list manipulations, the use of
the priotree is disabled when there are no schedulers to use it.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 72 -
 drivers/gpu/drm/i915/i915_gem_request.h | 23 +++
 2 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 9c8605c834f9..13090f226203 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -113,6 +113,59 @@ i915_gem_request_remove_from_client(struct 
drm_i915_gem_request *request)
spin_unlock(_priv->mm.lock);
 }

+static int
+i915_priotree_add_dependency(struct i915_priotree *pt,
+struct i915_priotree *signal,
+struct i915_dependency *dep)
+{
+   unsigned long flags = 0;
+
+   if (!dep) {
+   dep = kmalloc(sizeof(*dep), GFP_KERNEL);


I will mention a dedicated cache again since this could possibly be our 
hottest allocation path. With a dedicated slab I've seen it grow to 5-7k 
objects in some benchmarks, with the request slab around 1k at the same 
time.



+   if (!dep)
+   return -ENOMEM;
+
+   flags |= I915_DEPENDENCY_ALLOC;
+   }


Not sure if it would be any nicer to just set the flags after allocating 
to I915_DEPENDENCY_ALLOC and add an else path to set it to zero here.



+
+   dep->signal = signal;
+   dep->flags = flags;
+
+   list_add(>post_link, >post_list);
+   list_add(>pre_link, >pre_list);
+   return 0;
+}
+
+static void
+i915_priotree_fini(struct i915_priotree *pt)
+{
+   struct i915_dependency *dep, *next;
+
+   /* Everyone we depended upon should retire before us and remove
+* themselves from our list. However, retirement is run independently
+* on each timeline and so we may be called out-of-order.
+*/
+   list_for_each_entry_safe(dep, next, >pre_list, pre_link) {
+   list_del(>post_link);
+   if (dep->flags & I915_DEPENDENCY_ALLOC)
+   kfree(dep);
+   }
+
+   /* Remove ourselves from everyone who depends upon us */
+   list_for_each_entry_safe(dep, next, >post_list, post_link) {
+   list_del(>pre_link);
+   if (dep->flags & I915_DEPENDENCY_ALLOC)
+   kfree(dep);
+   }
+}
+
+static void
+i915_priotree_init(struct i915_priotree *pt)
+{
+   INIT_LIST_HEAD(>pre_list);
+   INIT_LIST_HEAD(>post_list);
+}
+
 void i915_gem_retire_noop(struct i915_gem_active *active,
  struct drm_i915_gem_request *request)
 {
@@ -182,6 +235,8 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
i915_gem_context_put(request->ctx);

dma_fence_signal(>fence);
+
+   i915_priotree_fini(>priotree);
i915_gem_request_put(request);
 }

@@ -464,6 +519,8 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
 */
i915_sw_fence_await_sw_fence(>execute, >submit, >execq);

+   i915_priotree_init(>priotree);
+
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
req->engine = engine;
@@ -517,6 +574,14 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,

GEM_BUG_ON(to == from);

+   if (to->engine->schedule) {
+   ret = i915_priotree_add_dependency(>priotree,
+  >priotree,
+  NULL);
+   if (ret < 0)
+   return ret;
+   }
+
if (to->timeline == from->timeline)
return 0;

@@ -740,9 +805,14 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)

prev = i915_gem_active_raw(>last_request,
  

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Introduce HAS_64BIT_RELOC (rev3)

[Joonas Lahtinen]

On to, 2016-11-03 at 09:16 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Introduce HAS_64BIT_RELOC (rev3)
> URL   : https://patchwork.freedesktop.org/series/14730/
> State : success
> 
> == Summary ==

Committing the patch, thanks for the review. 

As discussed in IRC, the obvious problem in rev2 was not caught so not
giving too much value to the all OK result.

Regards, Joonas

> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2897/
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Defer transfer onto execution timeline to actual hw submission

[Chris Wilson]

On Thu, Nov 03, 2016 at 10:34:26AM +, Tvrtko Ursulin wrote:
> 
> On 02/11/2016 17:50, Chris Wilson wrote:
> >Defer the transfer from the client's timeline onto the execution
> >timeline from the point of readiness to the point of actual submission.
> >For example, in execlists, a request is finally submitted to hardware
> >when the hardware is ready, and only put onto the hardware queue when
> >the request is ready. By deferring the transfer, we ensure that the
> >timeline is maintained in retirement order if we decide to queue the
> >requests onto the hardware in a different order than fifo.
> >
> >Signed-off-by: Chris Wilson 
> >---
> > drivers/gpu/drm/i915/i915_gem_request.c| 36 
> > ++
> > drivers/gpu/drm/i915/i915_gem_request.h|  2 ++
> > drivers/gpu/drm/i915/i915_guc_submission.c |  2 ++
> > drivers/gpu/drm/i915/intel_lrc.c   |  5 +
> > drivers/gpu/drm/i915/intel_ringbuffer.c|  2 ++
> > 5 files changed, 33 insertions(+), 14 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index 1ae5a2f8953f..05544dec5de9 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -307,25 +307,16 @@ static u32 timeline_get_seqno(struct i915_gem_timeline 
> >*tl)
> > return atomic_inc_return(>next_seqno);
> > }
> >
> >-static int __i915_sw_fence_call
> >-submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
> >+void __i915_gem_request_submit(struct drm_i915_gem_request *request)
> > {
> >-struct drm_i915_gem_request *request =
> >-container_of(fence, typeof(*request), submit);
> > struct intel_engine_cs *engine = request->engine;
> > struct intel_timeline *timeline;
> >-unsigned long flags;
> > u32 seqno;
> >
> >-if (state != FENCE_COMPLETE)
> >-return NOTIFY_DONE;
> >-
> > /* Transfer from per-context onto the global per-engine timeline */
> > timeline = engine->timeline;
> > GEM_BUG_ON(timeline == request->timeline);
> >-
> >-/* Will be called from irq-context when using foreign DMA fences */
> >-spin_lock_irqsave(>lock, flags);
> >+assert_spin_locked(>lock);
> >
> > seqno = timeline_get_seqno(timeline->common);
> > GEM_BUG_ON(!seqno);
> >@@ -345,15 +336,32 @@ submit_notify(struct i915_sw_fence *fence, enum 
> >i915_sw_fence_notify state)
> > GEM_BUG_ON(!request->global_seqno);
> > engine->emit_breadcrumb(request,
> > request->ring->vaddr + request->postfix);
> >-engine->submit_request(request);
> >
> >-spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING);
> >+/* nested from submit_notify */
> >+spin_lock_nested(>timeline->lock, 2);
> 
> Is this because lockdep does not differentiate between
> request->timeline->lock and engine->timeline->lock?

Yes. Worse is that the 2 comes from having different paths to this point
with their own nesting pattern.

struct timeline {
struct lock_class_key lockdep;
struct mutex mutex;
}

__mutex_init(>mutex, "timeline", >lockdep);

? (Hopefully that works w/o lockdep enabled)

Better then would be

i915_gem_timeline_create()
i915_gem_timeline_create_global()

and just use one lock class for all user timelines, and a lock class per
engine on the global timeline.

Will try.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/12] drm/i915/scheduler: Signal the arrival of a new request

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

The start of the scheduler, add a hook into request submission for the
scheduler to see the arrival of new requests and prepare its runqueues.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 
 drivers/gpu/drm/i915/i915_gem_request.c | 13 +
 drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 +
 include/uapi/drm/i915_drm.h |  5 +
 5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 79cea49183b3..5a0e885e6104 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -323,6 +323,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = i915_gem_mmap_gtt_version();
break;
+   case I915_PARAM_HAS_SCHEDULER:
+   value = dev_priv->engine[RCS] &&
+   dev_priv->engine[RCS]->schedule;
+   break;
case I915_PARAM_MMAP_VERSION:
/* Remember to bump this if the version changes! */
case I915_PARAM_HAS_GEM:
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 05544dec5de9..9c8605c834f9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -759,6 +759,19 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)

i915_gem_mark_busy(engine);

+   /* Let the backend know a new request has arrived that may need
+* to adjust the existing execution schedule due to a high priority
+* request - i.e. we may want to preempt the current request in order
+* to run a high priority dependency chain *before* we can execute this
+* request.
+*
+* This is called before the request is ready to run so that we can
+* decide whether to preempt the entire chain so that it is ready to
+* run at the earliest possible convenience.
+*/
+   if (engine->schedule)
+   engine->schedule(request, 0);
+
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 298f0f95dd3f..c9171a058478 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -102,6 +102,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;

+   /* Nothing to do here, execute in order of dependencies */
+   engine->schedule = NULL;
+
dev_priv->engine[id] = engine;
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 062bc8e1872a..75991a3c694b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -267,6 +267,15 @@ struct intel_engine_cs {
 */
void(*submit_request)(struct drm_i915_gem_request *req);

+   /* Call when the priority on a request has changed and it and its
+* dependencies may need rescheduling. Note the request itself may
+* not be ready to run!
+*
+* Called under the struct_mutex.
+*/
+   void(*schedule)(struct drm_i915_gem_request *request,
+   int priority);
+
/* Some chipsets are not quite as coherent as advertised and need
 * an expensive kick to force a true read of the up-to-date seqno.
 * However, the up-to-date seqno is not always required and the last
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 03725fe89859..1c12a350eca3 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -389,6 +389,11 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40

+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+ * priorities and the driver will attempt to execute batches in priority order.
+ */
+#define I915_PARAM_HAS_SCHEDULER41
+
 typedef struct drm_i915_getparam {
__s32 param;
/*



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Remove engine->execlist_lock

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

The execlist_lock is now completely subsumed by the engine->timeline->lock,
and so we can remove the redundant layer of locking.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c  | 1 -
 drivers/gpu/drm/i915/intel_lrc.c| 7 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
 5 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c9465fbff2df..3cb96d260dfb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3256,11 +3256,11 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
seq_printf(m, "\t\tELSP[1] idle\n");
rcu_read_unlock();

-   spin_lock_irq(>execlist_lock);


Hm why did we have this as _irq and not _bh already?


+   spin_lock_irq(>timeline->lock);
list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
print_request(m, rq, "\t\tQ ");
}
-   spin_unlock_irq(>execlist_lock);
+   spin_unlock_irq(>timeline->lock);
} else if (INTEL_GEN(dev_priv) > 6) {
seq_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
   I915_READ(RING_PP_DIR_BASE(engine)));
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5839bebba64a..cf28666021f8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2686,12 +2686,12 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)
 */

if (i915.enable_execlists) {
-   spin_lock(>execlist_lock);


Likewise should have been _bh here, never mind now. :)


+   spin_lock_irq(>timeline->lock);
INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
-   spin_unlock(>execlist_lock);
+   spin_unlock_irq(>timeline->lock);
}
 }

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 841f8d1e1410..298f0f95dd3f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -237,7 +237,6 @@ static void intel_engine_init_timeline(struct 
intel_engine_cs *engine)
 void intel_engine_setup_common(struct intel_engine_cs *engine)
 {
INIT_LIST_HEAD(>execlist_queue);
-   spin_lock_init(>execlist_lock);

intel_engine_init_timeline(engine);
intel_engine_init_hangcheck(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b9aba16851ac..186c3ccb2c34 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -471,7 +471,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 */

spin_lock_irqsave(>timeline->lock, flags);
-   spin_lock(>execlist_lock);
list_for_each_entry(cursor, >execlist_queue, execlist_link) {
/* Can we combine this request with the current port? It has to
 * be the same context/ringbuffer and not have any exceptions
@@ -515,7 +514,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)

i915_gem_request_assign(>request, last);
}
-   spin_unlock(>execlist_lock);
spin_unlock_irqrestore(>timeline->lock, flags);

if (submit)
@@ -600,9 +598,8 @@ static void intel_lrc_irq_handler(unsigned long data)
 static void execlists_submit_request(struct drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
-   unsigned long flags;

-   spin_lock_irqsave(>execlist_lock, flags);


Again I am confused why this wasn't just _bh.


+   assert_spin_locked(>timeline->lock);

/* We keep the previous context alive until we retire the following
 * request. This ensures that any the context object is still pinned
@@ -616,8 +613,6 @@ static void execlists_submit_request(struct 
drm_i915_gem_request *request)
list_add_tail(>execlist_link, >execlist_queue);
if (execlists_elsp_idle(engine))
tasklet_hi_schedule(>irq_tasklet);
-
-   spin_unlock_irqrestore(>execlist_lock, flags);
 }

 int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request 
*request)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 642b54692d0d..062bc8e1872a 100644
--- 

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Split request submit/execute phase into two

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

In order to support deferred scheduling, we need to differentiate
between when the request is ready to run (i.e. the submit fence is
signaled) and when the request is actually run (a new execute fence).
This is typically split between the request itself wanting to wait upon
others (for which we use the submit fence) and the CPU wanting to wait
upon the request, for which we use the execute fence to be sure the
hardware is ready to signal completion.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 33 -
 drivers/gpu/drm/i915/i915_gem_request.h |  2 ++
 2 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 79b0046d9a57..1ae5a2f8953f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -351,11 +351,19 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);

+   i915_sw_fence_commit(>execute);
+
spin_unlock_irqrestore(>lock, flags);

return NOTIFY_DONE;
 }

+static int __i915_sw_fence_call
+execute_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+   return NOTIFY_DONE;
+}
+
 /**
  * i915_gem_request_alloc - allocate a request structure
  *
@@ -441,6 +449,12 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
   __timeline_get_seqno(req->timeline->common));

i915_sw_fence_init(>submit, submit_notify);
+   i915_sw_fence_init(>execute, execute_notify);
+   /* Ensure that the execute fence completes after the submit fence -
+* as we complete the execute fence from within the submit fence
+* callback, its completion would otherwise be visible first.
+*/
+   i915_sw_fence_await_sw_fence(>execute, >submit, >execq);

INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
@@ -817,9 +831,9 @@ bool __i915_spin_request(const struct drm_i915_gem_request 
*req,
 }

 static long
-__i915_request_wait_for_submit(struct drm_i915_gem_request *request,
-  unsigned int flags,
-  long timeout)
+__i915_request_wait_for_execute(struct drm_i915_gem_request *request,
+   unsigned int flags,
+   long timeout)
 {
const int state = flags & I915_WAIT_INTERRUPTIBLE ?
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
@@ -831,9 +845,9 @@ __i915_request_wait_for_submit(struct drm_i915_gem_request 
*request,
add_wait_queue(q, );

do {
-   prepare_to_wait(>submit.wait, , state);
+   prepare_to_wait(>execute.wait, , state);

-   if (i915_sw_fence_done(>submit))
+   if (i915_sw_fence_done(>execute))
break;

if (flags & I915_WAIT_LOCKED &&
@@ -851,7 +865,7 @@ __i915_request_wait_for_submit(struct drm_i915_gem_request 
*request,

timeout = io_schedule_timeout(timeout);
} while (timeout);
-   finish_wait(>submit.wait, );
+   finish_wait(>execute.wait, );

if (flags & I915_WAIT_LOCKED)
remove_wait_queue(q, );
@@ -903,13 +917,14 @@ long i915_wait_request(struct drm_i915_gem_request *req,

trace_i915_gem_request_wait_begin(req);

-   if (!i915_sw_fence_done(>submit)) {
-   timeout = __i915_request_wait_for_submit(req, flags, timeout);
+   if (!i915_sw_fence_done(>execute)) {
+   timeout = __i915_request_wait_for_execute(req, flags, timeout);
if (timeout < 0)
goto complete;

-   GEM_BUG_ON(!i915_sw_fence_done(>submit));
+   GEM_BUG_ON(!i915_sw_fence_done(>execute));
}
+   GEM_BUG_ON(!i915_sw_fence_done(>submit));
GEM_BUG_ON(!req->global_seqno);

/* Optimistic short spin before touching IRQs */
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 75f8360b3421..ed13f37fea0f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -85,7 +85,9 @@ struct drm_i915_gem_request {
struct intel_signal_node signaling;

struct i915_sw_fence submit;
+   struct i915_sw_fence execute;
wait_queue_t submitq;
+   wait_queue_t execq;

u32 global_seqno;




Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Defer transfer onto execution timeline to actual hw submission

[Tvrtko Ursulin]

On 02/11/2016 17:50, Chris Wilson wrote:

Defer the transfer from the client's timeline onto the execution
timeline from the point of readiness to the point of actual submission.
For example, in execlists, a request is finally submitted to hardware
when the hardware is ready, and only put onto the hardware queue when
the request is ready. By deferring the transfer, we ensure that the
timeline is maintained in retirement order if we decide to queue the
requests onto the hardware in a different order than fifo.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c| 36 ++
 drivers/gpu/drm/i915/i915_gem_request.h|  2 ++
 drivers/gpu/drm/i915/i915_guc_submission.c |  2 ++
 drivers/gpu/drm/i915/intel_lrc.c   |  5 +
 drivers/gpu/drm/i915/intel_ringbuffer.c|  2 ++
 5 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 1ae5a2f8953f..05544dec5de9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -307,25 +307,16 @@ static u32 timeline_get_seqno(struct i915_gem_timeline 
*tl)
return atomic_inc_return(>next_seqno);
 }

-static int __i915_sw_fence_call
-submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+void __i915_gem_request_submit(struct drm_i915_gem_request *request)
 {
-   struct drm_i915_gem_request *request =
-   container_of(fence, typeof(*request), submit);
struct intel_engine_cs *engine = request->engine;
struct intel_timeline *timeline;
-   unsigned long flags;
u32 seqno;

-   if (state != FENCE_COMPLETE)
-   return NOTIFY_DONE;
-
/* Transfer from per-context onto the global per-engine timeline */
timeline = engine->timeline;
GEM_BUG_ON(timeline == request->timeline);
-
-   /* Will be called from irq-context when using foreign DMA fences */
-   spin_lock_irqsave(>lock, flags);
+   assert_spin_locked(>lock);

seqno = timeline_get_seqno(timeline->common);
GEM_BUG_ON(!seqno);
@@ -345,15 +336,32 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
GEM_BUG_ON(!request->global_seqno);
engine->emit_breadcrumb(request,
request->ring->vaddr + request->postfix);
-   engine->submit_request(request);

-   spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING);
+   /* nested from submit_notify */
+   spin_lock_nested(>timeline->lock, 2);


Is this because lockdep does not differentiate between 
request->timeline->lock and engine->timeline->lock?


Could we pass different lock classes to i915_gem_timeline_init and 
remove this deep nested annotation. Would be better I think.



list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);

i915_sw_fence_commit(>execute);
+}

-   spin_unlock_irqrestore(>lock, flags);
+static int __i915_sw_fence_call
+submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+   if (state == FENCE_COMPLETE) {
+   struct drm_i915_gem_request *request =
+   container_of(fence, typeof(*request), submit);
+   struct intel_engine_cs *engine = request->engine;
+   unsigned long flags;
+
+   /* Will be called from irq-context when using foreign fences,
+* and may be called from the execution callback of another
+* engine.
+*/
+   spin_lock_irqsave_nested(>timeline->lock, flags, 1);
+   engine->submit_request(request);
+   spin_unlock_irqrestore(>timeline->lock, flags);
+   }

return NOTIFY_DONE;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index ed13f37fea0f..725d04128eaf 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -228,6 +228,8 @@ void __i915_add_request(struct drm_i915_gem_request *req, 
bool flush_caches);
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, false)

+void __i915_gem_request_submit(struct drm_i915_gem_request *request);
+
 struct intel_rps_client;
 #define NO_WAITBOOST ERR_PTR(-1)
 #define IS_RPS_CLIENT(p) (!IS_ERR(p))
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 857ef914cae7..ddb574d5ceda 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -640,6 +640,8 @@ static void i915_guc_submit(struct drm_i915_gem_request *rq)
struct i915_guc_client *client = guc->execbuf_client;
int b_ret;

+   __i915_gem_request_submit(rq);
+
spin_lock(>wq_lock);
guc_wq_item_append(client, rq);

diff --git 

Re: [Intel-gfx] [PATCH] drm/i915: Fix pages pin counting around swizzle quirk

[Chris Wilson]

On Wed, Nov 02, 2016 at 09:43:54AM +, Chris Wilson wrote:
> commit bc0629a76726 ("drm/i915: Track pages pinned due to swizzling
> quirk") fixed one problem, but revealed a whole lot more. The root cause
> of the pin count mismatch for the swizzle quirk (for L-shaped memory on
> gen3/4) was that we were incrementing the pages_pin_count upon getting
> the backing pages but then overwriting the pages_pin_count to set it to
> 1 afterwards. With a little bit of adjustment to satisfy the GEM_BUG_ON
> sanitychecks, the fix is to replace the explicit atomic_set with an
> atomic_inc.
> 
> Fixes: 1233e2db199d ("drm/i915: Move object backing storage manipulation")
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Tvrtko Ursulin 

Ping?

> ---
>  drivers/gpu/drm/i915/i915_gem.c| 40 
> ++
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  1 +
>  drivers/gpu/drm/i915/i915_gem_tiling.c |  1 +
>  3 files changed, 23 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 993fb90da104..5fe7562aefbd 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2386,12 +2386,6 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>   if (i915_gem_object_needs_bit17_swizzle(obj))
>   i915_gem_object_do_bit_17_swizzle(obj, st);
>  
> - if (i915_gem_object_is_tiled(obj) &&
> - dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
> - __i915_gem_object_pin_pages(obj);
> - obj->mm.quirked = true;
> - }
> -
>   return st;
>  
>  err_pages:
> @@ -2424,6 +2418,13 @@ void __i915_gem_object_set_pages(struct 
> drm_i915_gem_object *obj,
>   obj->mm.get_page.sg_idx = 0;
>  
>   obj->mm.pages = pages;
> +
> + if (i915_gem_object_is_tiled(obj) &&
> + to_i915(obj->base.dev)->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
> + GEM_BUG_ON(obj->mm.quirked);
> + __i915_gem_object_pin_pages(obj);
> + obj->mm.quirked = true;
> + }
>  }
>  
>  static int i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> @@ -2458,17 +2459,16 @@ int __i915_gem_object_get_pages(struct 
> drm_i915_gem_object *obj)
>   if (err)
>   return err;
>  
> - if (likely(obj->mm.pages)) {
> - __i915_gem_object_pin_pages(obj);
> - goto unlock;
> - }
> -
> - GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> + if (unlikely(!obj->mm.pages)) {
> + GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> + err = i915_gem_object_get_pages(obj);
> + if (err)
> + goto unlock;
>  
> - err = i915_gem_object_get_pages(obj);
> - if (!err)
> - atomic_set_release(>mm.pages_pin_count, 1);
> + smp_mb__before_atomic();
> + }
>  
> + __i915_gem_object_pin_pages(obj);
>  unlock:
>   mutex_unlock(>mm.lock);
>   return err;
> @@ -2542,8 +2542,8 @@ void *i915_gem_object_pin_map(struct 
> drm_i915_gem_object *obj,
>   if (ret)
>   goto err_unlock;
>  
> - GEM_BUG_ON(atomic_read(>mm.pages_pin_count));
> - atomic_set_release(>mm.pages_pin_count, 1);
> + smp_mb__before_atomic();
> + __i915_gem_object_pin_pages(obj);
>   pinned = false;
>   }
>   GEM_BUG_ON(!obj->mm.pages);
> @@ -2578,7 +2578,7 @@ void *i915_gem_object_pin_map(struct 
> drm_i915_gem_object *obj,
>   return ptr;
>  
>  err_unpin:
> - atomic_dec(>mm.pages_pin_count);
> + __i915_gem_object_unpin_pages(obj);
>  err_unlock:
>   ptr = ERR_PTR(ret);
>   goto out_unlock;
> @@ -2996,7 +2996,7 @@ int i915_vma_unbind(struct i915_vma *vma)
>   goto destroy;
>  
>   GEM_BUG_ON(obj->bind_count == 0);
> - GEM_BUG_ON(!obj->mm.pages);
> + GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
>  
>   if (i915_vma_is_map_and_fenceable(vma)) {
>   /* release the fence reg _after_ flushing */
> @@ -3230,6 +3230,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> alignment, u64 flags)
>   list_move_tail(>global_list, _priv->mm.bound_list);
>   list_move_tail(>vm_link, >vm->inactive_list);
>   obj->bind_count++;
> + GEM_BUG_ON(atomic_read(>mm.pages_pin_count) < obj->bind_count);
>  
>   return 0;
>  
> @@ -4282,6 +4283,7 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void 
> *data,
>   obj->mm.quirked = false;
>   }
>   if (args->madv == I915_MADV_WILLNEED) {
> + GEM_BUG_ON(obj->mm.quirked);
>   __i915_gem_object_pin_pages(obj);
>   obj->mm.quirked = true;
>   }
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> 

[Intel-gfx] [PATCH v3 3/3] igt/kms_flip: Use new igt_spin_batch

[Abdiel Janulgue]

Cc: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Abdiel Janulgue 
---
 tests/kms_flip.c | 185 ++-
 1 file changed, 4 insertions(+), 181 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6a1549e..79cb783 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -191,109 +191,6 @@ static unsigned long gettime_us(void)
return ts.tv_sec * 100 + ts.tv_nsec / 1000;
 }
 
-static int calibrate_dummy_load(struct test_output *o,
-   const char *ring_name,
-   int (*emit)(struct test_output *o, int limit, 
int timeout))
-{
-   unsigned long start;
-   int ops = 1;
-
-   start = gettime_us();
-
-   do {
-   unsigned long diff;
-   int ret;
-
-   ret = emit(o, (ops+1)/2, 10);
-   diff = gettime_us() - start;
-
-   if (ret || diff / USEC_PER_SEC >= 1)
-   break;
-
-   ops += ops;
-   } while (ops < 10);
-
-   igt_debug("%s dummy load calibrated: %d operations / second\n",
- ring_name, ops);
-
-   return ops;
-}
-
-static void blit_copy(drm_intel_bo *dst, drm_intel_bo *src,
- unsigned int width, unsigned int height,
- unsigned int dst_pitch, unsigned int src_pitch)
-{
-   BLIT_COPY_BATCH_START(0);
-   OUT_BATCH((3 << 24) | /* 32 bits */
- (0xcc << 16) | /* copy ROP */
- dst_pitch);
-   OUT_BATCH(0 << 16 | 0);
-   OUT_BATCH(height << 16 | width);
-   OUT_RELOC_FENCED(dst, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 
0);
-   OUT_BATCH(0 << 16 | 0);
-   OUT_BATCH(src_pitch);
-   OUT_RELOC_FENCED(src, I915_GEM_DOMAIN_RENDER, 0, 0);
-   ADVANCE_BATCH();
-
-   if (batch->gen >= 6) {
-   BEGIN_BATCH(3, 0);
-   OUT_BATCH(XY_SETUP_CLIP_BLT_CMD);
-   OUT_BATCH(0);
-   OUT_BATCH(0);
-   ADVANCE_BATCH();
-   }
-}
-
-static int _emit_dummy_load__bcs(struct test_output *o, int limit, int timeout)
-{
-   int i, ret = 0;
-   drm_intel_bo *src_bo, *dst_bo, *fb_bo;
-   struct igt_fb *fb_info = >fb_info[o->current_fb_id];
-
-   igt_require(bufmgr);
-
-   src_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(src_bo);
-
-   dst_bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(dst_bo);
-
-   fb_bo = gem_handle_to_libdrm_bo(bufmgr, drm_fd, "imported", 
fb_info->gem_handle);
-   igt_assert(fb_bo);
-
-   for (i = 0; i < limit; i++) {
-   blit_copy(dst_bo, src_bo,
- 2048, 2048,
- 2048*4, 2048*4);
-
-   igt_swap(src_bo, dst_bo);
-   }
-   blit_copy(fb_bo, src_bo,
- min(o->fb_width, 2048), min(o->fb_height, 2048),
- fb_info->stride, 2048*4);
-   intel_batchbuffer_flush(batch);
-
-   if (timeout > 0)
-   ret = drm_intel_gem_bo_wait(fb_bo, timeout * NSEC_PER_SEC);
-
-   drm_intel_bo_unreference(src_bo);
-   drm_intel_bo_unreference(dst_bo);
-   drm_intel_bo_unreference(fb_bo);
-
-   return ret;
-}
-
-static void emit_dummy_load__bcs(struct test_output *o, int seconds)
-{
-   static int ops_per_sec;
-
-   if (ops_per_sec == 0)
-   ops_per_sec = calibrate_dummy_load(o, "bcs",
-  _emit_dummy_load__bcs);
-
-   _emit_dummy_load__bcs(o, seconds * ops_per_sec, 0);
-}
-
 static void emit_fence_stress(struct test_output *o)
 {
const int num_fences = gem_available_fences(drm_fd);
@@ -338,82 +235,6 @@ static void emit_fence_stress(struct test_output *o)
free(exec);
 }
 
-static int _emit_dummy_load__rcs(struct test_output *o, int limit, int timeout)
-{
-   const struct igt_fb *fb_info = >fb_info[o->current_fb_id];
-   igt_render_copyfunc_t copyfunc;
-   struct igt_buf sb[3], *src, *dst, *fb;
-   int i, ret = 0;
-
-   igt_require(bufmgr);
-
-   copyfunc = igt_get_render_copyfunc(devid);
-   if (copyfunc == NULL)
-   return _emit_dummy_load__bcs(o, limit, timeout);
-
-   sb[0].bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(sb[0].bo);
-   sb[0].size = sb[0].bo->size;
-   sb[0].tiling = I915_TILING_NONE;
-   sb[0].data = NULL;
-   sb[0].num_tiles = sb[0].bo->size;
-   sb[0].stride = 4 * 2048;
-
-   sb[1].bo = drm_intel_bo_alloc(bufmgr, "dummy_bo", 2048*2048*4, 4096);
-   igt_assert(sb[1].bo);
-   sb[1].size = sb[1].bo->size;
-   sb[1].tiling = I915_TILING_NONE;
-   sb[1].data = NULL;
-   sb[1].num_tiles = sb[1].bo->size;
-   sb[1].stride = 4 * 2048;
-
-   sb[2].bo = 

[Intel-gfx] [PATCH v3 2/3] igt/gem_wait: Use new igt_spin_batch

[Abdiel Janulgue]

Cc: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Abdiel Janulgue 
---
 tests/gem_wait.c | 125 ---
 1 file changed, 7 insertions(+), 118 deletions(-)

diff --git a/tests/gem_wait.c b/tests/gem_wait.c
index b4127de..785bb14 100644
--- a/tests/gem_wait.c
+++ b/tests/gem_wait.c
@@ -27,18 +27,6 @@
 
 #include "igt.h"
 
-#include 
-#include 
-#include 
-
-#define gettid() syscall(__NR_gettid)
-#define sigev_notify_thread_id _sigev_un._tid
-
-#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
-#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
-
-#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
-
 static int __gem_wait(int fd, struct drm_i915_gem_wait *w)
 {
int err;
@@ -75,14 +63,6 @@ static void invalid_buf(int fd)
igt_assert_eq(__gem_wait(fd, ), -ENOENT);
 }
 
-static uint32_t *batch;
-
-static void sigiter(int sig, siginfo_t *info, void *arg)
-{
-   *batch = MI_BATCH_BUFFER_END;
-   __sync_synchronize();
-}
-
 #define MSEC_PER_SEC (1000)
 #define USEC_PER_SEC (1000 * MSEC_PER_SEC)
 #define NSEC_PER_SEC (1000 * USEC_PER_SEC)
@@ -91,113 +71,26 @@ static void sigiter(int sig, siginfo_t *info, void *arg)
 #define HANG 2
 static void basic(int fd, unsigned engine, unsigned flags)
 {
-   const int gen = intel_gen(intel_get_drm_devid(fd));
-   struct drm_i915_gem_exec_object2 obj;
-   struct drm_i915_gem_relocation_entry reloc;
-   struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_wait wait;
-   unsigned engines[16];
-   unsigned nengine;
-   int i, timeout;
-
-   nengine = 0;
-   if (engine == -1) {
-   for_each_engine(fd, engine)
-   if (engine) engines[nengine++] = engine;
-   } else {
-   igt_require(gem_has_ring(fd, engine));
-   engines[nengine++] = engine;
-   }
-   igt_require(nengine);
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = (uintptr_t)
-   execbuf.buffer_count = 1;
-
-   memset(, 0, sizeof(obj));
-   obj.handle = gem_create(fd, 4096);
-
-   obj.relocs_ptr = (uintptr_t)
-   obj.relocation_count = 1;
-   memset(, 0, sizeof(reloc));
-
-   batch = gem_mmap__gtt(fd, obj.handle, 4096, PROT_WRITE);
-   gem_set_domain(fd, obj.handle,
-   I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
-
-   reloc.target_handle = obj.handle; /* recurse */
-   reloc.presumed_offset = 0;
-   reloc.offset = sizeof(uint32_t);
-   reloc.delta = 0;
-   reloc.read_domains = I915_GEM_DOMAIN_COMMAND;
-   reloc.write_domain = 0;
-
-   i = 0;
-   batch[i] = MI_BATCH_BUFFER_START;
-   if (gen >= 8) {
-   batch[i] |= 1 << 8 | 1;
-   batch[++i] = 0;
-   batch[++i] = 0;
-   } else if (gen >= 6) {
-   batch[i] |= 1 << 8;
-   batch[++i] = 0;
-   } else {
-   batch[i] |= 2 << 6;
-   batch[++i] = 0;
-   if (gen < 4) {
-   batch[i] |= 1;
-   reloc.delta = 1;
-   }
-   }
-
-   for (i = 0; i < nengine; i++) {
-   execbuf.flags &= ~ENGINE_MASK;
-   execbuf.flags |= engines[i];
-   gem_execbuf(fd, );
-   }
+   int wait_s = (flags == 0) ? NSEC_PER_SEC : 0;
+   wait_s = ((flags & HANG) == 0) ? wait_s : -1;
+   igt_spin_t spin = igt_spin_batch(fd, wait_s, engine, 0);
+   int timeout;
 
memset(, 0, sizeof(wait));
-   wait.bo_handle = obj.handle;
-   igt_assert_eq(__gem_wait(fd, ), -ETIME);
+   wait.bo_handle = spin.handle;
 
if (flags & BUSY) {
struct timespec tv;
 
timeout = 120;
-   if ((flags & HANG) == 0) {
-   *batch = MI_BATCH_BUFFER_END;
-   __sync_synchronize();
+   if ((flags & HANG) == 0)
timeout = 1;
-   }
 
memset(, 0, sizeof(tv));
while (__gem_wait(fd, ) == -ETIME)
igt_assert(igt_seconds_elapsed() < timeout);
} else {
-   timer_t timer;
-
-   if ((flags & HANG) == 0) {
-   struct sigevent sev;
-   struct sigaction act;
-   struct itimerspec its;
-
-   memset(, 0, sizeof(sev));
-   sev.sigev_notify = SIGEV_SIGNAL | SIGEV_THREAD_ID;
-   sev.sigev_notify_thread_id = gettid();
-   sev.sigev_signo = SIGRTMIN + 1;
-   igt_assert(timer_create(CLOCK_MONOTONIC, , ) 
== 0);
-
-   memset(, 0, sizeof(act));
-   act.sa_sigaction = sigiter;
-   act.sa_flags = 

[Intel-gfx] [PATCH v3 1/3] lib: add igt_dummyload

[Abdiel Janulgue]

A lot of igt testcases need some GPU workload to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overtly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that should consume exactly a specific
amount of time.

v2 : Add recursive batch feature from Chris
v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
 by adding a dummy reloc to the bo as suggested by Ville.

Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Signed-off-by: Abdiel Janulgue 
---
 lib/Makefile.sources |   2 +
 lib/igt.h|   1 +
 lib/igt_dummyload.c  | 274 +++
 lib/igt_dummyload.h  |  42 
 4 files changed, 319 insertions(+)
 create mode 100644 lib/igt_dummyload.c
 create mode 100644 lib/igt_dummyload.h

diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index e8e277b..7fc5ec2 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -75,6 +75,8 @@ lib_source_list = \
igt_draw.h  \
igt_pm.c\
igt_pm.h\
+   igt_dummyload.c \
+   igt_dummyload.h \
uwildmat/uwildmat.h \
uwildmat/uwildmat.c \
$(NULL)
diff --git a/lib/igt.h b/lib/igt.h
index d751f24..a0028d5 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -32,6 +32,7 @@
 #include "igt_core.h"
 #include "igt_debugfs.h"
 #include "igt_draw.h"
+#include "igt_dummyload.h"
 #include "igt_fb.h"
 #include "igt_gt.h"
 #include "igt_kms.h"
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
new file mode 100644
index 000..d37a30b
--- /dev/null
+++ b/lib/igt_dummyload.c
@@ -0,0 +1,274 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "igt_dummyload.h"
+#include 
+#include 
+#include 
+
+/**
+ * SECTION:igt_dummyload
+ * @short_description: Library for submitting GPU workloads
+ * @title: Dummyload
+ * @include: igt.h
+ *
+ * A lot of igt testcases need some GPU workload to make sure a race window is
+ * big enough. Unfortunately having a fixed amount of workload leads to
+ * spurious test failures or overtly long runtimes on some fast/slow platforms.
+ * This library contains functionality to submit GPU workloads that should
+ * consume exactly a specific amount of time.
+ */
+
+#define NSEC_PER_SEC 10L
+
+#define gettid() syscall(__NR_gettid)
+#define sigev_notify_thread_id _sigev_un._tid
+
+#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
+#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+
+#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
+static void
+fill_object(struct drm_i915_gem_exec_object2 *obj, uint32_t gem_handle,
+   struct drm_i915_gem_relocation_entry *relocs, uint32_t count)
+{
+   memset(obj, 0, sizeof(*obj));
+   obj->handle = gem_handle;
+   obj->relocation_count = count;
+   obj->relocs_ptr = (uintptr_t)relocs;
+}
+
+static void
+fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
+  uint32_t gem_handle, uint32_t offset,
+  uint32_t read_domains, uint32_t write_domains)
+{
+   reloc->target_handle = gem_handle;
+   reloc->delta = 0;
+   reloc->offset = offset * sizeof(uint32_t);
+   reloc->presumed_offset = 0;
+   reloc->read_domains = read_domains;
+   reloc->write_domain = write_domains;
+}
+
+
+static uint32_t *batch;
+
+static uint32_t emit_recursive_batch(int fd, int engine, unsigned dep_handle)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry 

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Add pipe scaler for Gen9 in atomic path

[Maiti, Nabendu Bikash]

Hi,

Please review the patches and comments.


On 10/28/2016 6:05 PM, Nabendu Maiti wrote:

Attaching old discussion thread for easy reference.

On Tue, Jan 05, 2016 at 05:18:40PM +0200, Ville Syrjälä wrote:


On Tue, Jan 05, 2016 at 03:50:38PM +0100, Daniel Vetter wrote:



> On Mon, Jan 04, 2016 at 07:06:15PM +0200, Ville Syrjälä wrote:



> > On Mon, Jan 04, 2016 at 11:16:39AM +0100, Maarten Lankhorst wrote:



> > > Hey,



> > >



> > > Op 23-12-15 om 12:05 schreef Nabendu Maiti:



> > > > This patch is adding pipesource size as property as intel



> > > > property.User application is allowed to change the pipe source

size in runtime on BXT/SKL.


> > > > Added the property as inteli crtc property.



> > > >



> > > > Comments and suggestions are requested for whether we can keep



> > > > the property as intel crtc property or move to drm level.



> > > >



> > > This property would get lost on a modeset. But why do you need a

pipe_src property?


> >



> > It's needed if we want to use the panel fitter with



> > non-eDP/LVDS/DSI displays.



> >



> > Last time this came up I decided that we want to expose this via a



> > new "fixed_mode" property. Ie. userspace can choose the actual



> > display timings by setting the "fixed_mode" property with a



> > specific mode, and then the normal mode property will basically



> > just control just the pipe src size just like it already does for



> > eDP/LVDS/DSI where we already have the fixed_mode internally (just



> > not exposed to usersapce). If the fixed_mode is not specified,



> > things will work just as they do right now. Obviously for



> > eDP/LVDS/DSI we will reject any request to change/unset the fixed

mode.


> >



> > The benefit of that approach is that things will work exactly the



> > same way as before unless the user explicitly sets the fixed_mode,



> > and once it's set thigns will work exactly the same way as they



> > have worked so far for eDP/LVDS/DSI. Also it keeps the policy of



> > choosing the fixed mode strictly is userspace for external displays.



> >



> > And as a bonus we will also expose the eDP/LVDS/DSI fixed_mode to



> > userspace giving userspace more information on what the actual



> > panel timings are. Currently userspace has to more or less guess



> > that one of the modes the connector claims to support has the



> > actual panel timings.



> >



> > So far I've not heard any opposing opinions to this plan.



>



> Hm yeah, pipe_src would run into all kinds of fun in conjunction



> with the existing fixed mode stuff we have. Just exposing the fixed



> as a prop might be simpler. But then we need to figure out what to



> do wrt the clock in the mode passed in through userspace - currently



> the fixed mode always wins, but for manual DRRS it would be nice if



> userspace could control it, and doesn't have to know that there's a

fixed_mode.






We could have the user mode vrefresh indicate the desired refresh rate



of the fixed mode as well. In fact I've been wanting to add a check to



make sure the user mode refresh rate isn't too far off from the



fixed/downlclock mode vrefresh, but didn't get around to it yet.




Yeah agreed, userspace vrefresh should control (or at least be checked

against) the fixed mode vrefresh.




> So semantically I think only exposing the pipe src to expose panel



> fitters would be cleaner. Then we'd need to deal with some internal



> troubles to make sure we combine everything correctly, but that



> shouldn't be too hard really.







I think it's quite a bit more work since we have to redo all the fb



size checks and whatnot to use the property when specified. I once



outlined a more detailed plan for his approach too (too lazy to dig up



the mail), but I think the fixed mode prop is a simpler approach and



won't actually require much in the way of userspace changes either.



It'll be enough to set the property once and then even the legacy



modeset ioctls will work exactly like they do now for eDP/LVDS/DSI.




One downside of the fixed mode against an explicit pipe src rectangle is
that the explict rectangle allows us to letter/pillar/stretch/move too.

With just a fixed_mode that's much harder to pull off.



I think for i915 it should be fairly ok-ish to implement this. We just
need to move pipe src rectangle to drm_crtc_state, and adjust all the
pfit config logic to work on the pipe level. Panels would then only
replace the output mode with the fixed panel mode, and leave
scaling/pfit selection to the core crtc code.

-Daniel

--

Daniel Vetter

Software Engineer, Intel Corporation

http://blog.ffwll.ch

___

Intel-gfx mailing list

Intel-gfx@lists.freedesktop.org 

http://lists.freedesktop.org/mailman/listinfo/intel-gfx

..>
On 10/03/2016 04:57 PM, Ville Syrjälä wrote:

On Wed, Sep 21, 2016 at 07:47:37PM 

Re: [Intel-gfx] [RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections

[Paul Bolle]

On Thu, 2016-11-03 at 02:16 -0700, Joe Perches wrote:
> Yes, it's been reported and should be fixed in -mm.
> The fix should show up in -next in a little bit.

Great.

> For now, try:
> $ sed -i -e 's/\xA0/ /g' scripts/get_maintainer.pl

Thanks,


Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections

[Joe Perches]

On Thu, 2016-11-03 at 10:07 +0100, Paul Bolle wrote:
> On Mon, 2016-10-24 at 11:05 -0700, Joe Perches wrote:
> > Jani Nikula proposes patches to add a few new letter prefixes
> > for "B:" bug reporting and "C:" maintainer chatting to the
> > various sections of MAINTAINERS.
> > 
> > Add a generic mechanism to get_maintainer.pl to find sections that
> > have any combination of "[A-Z]" letter prefix types in a section.
> > 
> > Signed-off-by: Joe Perches 
> 
> This patch made it into linux-next (ie, next-20161028).
> 
> > --- a/scripts/get_maintainer.pl
> > +++ b/scripts/get_maintainer.pl
> > @@ -271,7 +273,8 @@ $output_multiline = 0 if ($output_separator ne ", ");
> >  $output_rolestats = 1 if ($interactive);
> >  $output_roles = 1 if ($output_rolestats);
> >  
> > -if ($sections) {
> > +if ($sections || $letters ne "") {
> > +$sections = 1;
> 
> This triggers:
>     Unrecognized character \xA0; marked by <-- HERE after <-- HERE near 
> column 1 at ./scripts/get_maintainer.pl line 277.
> 
> Git blame shows:
>     git blame -L 277,+1 ./scripts/get_maintainer.pl
> b67071653d3fc (Joe Perches 2016-10-28 13:22:01 +1100 277) 
> $sections = 1;
> 
> (A0 seems to be the no break space. That character was inserted more
> often further down the patch.)
> 
> Anybody else seeing this?

Yes, it's been reported and should be fixed in -mm.
The fix should show up in -next in a little bit.

For now, try:
$ sed -i -e 's/\xA0/ /g' scripts/get_maintainer.pl

cheers, Joe

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Introduce HAS_64BIT_RELOC (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Introduce HAS_64BIT_RELOC (rev3)
URL   : https://patchwork.freedesktop.org/series/14730/
State : success

== Summary ==

Series 14730v3 drm/i915: Introduce HAS_64BIT_RELOC
https://patchwork.freedesktop.org/api/1.0/series/14730/revisions/3/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-hsw-4770r)
skip   -> PASS   (fi-snb-2520m)
skip   -> PASS   (fi-ilk-650)
skip   -> PASS   (fi-ivb-3520m)
skip   -> PASS   (fi-snb-2600)
skip   -> PASS   (fi-ivb-3770)

fi-bdw-5557u total:241  pass:226  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:241  pass:201  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:241  pass:213  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:241  pass:221  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:241  pass:188  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:241  pass:219  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:241  pass:220  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:241  pass:219  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:241  pass:227  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:241  pass:209  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:241  pass:208  dwarn:0   dfail:0   fail:0   skip:33 

bf6b989af8b0fde56a352d9005c97b2d8e3bbbe3 drm-intel-nightly: 
2016y-11m-02d-15h-44m-03s UTC integration manifest
c5f2902 drm/i915: Introduce HAS_64BIT_RELOC

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2897/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections

[Paul Bolle]

On Mon, 2016-10-24 at 11:05 -0700, Joe Perches wrote:
> Jani Nikula proposes patches to add a few new letter prefixes
> for "B:" bug reporting and "C:" maintainer chatting to the
> various sections of MAINTAINERS.
> 
> Add a generic mechanism to get_maintainer.pl to find sections that
> have any combination of "[A-Z]" letter prefix types in a section.
> 
> Signed-off-by: Joe Perches 

This patch made it into linux-next (ie, next-20161028).

> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl

> @@ -271,7 +273,8 @@ $output_multiline = 0 if ($output_separator ne ", ");
>  $output_rolestats = 1 if ($interactive);
>  $output_roles = 1 if ($output_rolestats);
>  
> -if ($sections) {
> +if ($sections || $letters ne "") {
> +$sections = 1;

This triggers:
    Unrecognized character \xA0; marked by <-- HERE after <-- HERE near column 
1 at ./scripts/get_maintainer.pl line 277.

Git blame shows:
    git blame -L 277,+1 ./scripts/get_maintainer.pl
b67071653d3fc (Joe Perches 2016-10-28 13:22:01 +1100 277) 
$sections = 1;

(A0 seems to be the no break space. That character was inserted more
often further down the patch.)

Anybody else seeing this?


Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

[Chris Wilson]

On Thu, Nov 03, 2016 at 08:33:58AM +, Tvrtko Ursulin wrote:
> On 02/11/2016 17:34, Chris Wilson wrote:
> >It looks ok, but I just don't see the point. wq->flags is private to the
> >wq->func callback.
> 
> A very superficial skim shows that wake_up_common at least looks at
> the flags. So I thought, as long as wake_up_something gets called
> form somewhere on these ones, it would be safer not to potentially
> silently collide with some core flag.
> 
> Or are you saying no one ever touches them outside i915_sw_fence.c ?

That would break the encapsulation of the waitqueue being inside the
fence. I was not intending for people to call wake_up_all(fence.wait),
kfence_wake_up_all() [bad name, I was trying to borrow the concept from
wake_up_all() but it is not the same, it is for the completion of a
deferred signal notify] completes the fence in addition to signaling its
waiters.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Introduce HAS_64BIT_RELOC

[Chris Wilson]

On Thu, Nov 03, 2016 at 10:39:46AM +0200, Joonas Lahtinen wrote:
> Move has_64bit_reloc into dev_priv->info. This will make it visible
> in the feature listing debug output.
> 
> v2:
> - Keep the struct member to keep GCC fragile but happy (Chris)
> v3:
> - More detailed commit message (Chris)
> - Include forgotten CHV and BXT (Chris)
> 
> Cc: Chris Wilson 
> Signed-off-by: Joonas Lahtinen 

Reviewed-by: Chris Wilson 

If I haven't written a BAT test case to detect the fallout from v2,
please ping me with a baseball bat later.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915: Introduce HAS_64BIT_RELOC

[Joonas Lahtinen]

Move has_64bit_reloc into dev_priv->info. This will make it visible
in the feature listing debug output.

v2:
- Keep the struct member to keep GCC fragile but happy (Chris)
v3:
- More detailed commit message (Chris)
- Include forgotten CHV and BXT (Chris)

Cc: Chris Wilson 
Signed-off-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 3 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 3 ++-
 drivers/gpu/drm/i915/i915_gem_render_state.c | 3 +--
 drivers/gpu/drm/i915/i915_pci.c  | 5 -
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eaa01da..ae0217d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -670,6 +670,7 @@ struct intel_csr {
func(is_kabylake); \
func(is_preliminary); \
/* Keep has_* in alphabetical order */ \
+   func(has_64bit_reloc); \
func(has_csr); \
func(has_ddi); \
func(has_dp_mst); \
@@ -2917,6 +2918,8 @@ struct drm_i915_cmd_table {
 #define HAS_CSR(dev)   (INTEL_INFO(dev)->has_csr)
 
 #define HAS_RUNTIME_PM(dev_priv) ((dev_priv)->info.has_runtime_pm)
+#define HAS_64BIT_RELOC(dev_priv) ((dev_priv)->info.has_64bit_reloc)
+
 /*
  * For now, anything with a GuC requires uCode loading, and then supports
  * command submission once loaded. But these are logically independent
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c35e847..322c580 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -331,7 +331,8 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->page = -1;
cache->vaddr = 0;
cache->i915 = i915;
-   cache->use_64bit_reloc = INTEL_GEN(cache->i915) >= 8;
+   /* Must be a variable in the struct to allow GCC to unroll. */
+   cache->use_64bit_reloc = HAS_64BIT_RELOC(i915);
cache->node.allocated = false;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 57918f2..5af19b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -74,7 +74,6 @@ static int render_state_setup(struct intel_render_state *so,
  struct drm_i915_private *i915)
 {
const struct intel_renderstate_rodata *rodata = so->rodata;
-   const bool has_64bit_reloc = INTEL_GEN(i915) >= 8;
struct drm_i915_gem_object *obj = so->vma->obj;
unsigned int i = 0, reloc_index = 0;
unsigned int needs_clflush;
@@ -93,7 +92,7 @@ static int render_state_setup(struct intel_render_state *so,
if (i * 4  == rodata->reloc[reloc_index]) {
u64 r = s + so->vma->node.start;
s = lower_32_bits(r);
-   if (has_64bit_reloc) {
+   if (HAS_64BIT_RELOC(i915)) {
if (i + 1 >= rodata->batch_items ||
rodata->batch[i + 1] != 0)
goto err;
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 31e6edd..2a41950 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -288,7 +288,8 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
-   .has_logical_ring_contexts = 1
+   .has_logical_ring_contexts = 1, \
+   .has_64bit_reloc = 1
 
 static const struct intel_device_info intel_broadwell_info = {
BDW_FEATURES,
@@ -308,6 +309,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.is_cherryview = 1,
+   .has_64bit_reloc = 1,
.has_psr = 1,
.has_runtime_pm = 1,
.has_resource_streamer = 1,
@@ -347,6 +349,7 @@ static const struct intel_device_info intel_broxton_info = {
.has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_pipes = 3,
+   .has_64bit_reloc = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
.has_fbc = 1,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/sw_fence: Replace private use of wq->flags with bit zero in wq->private

[Tvrtko Ursulin]

On 02/11/2016 17:34, Chris Wilson wrote:

On Wed, Nov 02, 2016 at 05:00:28PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Use of an un-allocated bit in flags is making me nervous so I
thought to use the bit zero of the private pointer instead.

That should be safer against the core kernel changes and safe
since I can't imagine we can get a fence at the odd address.


I'm not squeamish about using flags ;)


Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_sw_fence.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 95f2f12e0917..cd4d6b915848 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -13,7 +13,8 @@

 #include "i915_sw_fence.h"

-#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for safety */
+#define I915_SW_FENCE_FLAG_ALLOC   (1)


BIT(0) before Joonas notices.


+#define I915_SW_FENCE_PRIVATE_MASK ~(I915_SW_FENCE_FLAG_ALLOC)

 static DEFINE_SPINLOCK(i915_sw_fence_lock);

@@ -132,12 +133,17 @@ void i915_sw_fence_commit(struct i915_sw_fence *fence)
i915_sw_fence_put(fence);
 }

+#define wq_to_i915_sw_fence(wq) (struct i915_sw_fence *) \
+   ((unsigned long)(wq)->private & I915_SW_FENCE_PRIVATE_MASK)


I quite like:

#define wq_to_i915_sw_fence(wq) ({
unsigned long __v = (unsigned long)(wq)->private;
(struct i915_sw_fence *)(__v & I915_SW_FENCE_PRIVATE_MASK);
)}

or better

static inline struct i915_sw_fence *
wq_to_i915_sw_fence(const wait_queue_t *wq)
{
unsigned long __v = (unsigned long)wq->private;
return (struct i915_sw_fence *)(__v & I915_SW_FENCE_PRIVATE_MASK);
}

static inline bool
wq_is_alloc(const wait_queue_t *wq)
{
unsigned long __v = (unsigned long)wq->private;
return __v & I915_SW_FENCE_FLAG_ALLOC;
}


+
 static int i915_sw_fence_wake(wait_queue_t *wq, unsigned mode, int flags, void 
*key)
 {
+   struct i915_sw_fence *fence = wq_to_i915_sw_fence(wq);
+
list_del(>task_list);
-   __i915_sw_fence_complete(wq->private, key);
-   i915_sw_fence_put(wq->private);
-   if (wq->flags & I915_SW_FENCE_FLAG_ALLOC)
+   __i915_sw_fence_complete(fence, key);
+   i915_sw_fence_put(fence);
+   if ((unsigned long)wq->private & I915_SW_FENCE_FLAG_ALLOC)
kfree(wq);
return 0;
 }
@@ -157,7 +163,8 @@ static bool __i915_sw_fence_check_if_after(struct 
i915_sw_fence *fence,
if (wq->func != i915_sw_fence_wake)
continue;

-   if (__i915_sw_fence_check_if_after(wq->private, signaler))
+   if (__i915_sw_fence_check_if_after(wq_to_i915_sw_fence(wq),
+  signaler))
return true;
}

@@ -175,7 +182,7 @@ static void __i915_sw_fence_clear_checked_bit(struct 
i915_sw_fence *fence)
if (wq->func != i915_sw_fence_wake)
continue;

-   __i915_sw_fence_clear_checked_bit(wq->private);
+   __i915_sw_fence_clear_checked_bit(wq_to_i915_sw_fence(wq));
}
 }

@@ -221,13 +228,14 @@ static int __i915_sw_fence_await_sw_fence(struct 
i915_sw_fence *fence,
return 0;
}

-   pending |= I915_SW_FENCE_FLAG_ALLOC;
+   pending = I915_SW_FENCE_FLAG_ALLOC;
}

INIT_LIST_HEAD(>task_list);
-   wq->flags = pending;


We still need to set wq->flags to 0.


Ooops.


It looks ok, but I just don't see the point. wq->flags is private to the
wq->func callback.


A very superficial skim shows that wake_up_common at least looks at the 
flags. So I thought, as long as wake_up_something gets called form 
somewhere on these ones, it would be safer not to potentially silently 
collide with some core flag.


Or are you saying no one ever touches them outside i915_sw_fence.c ? Hm, 
I have to admit I haven't figured it all out yet so I am not sure.


Regards,

Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx