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

[Takashi Iwai]

On Thu, 30 Mar 2017 02:24:37 +0200,
Lyude Paul wrote:
> 
> On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> > On Wed, 29 Mar 2017 15:34:15 +0200,
> > Ville Syrjälä wrote:
> > > 
> > > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > > > On Mon, 27 Mar 2017 18:02:13 +0200,
> > > > Takashi Iwai wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > > > > drm/i915: Call intel_dp_mst_resume() before resuming
> > > > > displays
> > > > > 
> > > > > seems to trigger a kernel panic when some modeset change
> > > > > happens after
> > > > > S3 resume.  The details are found in openSUSE bugzilla,
> > > > >   https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > > > > 
> > > > > In short, the following procedure causes a kernel panic
> > > > > (supposedly)
> > > > > almost 100% on Dell Latitude with Skylake with MST DP on dock:
> > > > > 
> > > > > - Boot with a docking station, DP-1 connected.
> > > > > - Login on X
> > > > > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto 
> > > > > --left-of eDP-1
> > > > >   ==> This changes the mode.
> > > > > - Suspend ("systemctl suspend" in my case), and close the lid.
> > > > > - Remove from the dock (keep the lid closed).
> > > > > - Open the lid, which resumes automatically.  It works.
> > > > > - Suspend again.
> > > > > - Connect to the dock again (keep the lid closed).
> > > > > - Open the lid, which resumes automatically.  It's still OK.
> > > > > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto 
> > > > > --left-of eDP-1
> > > > >   ==> Now the kernel feezes.
> > > > > 
> > > > > Reverting the commit mentioned above fixes the problem.
> > > > > 
> > > > > The problem is present in all versions I tested.  The reported
> > > > > kernel
> > > > > in the Bugzilla is 4.4.x-based one, but the issue is seen in
> > > > > 4.11-rc3,
> > > > > too.  Note that the S3 resume itself works in 4.11-rc3; the
> > > > > kernel
> > > > > panic happens when invoking xrandr manually after that.
> > > > > 
> > > > > Unfortunately, I couldn't get a kernel panic message, so
> > > > > far.  kdump
> > > > > didn't work well in this case by some reason.  There are some
> > > > > screenshots taken by the original reporter (could switch VT
> > > > > beforehand), but I don't know whether it helps.
> > > > > 
> > > > > If you have any hints for further debugging, it'd be highly
> > > > > appreciated.
> > > > 
> > > > It seems that the patch below works around the problem.
> > > > Can anyone enlighten what's going on there?
> > > > 
> > > > 
> > > > thanks,
> > > > 
> > > > Takashi
> > > > 
> > > > -- 8< --
> > > > From: Takashi Iwai 
> > > > Subject: [PATCH] drm/i915: Fix crash after S3 resume with DP MST
> > > > mode change
> > > > 
> > > > We've got a bug report showing that Skylake Dell machines with a
> > > > docking station causes a kernel panic after S3 resume and
> > > > modeset.
> > > > The details are found in the openSUSE bugzilla entry below.  The
> > > > typical test procedure is:
> > > > 
> > > > - Laptop is Dell Latitude with eDP (1366x768)
> > > > - Boot with docking station connected to a DP (1920x1080)
> > > > - Login, change the mode via
> > > >   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of
> > > > eDP-1
> > > > - Suspend, and close the lid after the suspend
> > > >   (or close the lid to trigger the suspend)
> > > > - Undock while keeping the lid closed.
> > > > - Open the lid, which triggers the resume;
> > > >   the machine wakes up well, and X shows up.  No problem, so far.
> > > > - Suspend again, close the lid.
> > > > - Dock again while keeping the lid closed.
> > > > - Open the lid, triggering the resume; this wakes up still fine.
> > > > - At this moment, run xrandr again to re-setup DP-1
> > > >   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of
> > > > eDP-1
> > > >   ==> This triggers a hard crash.
> > > > 
> > > > I could bisect it, and this leaded to the commit a16b7658f4e0
> > > > ("drm/i915: Call intel_dp_mst_resume() before resuming
> > > > displays").
> > > > 
> > > > Basically the commit just shuffles the calls of
> > > > intel_display_resume()
> > > > and intel_dp_mst_resume().  So as a workaround, I tried to split
> > > > intel_dp_mst_resume() call to postpone the suspected code (the
> > > > invocation of intel_dp_check_mst_status()), then bingo, this
> > > > cured the
> > > > problem.
> > > > 
> > > > But don't ask me *why* this fixes.  It's still in a cargo-cult
> > > > state.
> > > > 
> > > > Fixes: a16b7658f4e0 ("drm/i915: Call intel_dp_mst_resume() before
> > > > resuming displays")
> > > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > > > Signed-off-by: Takashi Iwai 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c  |  5 -
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 20 +++-
> > > >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> > > >  3 

Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for Gen7.5+ in virtual environment

[Zhang, Xiong Y]

> On Wed, Mar 29, 2017 at 05:02:47PM +0800, Xiong Zhang wrote:
> > In a virtual passthrough environment, the ISA bridge isn't able to
> > be passed through. So pch_id couldn't be gotten from ISA bridge, but
> > pch_id is used to identify LPT_H and LPT_LP, this patch set pch_id
> > according to IGD type.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938
> >
> > Signed-off-by: Xiong Zhang 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> > index 8b807a9..32a9bff 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -135,9 +135,17 @@ static enum intel_pch intel_virt_detect_pch(struct
> drm_i915_private *dev_priv)
> > DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> > } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> > ret = PCH_LPT;
> > +   if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> > +   dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> > +   else
> > +   dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> > DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> > } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> > ret = PCH_SPT;
> > +   if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv))
> > +   dev_priv->pch_id = INTEL_PCH_SPT_LP_DEVICE_ID_TYPE;
> > +   else
> > +   dev_priv->pch_id = INTEL_PCH_SPT_DEVICE_ID_TYPE;
> 
> I'm not 100% sure the ULT/ULX <=> LP thing always holds. I *think* it
> should but I've never been able to convince myself totally.
[Zhang, Xiong Y] For BDW ULT/ULX, it should be LP. A picture from 
https://gfxspecs.intel.com/Predator/Home/Index/4216 could confirm this.
For HSW ULT/ULX, I couldn't find a material to confirm this.
Anyway I copy this condition from the WARN_ON() in intel_detect_pch() 

For SKL/KBL ULT/ULX, I couldn't find a material to confirm this neither.

> As far as KBL goes, maybe we want PCH_KBP for it? Although I don't actually
> know why we even make the distinction between the two since they seem
> identical for us, and we don't distinguish LPT vs. WPT either. Rodrigo?
[Zhang, Xiong Y] For PCH_KBP, I couldn't find out which KBL type will co-work 
with it.
As the real ISA Bridge doesn't exist in a emulated guest machine, we couldn't 
get the real and accurate pch_id in guest. In such passthrough virtual 
environment, the only real HW is IGD which is passed through to guest, we could 
only assume the pch_id from this IGD.
Fortunately pch_id is only used to identify LPT_LP and LPT_H currently.
Without this patch, pch_id is totally wrong. And on LPT_LP platform without 
this patch, the local HDMI/DP display couldn't lightup when guest boot up. But 
this patch could only remedy part of pch_id. Currently I have two plans to 
improve this patch:
1) only remain pch_id assuming for HSW and BDW, as this is really we need to 
fix the bug.
  Delete pch_id assuming for SKL and KBL, as currently i915 driver don't use it.
2) Claim this patch's limitation in commit message.
Any suggestion ?
> > DRM_DEBUG_KMS("Assuming SunrisePoint PCH\n");
> > }
> >
> > --
> > 1.9.1
> >
> > ___
> > 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 v4 0/6] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

Friendly ping. Can anyone please review this?
Thanks


On Wed, Mar 22, 2017 at 3:54 PM, Puthikorn Voravootivat  wrote:

> Rebase since this is not applied cleanly now.
>
> This patch set contain 6 patches.
> - First two patches allow enable DPCD backlight control when panel
>   can also do that via PWM pin and fix the usage of enable register.
> - Next patch adds enable DBC by default
> - Next patch makes the driver restore last brightness level after
>   turning display off and on.
> - Last two patches set the PWM freqency to match data in panel vbt.
>
> Change log:
> v2:
> - Drop PWM frequency patch
> - Addess suggestion from Jani Nikula
>
> v3:
> - Add new implementation of PWM frequency patch
>
> v4:
> - Rebase / minor typo fix.
>
> Puthikorn Voravootivat (6):
>   drm/i915: Add DPCD prefered mode for backlight control
>   drm/i915: Correctly enable blacklight adjustment via DPCD
>   drm/i915: Support dynamic backlight via DPCD register
>   drm/i915: Store brightness level in aux backlight driver
>   drm: Add definition for eDP backlight frequency
>   drm/i915: Set PWM divider to match desired frequency in vbt
>
>  drivers/gpu/drm/i915/i915_params.c|   6 +-
>  drivers/gpu/drm/i915/i915_params.h|   2 +-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 143
> +++---
>  include/drm/drm_dp_helper.h   |   2 +
>  4 files changed, 133 insertions(+), 20 deletions(-)
>
> --
> 2.12.1.500.gab5fba24ee-goog
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/intel_ringbuffer.h

between commit:

  dd68f2ba0720 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")

from the drm-intel-fixes tree and commit:

  73dec95e6ba3 ("drm/i915: Emit to ringbuffer directly")

from the drm 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_ringbuffer.h
index 8cb2078c5bfc,847aea554464..
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@@ -522,19 -525,14 +525,20 @@@ intel_ring_advance(struct drm_i915_gem_
  }
  
  static inline u32
 +intel_ring_wrap(const struct intel_ring *ring, u32 pos)
 +{
 +  return pos & (ring->size - 1);
 +}
 +
- static inline u32 intel_ring_offset(struct intel_ring *ring, void *addr)
++static inline u32
+ intel_ring_offset(struct drm_i915_gem_request *req, void *addr)
  {
/* Don't write ring->size (equivalent to 0) as that hangs some GPUs. */
-   u32 offset = addr - ring->vaddr;
-   return intel_ring_wrap(ring, offset);
+   u32 offset = addr - req->ring->vaddr;
+   GEM_BUG_ON(offset > req->ring->size);
 -  return offset & (req->ring->size - 1);
++  return intel_ring_wrap(req->ring, offset);
  }
  
- int __intel_ring_space(int head, int tail, int size);
  void intel_ring_update_space(struct intel_ring *ring);
  
  void intel_engine_init_global_seqno(struct intel_engine_cs *engine, u32 
seqno);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/i915/intel_lrc.c

between commit:

  dd68f2ba0720 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")

from the drm-intel-fixes tree and commit:

  944a36d472be ("drm/i915: Assert that the request->tail is always qword 
aligned")

from the drm 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_lrc.c
index 91555d4e9129,77168e673e0a..
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@@ -1440,9 -1268,8 +1268,10 @@@ static void reset_common_ring(struct in
GEM_BUG_ON(request->ctx != port[0].request->ctx);
  
/* Reset WaIdleLiteRestore:bdw,skl as well */
 -  request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
 +  request->tail =
 +  intel_ring_wrap(request->ring,
 +  request->wa_tail - WA_TAIL_DWORDS*sizeof(u32));
+   GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
  }
  
  static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Lyude Paul]

On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> On Wed, 29 Mar 2017 15:34:15 +0200,
> Ville Syrjälä wrote:
> > 
> > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > > On Mon, 27 Mar 2017 18:02:13 +0200,
> > > Takashi Iwai wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > > > drm/i915: Call intel_dp_mst_resume() before resuming
> > > > displays
> > > > 
> > > > seems to trigger a kernel panic when some modeset change
> > > > happens after
> > > > S3 resume.  The details are found in openSUSE bugzilla,
> > > >   https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > > > 
> > > > In short, the following procedure causes a kernel panic
> > > > (supposedly)
> > > > almost 100% on Dell Latitude with Skylake with MST DP on dock:
> > > > 
> > > > - Boot with a docking station, DP-1 connected.
> > > > - Login on X
> > > > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto 
> > > > --left-of eDP-1
> > > >   ==> This changes the mode.
> > > > - Suspend ("systemctl suspend" in my case), and close the lid.
> > > > - Remove from the dock (keep the lid closed).
> > > > - Open the lid, which resumes automatically.  It works.
> > > > - Suspend again.
> > > > - Connect to the dock again (keep the lid closed).
> > > > - Open the lid, which resumes automatically.  It's still OK.
> > > > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto 
> > > > --left-of eDP-1
> > > >   ==> Now the kernel feezes.
> > > > 
> > > > Reverting the commit mentioned above fixes the problem.
> > > > 
> > > > The problem is present in all versions I tested.  The reported
> > > > kernel
> > > > in the Bugzilla is 4.4.x-based one, but the issue is seen in
> > > > 4.11-rc3,
> > > > too.  Note that the S3 resume itself works in 4.11-rc3; the
> > > > kernel
> > > > panic happens when invoking xrandr manually after that.
> > > > 
> > > > Unfortunately, I couldn't get a kernel panic message, so
> > > > far.  kdump
> > > > didn't work well in this case by some reason.  There are some
> > > > screenshots taken by the original reporter (could switch VT
> > > > beforehand), but I don't know whether it helps.
> > > > 
> > > > If you have any hints for further debugging, it'd be highly
> > > > appreciated.
> > > 
> > > It seems that the patch below works around the problem.
> > > Can anyone enlighten what's going on there?
> > > 
> > > 
> > > thanks,
> > > 
> > > Takashi
> > > 
> > > -- 8< --
> > > From: Takashi Iwai 
> > > Subject: [PATCH] drm/i915: Fix crash after S3 resume with DP MST
> > > mode change
> > > 
> > > We've got a bug report showing that Skylake Dell machines with a
> > > docking station causes a kernel panic after S3 resume and
> > > modeset.
> > > The details are found in the openSUSE bugzilla entry below.  The
> > > typical test procedure is:
> > > 
> > > - Laptop is Dell Latitude with eDP (1366x768)
> > > - Boot with docking station connected to a DP (1920x1080)
> > > - Login, change the mode via
> > >   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of
> > > eDP-1
> > > - Suspend, and close the lid after the suspend
> > >   (or close the lid to trigger the suspend)
> > > - Undock while keeping the lid closed.
> > > - Open the lid, which triggers the resume;
> > >   the machine wakes up well, and X shows up.  No problem, so far.
> > > - Suspend again, close the lid.
> > > - Dock again while keeping the lid closed.
> > > - Open the lid, triggering the resume; this wakes up still fine.
> > > - At this moment, run xrandr again to re-setup DP-1
> > >   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of
> > > eDP-1
> > >   ==> This triggers a hard crash.
> > > 
> > > I could bisect it, and this leaded to the commit a16b7658f4e0
> > > ("drm/i915: Call intel_dp_mst_resume() before resuming
> > > displays").
> > > 
> > > Basically the commit just shuffles the calls of
> > > intel_display_resume()
> > > and intel_dp_mst_resume().  So as a workaround, I tried to split
> > > intel_dp_mst_resume() call to postpone the suspected code (the
> > > invocation of intel_dp_check_mst_status()), then bingo, this
> > > cured the
> > > problem.
> > > 
> > > But don't ask me *why* this fixes.  It's still in a cargo-cult
> > > state.
> > > 
> > > Fixes: a16b7658f4e0 ("drm/i915: Call intel_dp_mst_resume() before
> > > resuming displays")
> > > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > > Signed-off-by: Takashi Iwai 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.c  |  5 -
> > >  drivers/gpu/drm/i915/intel_dp.c  | 20 +++-
> > >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> > >  3 files changed, 25 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 1c75402a59c1..62c40090ceed 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ 

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Wait for inflight writes before checking intel_engine_is_idle()

[Chris Wilson]

On Wed, Mar 29, 2017 at 10:36:16PM +0100, Chris Wilson wrote:
> Some GPUs may have writes inflight much longer than expected, so before
> declaring the GPU is idle, try to flush them using any
> engine->irq_seqno_barrier() if available. By allowing them to be
> flushed, we can be a little more confident that the GPU really is idle
> when we think it is!
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/intel_engine_cs.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index c76a64483d64..ff6d0e1d1306 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1074,6 +1074,10 @@ bool intel_engine_is_idle(struct intel_engine_cs 
> *engine)
>  {
>   struct drm_i915_private *dev_priv = engine->i915;
>  
> + /* We have to allow time for writes to land from the GPU. */
> + if (engine->irq_seqno_barrier)
> + engine->irq_seqno_barrier(engine);
> +

Problem persists so ignore this patch. 2-4 are still a nice cleanup and
worth persuing.
-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/4] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

[Chris Wilson]

On Wed, Mar 29, 2017 at 10:36:17PM +0100, Chris Wilson wrote:
> Make i915_gem_wait_for_idle() be a little heavier in order to try and
> guarantee that the GPU is indeed idle (by checking each engine
> individually is idle, i.e. all writes are complete and the rings
> stopped) after waiting for in-flight requests to be completed.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ec194d3e6cd3..5f0aff016eb1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3054,6 +3054,19 @@ static int wait_for_timeline(struct i915_gem_timeline 
> *tl, unsigned int flags)
>   return 0;
>  }
>  
> +static int wait_for_engines(struct drm_i915_private *i915)
> +{
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + for_each_engine(engine, i915, id) {
> + if (GEM_WARN_ON(wait_for(intel_engine_is_idle(engine), 50)))

And I might want to consider an inline for
wait_for(intel_engine_is_idle)) to avoid the hideous string :)
-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 3/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

On 17-03-29 23:17:13, Ville Syrjälä wrote:

On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

Cc: Ville Syrjälä 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 112 +--
 drivers/gpu/drm/i915/intel_sprite.c  |  25 +++-
 2 files changed, 131 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 802a8449c5d3..bb559a116fda 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };

+static const uint64_t i9xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };

+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED,
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13453,6 +13467,83 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }

+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   (modifier >= I915_FORMAT_MOD_X_TILED &&
+modifier < I915_FORMAT_MOD_Yf_TILED);


The >= stuff makes this harder to parse than it should be IMO.
I'd just list each modifier explicitly.


+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   (modifier >= I915_FORMAT_MOD_X_TILED &&
+   modifier <= I915_FORMAT_MOD_Yf_TILED);


ditto. At first I couldn't even spot the difference between this and
the C8 case.



Okay, got those both. I think for now it's just:
   switch (format) {
   case DRM_FORMAT_C8:
   switch (modifier) {
   case DRM_FORMAT_MOD_LINEAR:
   case I915_FORMAT_MOD_X_TILED:
   case I915_FORMAT_MOD_Y_TILED:
   return true;
   default:
   return false;
   }
   case DRM_FORMAT_RGB565:
   case DRM_FORMAT_XRGB:
   case DRM_FORMAT_XBGR:
   case DRM_FORMAT_ARGB:
   case DRM_FORMAT_ABGR:
   case DRM_FORMAT_XRGB2101010:
   case DRM_FORMAT_XBGR2101010:
   case DRM_FORMAT_YUYV:
   case DRM_FORMAT_YVYU:
   case DRM_FORMAT_UYVY:
   case DRM_FORMAT_VYUY:
   /* All i915 modifiers are fine */
   switch (modifier) {
   case DRM_FORMAT_MOD_LINEAR:
   case I915_FORMAT_MOD_X_TILED:
   case I915_FORMAT_MOD_Y_TILED:
   case I915_FORMAT_MOD_Yf_TILED:
   return true;
   default:
   return false;
   }
   default:
   return false;
   }




+   case DRM_FORMAT_YUYV:
+   case 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

[Chris Wilson]

On Wed, Mar 29, 2017 at 10:36:17PM +0100, Chris Wilson wrote:
> Make i915_gem_wait_for_idle() be a little heavier in order to try and
> guarantee that the GPU is indeed idle (by checking each engine
> individually is idle, i.e. all writes are complete and the rings
> stopped) after waiting for in-flight requests to be completed.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index ec194d3e6cd3..5f0aff016eb1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3054,6 +3054,19 @@ static int wait_for_timeline(struct i915_gem_timeline 
> *tl, unsigned int flags)
>   return 0;
>  }
>  
> +static int wait_for_engines(struct drm_i915_private *i915)
> +{
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> +
> + for_each_engine(engine, i915, id) {
> + if (GEM_WARN_ON(wait_for(intel_engine_is_idle(engine), 50)))
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +
>  int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int flags)
>  {
>   int ret;
> @@ -3070,10 +3083,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
> *i915, unsigned int flags)
>   if (ret)
>   return ret;
>   }
> +
> + ret = wait_for_engines(i915);
>   } else {
>   ret = wait_for_timeline(>gt.global_timeline, flags);
> - if (ret)
> - return ret;
>   }
>  
>   return 0;

Forgot to change this to return ret;
-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] drm/i915: Drop verbose and archaic "ring" from our internal engine names

[Chris Wilson]

We pretty print the name of an engine in several places, mostly for
debug, but also in the GPU hang report. Using "ring" in the name is
archaic (we call those engines now to differentiate them from the
multiple rings of commands we execute on each engine), quite verbose and
often tautological. We run out of room in our GPU hang report for
instance if we have more than a couple of engines hung simultaneously.
Bit the bullet and update the strings to reflect the common internal names.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ff6d0e1d1306..7100ac688be5 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -36,7 +36,7 @@ static const struct engine_info {
int (*init_execlists)(struct intel_engine_cs *engine);
 } intel_engines[] = {
[RCS] = {
-   .name = "render ring",
+   .name = "rcs",
.uabi_id = I915_EXEC_RENDER,
.hw_id = RCS_HW,
.mmio_base = RENDER_RING_BASE,
@@ -45,7 +45,7 @@ static const struct engine_info {
.init_legacy = intel_init_render_ring_buffer,
},
[BCS] = {
-   .name = "blitter ring",
+   .name = "bcs",
.uabi_id = I915_EXEC_BLT,
.hw_id = BCS_HW,
.mmio_base = BLT_RING_BASE,
@@ -54,7 +54,7 @@ static const struct engine_info {
.init_legacy = intel_init_blt_ring_buffer,
},
[VCS] = {
-   .name = "bsd ring",
+   .name = "vcs",
.uabi_id = I915_EXEC_BSD,
.hw_id = VCS_HW,
.mmio_base = GEN6_BSD_RING_BASE,
@@ -63,7 +63,7 @@ static const struct engine_info {
.init_legacy = intel_init_bsd_ring_buffer,
},
[VCS2] = {
-   .name = "bsd2 ring",
+   .name = "vcs2",
.uabi_id = I915_EXEC_BSD2,
.hw_id = VCS2_HW,
.mmio_base = GEN8_BSD2_RING_BASE,
@@ -72,7 +72,7 @@ static const struct engine_info {
.init_legacy = intel_init_bsd2_ring_buffer,
},
[VECS] = {
-   .name = "video enhancement ring",
+   .name = "vecs",
.uabi_id = I915_EXEC_VEBOX,
.hw_id = VECS_HW,
.mmio_base = VEBOX_RING_BASE,
-- 
2.11.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 series starting with [1/4] drm/i915: Wait for inflight writes before checking intel_engine_is_idle() (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Wait for inflight writes before 
checking intel_engine_is_idle() (rev2)
URL   : https://patchwork.freedesktop.org/series/22126/
State : success

== Summary ==

Series 22126v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22126/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-skl-6260u)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 428s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 433s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 586s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 534s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 488s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 492s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 470s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 455s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 672s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 447s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 493s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 530s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 405s

e2bbafd9baa779a48160c2ffbb5fae6d6afe8d65 drm-tip: 2017y-03m-29d-20h-27m-37s UTC 
integration manifest
9255101 drm/i915: Combine reset_all_global_seqno() loops into one
4debcd5 drm/i915: Remove redudant wait for each engine to idle from seqno wrap
9a291fa drm/i915: Wait for all engines to be idle as part of 
i915_gem_wait_for_idle()
342656d drm/i915: Wait for inflight writes before checking 
intel_engine_is_idle()

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Combine reset_all_global_seqno() loops into one

[Chris Wilson]

We can merge the pair of loops over the engines and their timelines into
a single loop, making it easier to read and more consistent with the
commentary.

Signed-off-by: Chris Wilson 
---
git add ftw
---
 drivers/gpu/drm/i915/i915_gem_request.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 79c30bbcfdcb..6abc1a8d20c5 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -180,7 +180,6 @@ i915_priotree_init(struct i915_priotree *pt)
 
 static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
 {
-   struct i915_gem_timeline *timeline = >gt.global_timeline;
struct intel_engine_cs *engine;
enum intel_engine_id id;
int ret;
@@ -197,7 +196,8 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
 
/* If the seqno wraps around, we need to clear the breadcrumb rbtree */
for_each_engine(engine, i915, id) {
-   struct intel_timeline *tl = >engine[id];
+   struct i915_gem_timeline *timeline;
+   struct intel_timeline *tl = engine->timeline;
 
if (!i915_seqno_passed(seqno, tl->seqno)) {
/* spin until threads are complete */
@@ -208,14 +208,10 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
/* Finally reset hw state */
tl->seqno = seqno;
intel_engine_init_global_seqno(engine, seqno);
-   }
-
-   list_for_each_entry(timeline, >gt.timelines, link) {
-   for_each_engine(engine, i915, id) {
-   struct intel_timeline *tl = >engine[id];
 
-   memset(tl->sync_seqno, 0, sizeof(tl->sync_seqno));
-   }
+   list_for_each_entry(timeline, >gt.timelines, link)
+   memset(timeline->engine[id].sync_seqno, 0,
+  sizeof(timeline->engine[id].sync_seqno));
}
 
return 0;
-- 
2.11.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Wait for inflight writes before checking intel_engine_is_idle()

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915: Wait for inflight writes before 
checking intel_engine_is_idle()
URL   : https://patchwork.freedesktop.org/series/22126/
State : failure

== Summary ==

  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
  LD  net/packet/built-in.o
  LD  kernel/built-in.o
  LD  lib/xz/xz_dec.o
  LD  lib/xz/built-in.o
  LD  drivers/acpi/built-in.o
  LD [M]  sound/pci/hda/snd-hda-intel.o
  LD  drivers/video/fbdev/core/fb.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/scsi/built-in.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD  drivers/pci/built-in.o
  LD [M]  sound/pci/hda/snd-hda-codec-realtek.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  drivers/usb/gadget/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
drivers/gpu/drm/i915/i915_gem_request.c: In function ‘reset_all_global_seqno’:
drivers/gpu/drm/i915/i915_gem_request.c:199:32: error: ‘timeline’ undeclared 
(first use in this function)
   struct intel_timeline *tl = >engine[id];
^
drivers/gpu/drm/i915/i915_gem_request.c:199:32: note: each undeclared 
identifier is reported only once for each function it appears in
In file included from ./arch/x86/include/asm/percpu.h:44:0,
 from ./arch/x86/include/asm/current.h:5,
 from ./arch/x86/include/asm/processor.h:15,
 from ./include/linux/prefetch.h:14,
 from drivers/gpu/drm/i915/i915_gem_request.c:25:
./include/linux/kernel.h:852:48: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
./include/linux/list.h:365:2: note: in expansion of macro ‘container_of’
  container_of(ptr, type, member)
  ^
./include/linux/list.h:376:2: note: in expansion of macro ‘list_entry’
  list_entry((ptr)->next, type, member)
  ^
./include/linux/list.h:463:13: note: in expansion of macro ‘list_first_entry’
  for (pos = list_first_entry(head, typeof(*pos), member); \
 ^
drivers/gpu/drm/i915/i915_gem_request.c:211:3: note: in expansion of macro 
‘list_for_each_entry’
   list_for_each_entry(timeline, >gt.timelines, link)
   ^
  LD [M]  sound/pci/hda/snd-hda-codec-hdmi.o
  LD  lib/raid6/raid6_pq.o
  LD  lib/raid6/built-in.o
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_request.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_request.o] Error 1
make[4]: *** Waiting for unfinished jobs
  LD  net/xfrm/built-in.o
  LD  net/ipv6/ipv6.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/tty/serial/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  net/ipv6/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/usb/core/built-in.o
  LD  fs/btrfs/btrfs.o
  LD  fs/btrfs/built-in.o
  LD  lib/lz4/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  drivers/md/md-mod.o
  LD  drivers/md/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  net/ipv4/built-in.o
  CC  arch/x86/kernel/cpu/capflags.o
  AR  lib/lib.a
  LD  arch/x86/kernel/cpu/built-in.o
  EXPORTS lib/lib-ksyms.o
  LD  arch/x86/kernel/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  drivers/tty/vt/built-in.o
  LD  net/core/built-in.o
  LD  drivers/tty/built-in.o
  LD  arch/x86/built-in.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  LD  sound/pci/built-in.o
  LD  lib/built-in.o
  LD  net/built-in.o
  LD  sound/built-in.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/ext4.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1002: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH 3/4] drm/i915: Remove redudant wait for each engine to idle from seqno wrap

[Chris Wilson]

Having added the wait upon each engine to idle into the central
i915_gem_wait_for_idle(), we can remove the now redundant wait from
reset_all_global_seqno(). This has the advantage of removing the late
detection of an error (an engine still busy) which left the seqno reset
only partially complete (though it should be safe enough!).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 45299a8b5e4b..5439a21472bb 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -208,9 +208,6 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
for_each_engine(engine, i915, id) {
struct intel_timeline *tl = >engine[id];
 
-   if (wait_for(intel_engine_is_idle(engine), 50))
-   return -EBUSY;
-
if (!i915_seqno_passed(seqno, tl->seqno)) {
/* spin until threads are complete */
while (intel_breadcrumbs_busy(engine))
-- 
2.11.0

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

[Intel-gfx] [PATCH 4/4] drm/i915: Combine reset_all_global_seqno() loops into one

[Chris Wilson]

We can merge the pair of loops over the engines and their timelines into
a single loop, making it easier to read and more consistent with the
commentary.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5439a21472bb..76e4a83c2e53 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -189,7 +189,6 @@ i915_priotree_init(struct i915_priotree *pt)
 
 static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
 {
-   struct i915_gem_timeline *timeline = >gt.global_timeline;
struct intel_engine_cs *engine;
enum intel_engine_id id;
int ret;
@@ -217,14 +216,10 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
/* Finally reset hw state */
tl->seqno = seqno;
intel_engine_init_global_seqno(engine, seqno);
-   }
-
-   list_for_each_entry(timeline, >gt.timelines, link) {
-   for_each_engine(engine, i915, id) {
-   struct intel_timeline *tl = >engine[id];
 
-   memset(tl->sync_seqno, 0, sizeof(tl->sync_seqno));
-   }
+   list_for_each_entry(timeline, >gt.timelines, link)
+   memset(timeline->engine[id].sync_seqno, 0,
+  sizeof(timeline->engine[id].sync_seqno));
}
 
return 0;
-- 
2.11.0

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

[Intel-gfx] [PATCH 2/4] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

[Chris Wilson]

Make i915_gem_wait_for_idle() be a little heavier in order to try and
guarantee that the GPU is indeed idle (by checking each engine
individually is idle, i.e. all writes are complete and the rings
stopped) after waiting for in-flight requests to be completed.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ec194d3e6cd3..5f0aff016eb1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3054,6 +3054,19 @@ static int wait_for_timeline(struct i915_gem_timeline 
*tl, unsigned int flags)
return 0;
 }
 
+static int wait_for_engines(struct drm_i915_private *i915)
+{
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, i915, id) {
+   if (GEM_WARN_ON(wait_for(intel_engine_is_idle(engine), 50)))
+   return -EBUSY;
+   }
+
+   return 0;
+}
+
 int i915_gem_wait_for_idle(struct drm_i915_private *i915, unsigned int flags)
 {
int ret;
@@ -3070,10 +3083,10 @@ int i915_gem_wait_for_idle(struct drm_i915_private 
*i915, unsigned int flags)
if (ret)
return ret;
}
+
+   ret = wait_for_engines(i915);
} else {
ret = wait_for_timeline(>gt.global_timeline, flags);
-   if (ret)
-   return ret;
}
 
return 0;
-- 
2.11.0

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

[Intel-gfx] [PATCH 1/4] drm/i915: Wait for inflight writes before checking intel_engine_is_idle()

[Chris Wilson]

Some GPUs may have writes inflight much longer than expected, so before
declaring the GPU is idle, try to flush them using any
engine->irq_seqno_barrier() if available. By allowing them to be
flushed, we can be a little more confident that the GPU really is idle
when we think it is!

References: https://bugs.freedesktop.org/show_bug.cgi?id=98836
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index c76a64483d64..ff6d0e1d1306 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1074,6 +1074,10 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
 
+   /* We have to allow time for writes to land from the GPU. */
+   if (engine->irq_seqno_barrier)
+   engine->irq_seqno_barrier(engine);
+
/* Any inflight/incomplete requests? */
if (!i915_seqno_passed(intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine)))
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Implement cdclk restrictions based on Azalia BCLK

[Pandiyan, Dhinakaran]

On Wed, 2017-03-29 at 11:50 +0300, Ville Syrjälä wrote:
> On Tue, Mar 07, 2017 at 04:12:52PM -0800, Dhinakaran Pandiyan wrote:
> > According to BSpec, "The CD clock frequency must be at least twice the
> > frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by
> > default. This check is needed because BXT and GLK support cdclk
> > frequencies less than 192 MHz.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_cdclk.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index e8c1181..7b1ac1d 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -1458,6 +1458,18 @@ static int bdw_adjust_min_pipe_pixel_rate(struct 
> > intel_crtc_state *crtc_state,
> > pixel_rate = max(432000, pixel_rate);
> > }
> >  
> > +   /* According to BSpec, "The CD clock frequency must be at least twice
> > +* the frequency of the Azalia BCLK." and BCLK is 96 MHz by default.
> > +* The check for GLK has to be adjusted as the platform can output
> > +* two pixels per clock.
> > +*/
> > +   if (crtc_state->has_audio) {
> > +   if (IS_GEMINILAKE(dev_priv))
> > +   pixel_rate = max(2 * 2 * 96000, pixel_rate);
> 
> BTW that x2 factor for GLK looks wrong. It should be /2.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=100439
> 

BSpec[1] says cdclk needs to be > 2*96 MHz (azalia bclk). To set a cdclk
> 192 MHz on GLK, we need to pass in max_pixclk = 2*192 MHz. But with a
factor of /2, we can end up picking 158.4 MHz or 79.2 MHz for cdclk,
which are lower than 192 MHz.


static int glk_calc_cdclk(int max_pixclk)
{
if (max_pixclk > 2 * 158400)
return 316800;
else if (max_pixclk > 2 * 79200)
return 158400;
else
return 79200;
}

[1] Geminilake Clocks
"158.4 MHz CD (cannot be used when audio is enabled and Azalia BCLK is
96 MHz)
316.8 MHz CD
79.2 MHz CD (exclusively for resolutions up to 1080p in low power single
pipe eDP/MIPI configurations, no audio support)"



-DK

> > +   if (IS_BROXTON(dev_priv))
> > +   pixel_rate = max(2 * 96000, pixel_rate);
> > +   }
> > +
> > return pixel_rate;
> >  }
> >  
> > -- 
> > 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

[Intel-gfx] [maintainer-tools PATCH] dim: Fix assorted documentation typos

[Lukas Wunner]

Just a bunch of trivial typos that caught my eye while perusing the
documentation.

Signed-off-by: Lukas Wunner 
---
 dim.rst   | 14 +++---
 drm-intel.rst | 10 +-
 drm-misc.rst  |  2 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/dim.rst b/dim.rst
index aed79ca1d43c..3aa0eeae9a7a 100644
--- a/dim.rst
+++ b/dim.rst
@@ -31,7 +31,7 @@ Used to maintain drm-intel_ and drm-misc_ git repositories.
 QUICKSTART
 ==
 
-For getting started grab the latest drm (drm-intel-maintainer) script from::
+For getting started grab the latest dim (drm-intel-maintainer) script from::
 
 http://cgit.freedesktop.org/drm-intel/tree/dim?h=maintainer-tools
 
@@ -56,7 +56,7 @@ you have improvements for dim, please submit them to 
intel-gfx.
 
 If you have a freedesktop.org account and plan to push things on one of the
 drm-xxx repos, you should use the ssh://git.freedesktop.org/git/drm-xxx urls
-when adding a remote and, if it's not already done, you should add new entry in
+when adding a remote and, if it's not already done, you should add a new entry 
in
 ~/.ssh/config::
 
 $ printf '\nHost git.freedesktop.org\n\tUser ' >> ~/.ssh/config
@@ -200,7 +200,7 @@ apply-queued [*git am arguments*]
 
 extract-tags *branch* [*git-rangeish*]
 --
-This extracts various tags (eg. Reviwed-by:) from emails and applies them to 
the
+This extracts various tags (e.g. Reviewed-by:) from emails and applies them to 
the
 top commit on the given branch. You can give the command a rangeish to add the
 tags from the same email to multiple already applied patches.
 
@@ -277,12 +277,12 @@ add-link-queued
 magic-rebase-resolve
 
 Tries to resolve a rebase conflict by first resetting the tree
-and the using the magic patch tool. Then builds the tree, adds
+and then using the magic patch tool. Then builds the tree, adds
 any changes with git add -u and continues the rebase.
 
 apply-resolved
 --
-Compile-test the current tree and if successfully resolve a
+Compile-test the current tree and if successful resolve a
 conflicted git am. Also runs the patch checker afterwards. This fails to add 
the
 Link: tag, so you'll need to add it manually or use the **add-link** 
subcommand.
 
@@ -292,7 +292,7 @@ Create a new topic branch with the given name. Note that 
topic/ is not
 automatically prepended. The branch starts at HEAD or the given commit-ish. 
Note
 that by default the new branch is created in the drm-intel.git repository. If
 you want to create a branch somewhere else, then you need to prepend the remote
-name from nigthly.conf, e.g. "drm-misc/topic/branch".
+name from nightly.conf, e.g. "drm-misc/topic/branch".
 
 remove-branch *branch*
 --
@@ -413,7 +413,7 @@ Show this help. Install **rst2man(1)** for best results.
 
 usage
 -
-Short form usage help listening all subcommands. Run by default or if an 
unknown
+Short form usage help listing all subcommands. Run by default or if an unknown
 subcommand was passed on the cmdline.
 
 ENVIRONMENT
diff --git a/drm-intel.rst b/drm-intel.rst
index 9be1f086e925..c9c8812dc254 100644
--- a/drm-intel.rst
+++ b/drm-intel.rst
@@ -87,7 +87,7 @@ This is the branch where all new features, as well as any 
non-trivial or
 controversial fixes, are applied.
 
 This branch "hides" the merge window from the drm/i915 developers; patches are
-applied here regardless of the development phase of the Linus' upstream kernel.
+applied here regardless of the development phase of Linus' upstream kernel.
 
 drm-intel-next
 ~~
@@ -220,7 +220,7 @@ Signed-off-by: line in the commit message:
 Resolving Conflicts when Rebuilding drm-tip
 ===
 
-When you push patches with dim drm-tip always gets rebuild and this can
+When you push patches with dim drm-tip always gets rebuilt and this can
 sometimes fail, for example like this: ::
 
 Updating rerere cache and nightly.conf... Done.
@@ -263,7 +263,7 @@ when it's tricky or something fails in the below procedure.
 $ git commit -a
 
git will then store the conflict resolution internally (see git help rerere
-   for how this is implemented). Then re-run -nigthly generation to confirm the
+   for how this is implemented). Then re-run drm-tip generation to confirm the
resolution has been captured correctly by git (sometimes git rerere can't
match up your resolution with the conflict for odd reasons) and to make sure
there's no other conflict in later merges: ::
@@ -457,7 +457,7 @@ stakeholders. There's three components for that:
   domain experts, maybe maintainers. Also include maintainers and reviewers of
   the userspace component for new ABI, which often means non-Intel people. In
   case of doubt ask maintainers for a reasonable list of people. Make sure you
-  gather their input actively, don't expect them to deliver it on their on -
+  gather their 

[Intel-gfx] [drm-intel:drm-intel-nightly 1066/1091] drivers/gpu/drm/drm_plane.c:933:48-49: ERROR: reference preceded by free on line 926 (fwd)

[Julia Lawall]

The kfree on line 926 would only be a problem for the references to e on
lines 933 and 937 if the return value of drm_event_reserve_init can be
-EDEADLK.

julia

-- Forwarded message --
Date: Thu, 30 Mar 2017 00:48:54 +0800
From: kbuild test robot 
To: kbu...@01.org
Cc: Julia Lawall 
Subject: [drm-intel:drm-intel-nightly 1066/1091]
drivers/gpu/drm/drm_plane.c:933:48-49: ERROR: reference preceded by free on
line 926

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head:   2f9f22b419350cafb06ba7e5342bc461fcb0afca
commit: 29dc0d1de18239cf3ef8bab578b8321ed340d81c [1066/1091] drm: Roll out 
acquire context for the page_flip ioctl
:: branch date: 4 hours ago
:: commit date: 9 hours ago

>> drivers/gpu/drm/drm_plane.c:933:48-49: ERROR: reference preceded by free on 
>> line 926
   drivers/gpu/drm/drm_plane.c:937:41-42: ERROR: reference preceded by free on 
line 926

git remote add drm-intel git://anongit.freedesktop.org/drm-intel
git remote update drm-intel
git checkout 29dc0d1de18239cf3ef8bab578b8321ed340d81c
vim +933 drivers/gpu/drm/drm_plane.c

43968d7b Daniel Vetter 2016-09-21  920  }
43968d7b Daniel Vetter 2016-09-21  921  e->event.base.type = 
DRM_EVENT_FLIP_COMPLETE;
43968d7b Daniel Vetter 2016-09-21  922  e->event.base.length = 
sizeof(e->event);
43968d7b Daniel Vetter 2016-09-21  923  e->event.user_data = 
page_flip->user_data;
43968d7b Daniel Vetter 2016-09-21  924  ret = 
drm_event_reserve_init(dev, file_priv, >base, >event.base);
43968d7b Daniel Vetter 2016-09-21  925  if (ret) {
43968d7b Daniel Vetter 2016-09-21 @926  kfree(e);
43968d7b Daniel Vetter 2016-09-21  927  goto out;
43968d7b Daniel Vetter 2016-09-21  928  }
43968d7b Daniel Vetter 2016-09-21  929  }
43968d7b Daniel Vetter 2016-09-21  930
43968d7b Daniel Vetter 2016-09-21  931  crtc->primary->old_fb = 
crtc->primary->fb;
43968d7b Daniel Vetter 2016-09-21  932  if 
(crtc->funcs->page_flip_target)
43968d7b Daniel Vetter 2016-09-21 @933  ret = 
crtc->funcs->page_flip_target(crtc, fb, e,
43968d7b Daniel Vetter 2016-09-21  934  
page_flip->flags,
43968d7b Daniel Vetter 2016-09-21  935  
target_vblank);
43968d7b Daniel Vetter 2016-09-21  936  else

:: The code at line 933 was first introduced by commit
:: 43968d7b806d7a7e021261294c583a216fddf0e5 drm: Extract drm_plane.[hc]

:: TO: Daniel Vetter 
:: CC: Sean Paul 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use LINEAR modifier instead of NONE

[Ville Syrjälä]

On Wed, Mar 29, 2017 at 11:03:40PM +0300, Ville Syrjälä wrote:
> On Fri, Mar 24, 2017 at 02:29:48PM -0700, Ben Widawsky wrote:
> > They're the same, so use the one which makes more sense.
> > 
> > Signed-off-by: Ben Widawsky 
> 
> Reviewed-by: Ville Syrjälä 

And pushed to dinq immediately. Thanks for the patch.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 28 ++--
> >  1 file changed, 14 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9a28a8917dc1..696d106461f8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1997,7 +1997,7 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> > *fb, int plane)
> > unsigned int cpp = fb->format->cpp[plane];
> >  
> > switch (fb->modifier) {
> > -   case DRM_FORMAT_MOD_NONE:
> > +   case DRM_FORMAT_MOD_LINEAR:
> > return cpp;
> > case I915_FORMAT_MOD_X_TILED:
> > if (IS_GEN2(dev_priv))
> > @@ -2033,7 +2033,7 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> > *fb, int plane)
> >  static unsigned int
> >  intel_tile_height(const struct drm_framebuffer *fb, int plane)
> >  {
> > -   if (fb->modifier == DRM_FORMAT_MOD_NONE)
> > +   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> > return 1;
> > else
> > return intel_tile_size(to_i915(fb->dev)) /
> > @@ -2107,7 +2107,7 @@ static unsigned int intel_surf_alignment(const struct 
> > drm_framebuffer *fb,
> > return 4096;
> >  
> > switch (fb->modifier) {
> > -   case DRM_FORMAT_MOD_NONE:
> > +   case DRM_FORMAT_MOD_LINEAR:
> > return intel_linear_alignment(dev_priv);
> > case I915_FORMAT_MOD_X_TILED:
> > if (INTEL_GEN(dev_priv) >= 9)
> > @@ -2290,7 +2290,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
> >  
> > WARN_ON(new_offset > old_offset);
> >  
> > -   if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> > +   if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> > unsigned int tile_size, tile_width, tile_height;
> > unsigned int pitch_tiles;
> >  
> > @@ -2345,7 +2345,7 @@ static u32 _intel_compute_tile_offset(const struct 
> > drm_i915_private *dev_priv,
> > if (alignment)
> > alignment--;
> >  
> > -   if (fb_modifier != DRM_FORMAT_MOD_NONE) {
> > +   if (fb_modifier != DRM_FORMAT_MOD_LINEAR) {
> > unsigned int tile_size, tile_width, tile_height;
> > unsigned int tile_rows, tiles, pitch_tiles;
> >  
> > @@ -2471,7 +2471,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> > DRM_ROTATE_0, tile_size);
> > offset /= tile_size;
> >  
> > -   if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> > +   if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
> > unsigned int tile_width, tile_height;
> > unsigned int pitch_tiles;
> > struct drm_rect r;
> > @@ -2803,7 +2803,7 @@ static int skl_max_plane_width(const struct 
> > drm_framebuffer *fb, int plane,
> > int cpp = fb->format->cpp[plane];
> >  
> > switch (fb->modifier) {
> > -   case DRM_FORMAT_MOD_NONE:
> > +   case DRM_FORMAT_MOD_LINEAR:
> > case I915_FORMAT_MOD_X_TILED:
> > switch (cpp) {
> > case 8:
> > @@ -3199,7 +3199,7 @@ static void ironlake_update_primary_plane(struct 
> > drm_plane *primary,
> >  static u32
> >  intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
> >  {
> > -   if (fb->modifier == DRM_FORMAT_MOD_NONE)
> > +   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
> > return 64;
> > else
> > return intel_tile_width_bytes(fb, plane);
> > @@ -3298,7 +3298,7 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> >  static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
> >  {
> > switch (fb_modifier) {
> > -   case DRM_FORMAT_MOD_NONE:
> > +   case DRM_FORMAT_MOD_LINEAR:
> > break;
> > case I915_FORMAT_MOD_X_TILED:
> > return PLANE_CTL_TILED_X;
> > @@ -8426,7 +8426,7 @@ skylake_get_initial_plane_config(struct intel_crtc 
> > *crtc,
> > tiling = val & PLANE_CTL_TILED_MASK;
> > switch (tiling) {
> > case PLANE_CTL_TILED_LINEAR:
> > -   fb->modifier = DRM_FORMAT_MOD_NONE;
> > +   fb->modifier = DRM_FORMAT_MOD_LINEAR;
> > break;
> > case PLANE_CTL_TILED_X:
> > plane_config->tiling = I915_TILING_X;
> > @@ -10399,7 +10399,7 @@ static void skl_do_mmio_flip(struct intel_crtc 
> > *intel_crtc,
> > ctl = I915_READ(PLANE_CTL(pipe, 0));
> > ctl &= ~PLANE_CTL_TILED_MASK;
> > switch (fb->modifier) {
> > -   case DRM_FORMAT_MOD_NONE:
> > +   case DRM_FORMAT_MOD_LINEAR:
> > break;
> > case I915_FORMAT_MOD_X_TILED:
> > ctl |= 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add format modifiers for Intel

[Ville Syrjälä]

On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
> 
> v2:
>   - Add LINEAR and Yf modifiers to list (Ville)
>   - Combine i8xx and i965 into one list of formats (Ville)
>   - Allow 1010102 formats for Y/Yf tiled (Ville)
> 
> v3:
>   - Handle cursor formats (Ville)
>   - Put handling for LINEAR in the mod_support functions (Ville)
> 
> Cc: Ville Syrjälä 
> Cc: Kristian H. Kristensen 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 112 
> +--
>  drivers/gpu/drm/i915/intel_sprite.c  |  25 +++-
>  2 files changed, 131 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 802a8449c5d3..bb559a116fda 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
>   DRM_FORMAT_XBGR2101010,
>  };
>  
> +static const uint64_t i9xx_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
>  static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_C8,
>   DRM_FORMAT_RGB565,
> @@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_VYUY,
>  };
>  
> +static const uint64_t skl_format_modifiers[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
>  /* Cursor formats */
>  static const uint32_t intel_cursor_formats[] = {
>   DRM_FORMAT_ARGB,
> @@ -13453,6 +13467,83 @@ void intel_plane_destroy(struct drm_plane *plane)
>   kfree(to_intel_plane(plane));
>  }
>  
> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XRGB:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + (modifier >= I915_FORMAT_MOD_X_TILED &&
> +  modifier < I915_FORMAT_MOD_Yf_TILED);

The >= stuff makes this harder to parse than it should be IMO.
I'd just list each modifier explicitly.

> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + (modifier >= I915_FORMAT_MOD_X_TILED &&
> + modifier <= I915_FORMAT_MOD_Yf_TILED);

ditto. At first I couldn't even spot the difference between this and
the C8 case.

> + case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_YVYU:
> + case DRM_FORMAT_UYVY:
> + case DRM_FORMAT_VYUY:
> + return modifier == DRM_FORMAT_MOD_LINEAR;

Any modifier will do for these formats.

> + default:
> + return false;
> + }
> +
> +}
> +
> +static bool intel_plane_format_mod_supported(struct drm_plane *plane,
> +  uint32_t format,
> +  uint64_t modifier)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + if (INTEL_GEN(dev_priv) >= 9)
> + return skl_mod_supported(format, modifier);
> + else if (INTEL_GEN(dev_priv) >= 4)
> + return i965_mod_supported(format, modifier);
> + else
> + return i8xx_mod_supported(format, modifier);
> +
> + return false;
> +}

I'd also like to see .format_mod_supported() + modifiers[] for
cursors as well. Those should only accept LINEAR+ARGB.

Apart from those issues, I think this is looking pretty good.

> +
>  const 

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use LINEAR modifier instead of NONE

[Ville Syrjälä]

On Fri, Mar 24, 2017 at 02:29:48PM -0700, Ben Widawsky wrote:
> They're the same, so use the one which makes more sense.
> 
> Signed-off-by: Ben Widawsky 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9a28a8917dc1..696d106461f8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1997,7 +1997,7 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> *fb, int plane)
>   unsigned int cpp = fb->format->cpp[plane];
>  
>   switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
>   return cpp;
>   case I915_FORMAT_MOD_X_TILED:
>   if (IS_GEN2(dev_priv))
> @@ -2033,7 +2033,7 @@ intel_tile_width_bytes(const struct drm_framebuffer 
> *fb, int plane)
>  static unsigned int
>  intel_tile_height(const struct drm_framebuffer *fb, int plane)
>  {
> - if (fb->modifier == DRM_FORMAT_MOD_NONE)
> + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
>   return 1;
>   else
>   return intel_tile_size(to_i915(fb->dev)) /
> @@ -2107,7 +2107,7 @@ static unsigned int intel_surf_alignment(const struct 
> drm_framebuffer *fb,
>   return 4096;
>  
>   switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
>   return intel_linear_alignment(dev_priv);
>   case I915_FORMAT_MOD_X_TILED:
>   if (INTEL_GEN(dev_priv) >= 9)
> @@ -2290,7 +2290,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
>  
>   WARN_ON(new_offset > old_offset);
>  
> - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
>   unsigned int tile_size, tile_width, tile_height;
>   unsigned int pitch_tiles;
>  
> @@ -2345,7 +2345,7 @@ static u32 _intel_compute_tile_offset(const struct 
> drm_i915_private *dev_priv,
>   if (alignment)
>   alignment--;
>  
> - if (fb_modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb_modifier != DRM_FORMAT_MOD_LINEAR) {
>   unsigned int tile_size, tile_width, tile_height;
>   unsigned int tile_rows, tiles, pitch_tiles;
>  
> @@ -2471,7 +2471,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
>   DRM_ROTATE_0, tile_size);
>   offset /= tile_size;
>  
> - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
>   unsigned int tile_width, tile_height;
>   unsigned int pitch_tiles;
>   struct drm_rect r;
> @@ -2803,7 +2803,7 @@ static int skl_max_plane_width(const struct 
> drm_framebuffer *fb, int plane,
>   int cpp = fb->format->cpp[plane];
>  
>   switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
>   case I915_FORMAT_MOD_X_TILED:
>   switch (cpp) {
>   case 8:
> @@ -3199,7 +3199,7 @@ static void ironlake_update_primary_plane(struct 
> drm_plane *primary,
>  static u32
>  intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
>  {
> - if (fb->modifier == DRM_FORMAT_MOD_NONE)
> + if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
>   return 64;
>   else
>   return intel_tile_width_bytes(fb, plane);
> @@ -3298,7 +3298,7 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
>  static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
>  {
>   switch (fb_modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
>   break;
>   case I915_FORMAT_MOD_X_TILED:
>   return PLANE_CTL_TILED_X;
> @@ -8426,7 +8426,7 @@ skylake_get_initial_plane_config(struct intel_crtc 
> *crtc,
>   tiling = val & PLANE_CTL_TILED_MASK;
>   switch (tiling) {
>   case PLANE_CTL_TILED_LINEAR:
> - fb->modifier = DRM_FORMAT_MOD_NONE;
> + fb->modifier = DRM_FORMAT_MOD_LINEAR;
>   break;
>   case PLANE_CTL_TILED_X:
>   plane_config->tiling = I915_TILING_X;
> @@ -10399,7 +10399,7 @@ static void skl_do_mmio_flip(struct intel_crtc 
> *intel_crtc,
>   ctl = I915_READ(PLANE_CTL(pipe, 0));
>   ctl &= ~PLANE_CTL_TILED_MASK;
>   switch (fb->modifier) {
> - case DRM_FORMAT_MOD_NONE:
> + case DRM_FORMAT_MOD_LINEAR:
>   break;
>   case I915_FORMAT_MOD_X_TILED:
>   ctl |= PLANE_CTL_TILED_X;
> @@ -13756,7 +13756,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
>   return -ENOMEM;
>   }
>  
> - if (fb->modifier != DRM_FORMAT_MOD_NONE) {
> + if (fb->modifier != 

Re: [Intel-gfx] [PATCH] drm: Fixup failure paths in drm_atomic_helper_set_config

[Harry Wentland]

Of course. I totally missed that.

Reviewed-by: Harry Wentland 

Harry

On 2017-03-29 01:41 PM, Daniel Vetter wrote:

I've screwed this up when removing the legacy backoff hack.

Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from 
set_config")
Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9dc67b52b905..d5915317e7d3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2294,10 +2294,11 @@ int drm_atomic_helper_set_config(struct drm_mode_set 
*set,
state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
-   return ret;
+   goto fail;
  
  	ret = drm_atomic_commit(state);
  
+fail:

drm_atomic_state_put(state);
return ret;
  }


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

[Intel-gfx] [PATCH 1/3] drm/i915: Group all the global context information together

[Chris Wilson]

Create a substruct to hold all the global context state under
drm_i915_private.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  4 +--
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 20 +++---
 drivers/gpu/drm/i915/i915_gem.c  |  1 -
 drivers/gpu/drm/i915/i915_gem_context.c  | 34 +---
 drivers/gpu/drm/i915/i915_sysfs.c|  2 +-
 drivers/gpu/drm/i915/intel_lrc.c |  2 +-
 drivers/gpu/drm/i915/selftests/mock_context.c|  2 +-
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  2 +-
 9 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8a7f57318a87..a75d848901d4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1956,7 +1956,7 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
if (ret)
return ret;
 
-   list_for_each_entry(ctx, _priv->context_list, link) {
+   list_for_each_entry(ctx, _priv->contexts.list, link) {
seq_printf(m, "HW context %u ", ctx->hw_id);
if (ctx->pid) {
struct task_struct *task;
@@ -2062,7 +2062,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
if (ret)
return ret;
 
-   list_for_each_entry(ctx, _priv->context_list, link)
+   list_for_each_entry(ctx, _priv->contexts.list, link)
for_each_engine(engine, dev_priv, id)
i915_dump_lrc_obj(m, ctx, engine);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e98f6c90efe0..111874c3a140 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -560,7 +560,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
 
i915_gem_drain_freed_objects(dev_priv);
 
-   WARN_ON(!list_empty(_priv->context_list));
+   WARN_ON(!list_empty(_priv->contexts.list));
 }
 
 static int i915_load_modeset_init(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f263715f65c9..45bc9a65ec53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2287,13 +2287,6 @@ struct drm_i915_private {
DECLARE_HASHTABLE(mm_structs, 7);
struct mutex mm_lock;
 
-   /* The hw wants to have a stable context identifier for the lifetime
-* of the context (for OA, PASID, faults, etc). This is limited
-* in execlists to 21 bits.
-*/
-   struct ida context_hw_ida;
-#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
-
/* Kernel Modesetting */
 
struct intel_crtc *plane_to_crtc_mapping[I915_MAX_PIPES];
@@ -2372,8 +2365,17 @@ struct drm_i915_private {
 */
struct mutex av_mutex;
 
-   uint32_t hw_context_size;
-   struct list_head context_list;
+   struct {
+   struct list_head list;
+   u32 hw_size;
+
+   /* The hw wants to have a stable context identifier for the
+* lifetime of the context (for OA, PASID, faults, etc).
+* This is limited in execlists to 21 bits.
+*/
+   struct ida hw_ida;
+#define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
+   } contexts;
 
u32 fdi_rx_config;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 10f2d26cb2a9..fef212821994 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4784,7 +4784,6 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
if (err)
goto err_dependencies;
 
-   INIT_LIST_HEAD(_priv->context_list);
INIT_WORK(_priv->mm.free_work, __i915_gem_free_work);
init_llist_head(_priv->mm.free_list);
INIT_LIST_HEAD(_priv->mm.unbound_list);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5aab9f97385c..c0f3acece66a 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -214,7 +214,7 @@ void i915_gem_context_free(struct kref *ctx_ref)
 
list_del(>link);
 
-   ida_simple_remove(>i915->context_hw_ida, ctx->hw_id);
+   ida_simple_remove(>i915->contexts.hw_ida, ctx->hw_id);
kfree(ctx);
 }
 
@@ -270,7 +270,7 @@ static int assign_hw_id(struct drm_i915_private *dev_priv, 
unsigned *out)
 {
int ret;
 
-   ret = ida_simple_get(_priv->context_hw_ida,
+   ret = ida_simple_get(_priv->contexts.hw_ida,
 0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
if (ret < 0) {
/* Contexts are only released when no longer active.
@@ -278,7 +278,7 @@ static int assign_hw_id(struct drm_i915_private 

[Intel-gfx] [PATCH 3/3] drm/i915: Enable rcu-only context lookups

[Chris Wilson]

Whilst the contents of the context is still protected by the big
struct_mutex, this is not much of an improvement. It is just one tiny
step towards reducing our BKL.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h| 16 +--
 drivers/gpu/drm/i915/i915_gem_context.c| 74 +++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 +
 3 files changed, 58 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aa5b7c8969ab..0d68966673bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3505,15 +3505,21 @@ void i915_gem_object_save_bit_17_swizzle(struct 
drm_i915_gem_object *obj,
 struct sg_table *pages);
 
 static inline struct i915_gem_context *
+__i915_gem_context_lookup_rcu(struct drm_i915_file_private *file_priv, u32 id)
+{
+   return idr_find(_priv->context_idr, id);
+}
+
+static inline struct i915_gem_context *
 i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
 {
struct i915_gem_context *ctx;
 
-   lockdep_assert_held(_priv->dev_priv->drm.struct_mutex);
-
-   ctx = idr_find(_priv->context_idr, id);
-   if (!ctx)
-   return ERR_PTR(-ENOENT);
+   rcu_read_lock();
+   ctx = __i915_gem_context_lookup_rcu(file_priv, id);
+   if (ctx && !kref_get_unless_zero(>ref))
+   ctx = NULL;
+   rcu_read_unlock();
 
return ctx;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3df050ee6ce4..d53efa107c03 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -225,6 +225,8 @@ static void free_contexts(struct work_struct *work)
while ((freed = llist_del_all(_priv->contexts.free_list))) {
struct i915_gem_context *ctx, *cn;
 
+   synchronize_rcu();
+
mutex_lock(_priv->drm.struct_mutex);
llist_for_each_entry_safe(ctx, cn, freed, free_link)
i915_gem_context_free(ctx);
@@ -1112,20 +1114,19 @@ int i915_gem_context_destroy_ioctl(struct drm_device 
*dev, void *data,
if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
return -ENOENT;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
-   if (IS_ERR(ctx)) {
-   mutex_unlock(>struct_mutex);
-   return PTR_ERR(ctx);
-   }
+   if (!ctx)
+   return -ENOENT;
+
+   ret = mutex_lock_interruptible(>struct_mutex);
+   if (ret)
+   goto out;
 
__destroy_hw_context(ctx, file_priv);
mutex_unlock(>struct_mutex);
 
-   DRM_DEBUG("HW context %d destroyed\n", args->ctx_id);
+out:
+   i915_gem_context_put(ctx);
return 0;
 }
 
@@ -1137,15 +1138,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
struct i915_gem_context *ctx;
int ret;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
-   if (IS_ERR(ctx)) {
-   mutex_unlock(>struct_mutex);
-   return PTR_ERR(ctx);
-   }
+   if (!ctx)
+   return -ENOENT;
 
args->size = 0;
switch (args->param) {
@@ -1176,8 +1171,8 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
ret = -EINVAL;
break;
}
-   mutex_unlock(>struct_mutex);
 
+   i915_gem_context_put(ctx);
return ret;
 }
 
@@ -1189,15 +1184,13 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
struct i915_gem_context *ctx;
int ret;
 
+   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
+   if (!ctx)
+   return -ENOENT;
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
-   return ret;
-
-   ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
-   if (IS_ERR(ctx)) {
-   mutex_unlock(>struct_mutex);
-   return PTR_ERR(ctx);
-   }
+   goto out;
 
switch (args->param) {
case I915_CONTEXT_PARAM_BAN_PERIOD:
@@ -1252,6 +1245,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
}
mutex_unlock(>struct_mutex);
 
+out:
+   i915_gem_context_put(ctx);
return ret;
 }
 
@@ -1269,27 +1264,30 @@ int i915_gem_context_reset_stats_ioctl(struct 
drm_device *dev,
if (args->ctx_id == DEFAULT_CONTEXT_HANDLE && !capable(CAP_SYS_ADMIN))
return -EPERM;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
+   ret = -ENOENT;
+  

[Intel-gfx] [PATCH 2/3] drm/i915: Allows contexts to be unreferenced locklessly

[Chris Wilson]

If we move the actual cleanup of the context to a worker, we can allow
the final free to be called from any context and avoid undue latency in
the caller.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/scheduler.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h | 23 ++-
 drivers/gpu/drm/i915/i915_gem_context.c | 32 +---
 drivers/gpu/drm/i915/i915_gem_context.h | 15 ++-
 drivers/gpu/drm/i915/i915_perf.c|  4 ++--
 5 files changed, 48 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index d9a735310e75..07db9a5c0293 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -597,7 +597,7 @@ int intel_gvt_init_workload_scheduler(struct intel_gvt *gvt)
 
 void intel_vgpu_clean_gvt_context(struct intel_vgpu *vgpu)
 {
-   i915_gem_context_put_unlocked(vgpu->shadow_ctx);
+   i915_gem_context_put(vgpu->shadow_ctx);
 }
 
 int intel_vgpu_init_gvt_context(struct intel_vgpu *vgpu)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 45bc9a65ec53..aa5b7c8969ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2367,6 +2367,8 @@ struct drm_i915_private {
 
struct {
struct list_head list;
+   struct llist_head free_list;
+   struct work_struct free_work;
u32 hw_size;
 
/* The hw wants to have a stable context identifier for the
@@ -3516,27 +3518,6 @@ i915_gem_context_lookup(struct drm_i915_file_private 
*file_priv, u32 id)
return ctx;
 }
 
-static inline struct i915_gem_context *
-i915_gem_context_get(struct i915_gem_context *ctx)
-{
-   kref_get(>ref);
-   return ctx;
-}
-
-static inline void i915_gem_context_put(struct i915_gem_context *ctx)
-{
-   lockdep_assert_held(>i915->drm.struct_mutex);
-   kref_put(>ref, i915_gem_context_free);
-}
-
-static inline void i915_gem_context_put_unlocked(struct i915_gem_context *ctx)
-{
-   struct mutex *lock = >i915->drm.struct_mutex;
-
-   if (kref_put_mutex(>ref, i915_gem_context_free, lock))
-   mutex_unlock(lock);
-}
-
 static inline struct intel_timeline *
 i915_gem_context_lookup_timeline(struct i915_gem_context *ctx,
 struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index c0f3acece66a..3df050ee6ce4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -184,13 +184,11 @@ static void vma_lut_free(struct i915_gem_context *ctx)
kvfree(lut->ht);
 }
 
-void i915_gem_context_free(struct kref *ctx_ref)
+static void i915_gem_context_free(struct i915_gem_context *ctx)
 {
-   struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
int i;
 
lockdep_assert_held(>i915->drm.struct_mutex);
-   trace_i915_context_free(ctx);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
 
vma_lut_free(ctx);
@@ -218,6 +216,32 @@ void i915_gem_context_free(struct kref *ctx_ref)
kfree(ctx);
 }
 
+static void free_contexts(struct work_struct *work)
+{
+   struct drm_i915_private *dev_priv =
+   container_of(work, struct drm_i915_private, contexts.free_work);
+   struct llist_node *freed;
+
+   while ((freed = llist_del_all(_priv->contexts.free_list))) {
+   struct i915_gem_context *ctx, *cn;
+
+   mutex_lock(_priv->drm.struct_mutex);
+   llist_for_each_entry_safe(ctx, cn, freed, free_link)
+   i915_gem_context_free(ctx);
+   mutex_unlock(_priv->drm.struct_mutex);
+   }
+}
+
+void i915_gem_context_release(struct kref *ctx_ref)
+{
+   struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
+   struct drm_i915_private *i915 = ctx->i915;
+
+   trace_i915_context_free(ctx);
+   if (llist_add(>free_link, >contexts.free_list))
+   queue_work(i915->wq, >contexts.free_work);
+}
+
 static struct drm_i915_gem_object *
 alloc_context_obj(struct drm_i915_private *dev_priv, u64 size)
 {
@@ -512,6 +536,8 @@ int i915_gem_context_init(struct drm_i915_private *dev_priv)
return 0;
 
INIT_LIST_HEAD(_priv->contexts.list);
+   INIT_WORK(_priv->contexts.free_work, free_contexts);
+   init_llist_head(_priv->contexts.free_list);
 
if (intel_vgpu_active(dev_priv) &&
HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index db5b28a28d75..526a4a87d23c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -86,6 +86,7 @@ struct i915_gem_context {
 
/** link: place with 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fixup failure paths in drm_atomic_helper_set_config

[Patchwork]

== Series Details ==

Series: drm: Fixup failure paths in drm_atomic_helper_set_config
URL   : https://patchwork.freedesktop.org/series/22106/
State : success

== Summary ==

Series 22106v1 drm: Fixup failure paths in drm_atomic_helper_set_config
https://patchwork.freedesktop.org/api/1.0/series/22106/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 459s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 458s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 577s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 548s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 584s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 505s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 513s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 432s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 430s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 445s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 518s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 501s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 487s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 595s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 492s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 601s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 486s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 515s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 459s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 552s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 425s

2f9f22b419350cafb06ba7e5342bc461fcb0afca drm-tip: 2017y-03m-29d-12h-52m-56s UTC 
integration manifest
c45202f drm: Fixup failure paths in drm_atomic_helper_set_config

== Logs ==

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

Re: [Intel-gfx] [PATCH RESEND 4/4] drm/i915/opregion: let user specify override VBT via firmware load

[Bob Paauwe]

On Wed, 29 Mar 2017 13:32:58 +0300
Jani Nikula  wrote:

> Sometimes it would be most enlightening to debug systems by replacing
> the VBT to be used. For example, in the referenced bug the BIOS provides
> different VBT depending on the boot mode (UEFI vs. legacy). It would be
> interesting to try the failing boot mode with the VBT from the working
> boot, and see if that makes a difference.
> 
> Add a module parameter to load the VBT using the firmware loader, not
> unlike the EDID firmware mechanism.
> 
> As a starting point for experimenting, one can pick up the BIOS provided
> VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt.

Jani,

I really like this idea and believe that it will be useful.  Thanks for
doing this!

> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  4 
>  drivers/gpu/drm/i915/i915_params.h|  1 +
>  drivers/gpu/drm/i915/intel_opregion.c | 40 
> +++
>  3 files changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index b6a7e363d076..6d5d334f50b1 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -115,6 +115,10 @@ MODULE_PARM_DESC(vbt_sdvo_panel_type,
>   "Override/Ignore selection of SDVO panel mode in the VBT "
>   "(-2=ignore, -1=auto [default], index in VBT BIOS table)");
>  
> +module_param_named_unsafe(vbt_firmware, i915.vbt_firmware, charp, 0400);
> +MODULE_PARM_DESC(vbt_firmware,
> +  "Load VBT from specified file under /lib/firmware");
> +
>  module_param_named_unsafe(reset, i915.reset, bool, 0600);
>  MODULE_PARM_DESC(reset, "Attempt GPU resets (default: true)");
>  
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 34148cc8637c..0aeb106e06af 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -28,6 +28,7 @@
>  #include  /* for __read_mostly */
>  
>  #define I915_PARAMS_FOR_EACH(func) \
> + func(char *, vbt_firmware); \
>   func(int, modeset); \
>   func(int, panel_ignore_lid); \
>   func(int, semaphores); \
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index d44465190dc1..7cbd801516ab 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -27,6 +27,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -912,6 +913,42 @@ static const struct dmi_system_id 
> intel_no_opregion_vbt[] = {
>   { }
>  };
>  
> +static int intel_load_vbt_firmware(struct drm_i915_private *dev_priv)
> +{
> + struct intel_opregion *opregion = _priv->opregion;
> + const struct firmware *fw = NULL;
> + const char *name = i915.vbt_firmware;
> + int ret;
> +
> + if (!name || !*name)
> + return -ENOENT;
> +
> + ret = request_firmware(, name, _priv->drm.pdev->dev);
> + if (ret) {
> + DRM_ERROR("Requesting VBT firmware \"%s\" failed (%d)\n",
> +   name, ret);
> + return ret;
> + }
> +
> + if (intel_bios_is_valid_vbt(fw->data, fw->size)) {
> + opregion->vbt = kmemdup(fw->data, fw->size, GFP_KERNEL);
> + if (opregion->vbt) {
> + DRM_DEBUG_KMS("Found valid VBT firmware \"%s\"\n", 
> name);
> + opregion->vbt_size = fw->size;
> + ret = 0;
> + } else {
> + ret = -ENOMEM;

Since the errors propagated, it might be a good idea to add a debug
message here too.

> + }
> + } else {
> + DRM_DEBUG_KMS("Invalid VBT firmware \"%s\"\n", name);
> + ret = -EINVAL;
> + }
> +
> + release_firmware(fw);
> +
> + return ret;
> +}
> +
>  int intel_opregion_setup(struct drm_i915_private *dev_priv)
>  {
>   struct intel_opregion *opregion = _priv->opregion;
> @@ -974,6 +1011,9 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   if (mboxes & MBOX_ASLE_EXT)
>   DRM_DEBUG_DRIVER("ASLE extension supported\n");
>  
> + if (!intel_load_vbt_firmware(dev_priv))
> + goto out;

I find the condition a bit confusing. It reads to me as "if firmware
not loaded, goto out" which is backwards from what it's really doing.
Since you're ignoring the error return value anyway, making 
intel_load_vbt_firmware() a boolean it would make it read better.

However, if you have some future plan to propagate errors, then keep
I'm fine with it all as is.

> +
>   if (dmi_check_system(intel_no_opregion_vbt))
>   goto out;
>  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

Re: [Intel-gfx] [PATCH RESEND 3/4] drm/i915/opregion: debug log about invalid ACPI OpRegion VBT

[Bob Paauwe]

On Wed, 29 Mar 2017 13:32:57 +0300
Jani Nikula  wrote:

> Leave more breadcrumbs for debuggers.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Bob Paauwe 

> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 2b64cb6691eb..d44465190dc1 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -989,6 +989,8 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   opregion->vbt = vbt;
>   opregion->vbt_size = vbt_size;
>   goto out;
> + } else {
> + DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (RVDA)\n");
>   }
>   }
>  
> @@ -1007,6 +1009,8 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox 
> #4)\n");
>   opregion->vbt = vbt;
>   opregion->vbt_size = vbt_size;
> + } else {
> + DRM_DEBUG_KMS("Invalid VBT in ACPI OpRegion (Mailbox #4)\n");
>   }
>  
>  out:



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH RESEND 2/4] drm/i915/opregion: try to validate RVDA VBT only if it's there

[Bob Paauwe]

On Wed, 29 Mar 2017 13:32:56 +0300
Jani Nikula  wrote:

> Seems more sensible this way, and reduces indent for the more common
> case.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Bob Paauwe 

> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 41 
> +--
>  1 file changed, 20 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 76a39ee6d005..2b64cb6691eb 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -920,8 +920,8 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   char buf[sizeof(OPREGION_SIGNATURE)];
>   int err = 0;
>   void *base;
> - const void *vbt = NULL;
> - u32 vbt_size = 0;
> + const void *vbt;
> + u32 vbt_size;
>  
>   BUILD_BUG_ON(sizeof(struct opregion_header) != 0x100);
>   BUILD_BUG_ON(sizeof(struct opregion_acpi) != 0x100);
> @@ -984,30 +984,29 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
> MEMREMAP_WB);
>   vbt = opregion->rvda;
>   vbt_size = opregion->asle->rvds;
> + if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> + DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion 
> (RVDA)\n");
> + opregion->vbt = vbt;
> + opregion->vbt_size = vbt_size;
> + goto out;
> + }
>   }
>  
> + vbt = base + OPREGION_VBT_OFFSET;
> + /*
> +  * The VBT specification says that if the ASLE ext mailbox is not used
> +  * its area is reserved, but on some CHT boards the VBT extends into the
> +  * ASLE ext area. Allow this even though it is against the spec, so we
> +  * do not end up rejecting the VBT on those boards (and end up not
> +  * finding the LCD panel because of this).
> +  */
> + vbt_size = (mboxes & MBOX_ASLE_EXT) ?
> + OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
> + vbt_size -= OPREGION_VBT_OFFSET;
>   if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> - DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (RVDA)\n");
> + DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (Mailbox 
> #4)\n");
>   opregion->vbt = vbt;
>   opregion->vbt_size = vbt_size;
> - } else {
> - vbt = base + OPREGION_VBT_OFFSET;
> - /*
> -  * The VBT specification says that if the ASLE ext mailbox is
> -  * not used its area is reserved, but on some CHT boards the VBT
> -  * extends into the ASLE ext area. Allow this even though it is
> -  * against the spec, so we do not end up rejecting the VBT on
> -  * those boards (and end up not finding the LCD panel because of
> -  * this).
> -  */
> - vbt_size = (mboxes & MBOX_ASLE_EXT) ?
> - OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
> - vbt_size -= OPREGION_VBT_OFFSET;
> - if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> - DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion 
> (Mailbox #4)\n");
> - opregion->vbt = vbt;
> - opregion->vbt_size = vbt_size;
> - }
>   }
>  
>  out:



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH RESEND 1/4] drm/i915/opregion: bail out early for systems with no opregion VBT

[Bob Paauwe]

On Wed, 29 Mar 2017 13:32:55 +0300
Jani Nikula  wrote:

> Reduce indent. No functional changes.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Bob Paauwe 

> ---
>  drivers/gpu/drm/i915/intel_opregion.c | 64 
> +--
>  1 file changed, 32 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index 441c01466384..76a39ee6d005 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -920,6 +920,8 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   char buf[sizeof(OPREGION_SIGNATURE)];
>   int err = 0;
>   void *base;
> + const void *vbt = NULL;
> + u32 vbt_size = 0;
>  
>   BUILD_BUG_ON(sizeof(struct opregion_header) != 0x100);
>   BUILD_BUG_ON(sizeof(struct opregion_acpi) != 0x100);
> @@ -972,45 +974,43 @@ int intel_opregion_setup(struct drm_i915_private 
> *dev_priv)
>   if (mboxes & MBOX_ASLE_EXT)
>   DRM_DEBUG_DRIVER("ASLE extension supported\n");
>  
> - if (!dmi_check_system(intel_no_opregion_vbt)) {
> - const void *vbt = NULL;
> - u32 vbt_size = 0;
> -
> - if (opregion->header->opregion_ver >= 2 && opregion->asle &&
> - opregion->asle->rvda && opregion->asle->rvds) {
> - opregion->rvda = memremap(opregion->asle->rvda,
> -   opregion->asle->rvds,
> -   MEMREMAP_WB);
> - vbt = opregion->rvda;
> - vbt_size = opregion->asle->rvds;
> - }
> + if (dmi_check_system(intel_no_opregion_vbt))
> + goto out;
> +
> + if (opregion->header->opregion_ver >= 2 && opregion->asle &&
> + opregion->asle->rvda && opregion->asle->rvds) {
> + opregion->rvda = memremap(opregion->asle->rvda,
> +   opregion->asle->rvds,
> +   MEMREMAP_WB);
> + vbt = opregion->rvda;
> + vbt_size = opregion->asle->rvds;
> + }
>  
> + if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> + DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion (RVDA)\n");
> + opregion->vbt = vbt;
> + opregion->vbt_size = vbt_size;
> + } else {
> + vbt = base + OPREGION_VBT_OFFSET;
> + /*
> +  * The VBT specification says that if the ASLE ext mailbox is
> +  * not used its area is reserved, but on some CHT boards the VBT
> +  * extends into the ASLE ext area. Allow this even though it is
> +  * against the spec, so we do not end up rejecting the VBT on
> +  * those boards (and end up not finding the LCD panel because of
> +  * this).
> +  */
> + vbt_size = (mboxes & MBOX_ASLE_EXT) ?
> + OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
> + vbt_size -= OPREGION_VBT_OFFSET;
>   if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> - DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion 
> (RVDA)\n");
> + DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion 
> (Mailbox #4)\n");
>   opregion->vbt = vbt;
>   opregion->vbt_size = vbt_size;
> - } else {
> - vbt = base + OPREGION_VBT_OFFSET;
> - /*
> -  * The VBT specification says that if the ASLE ext
> -  * mailbox is not used its area is reserved, but
> -  * on some CHT boards the VBT extends into the
> -  * ASLE ext area. Allow this even though it is
> -  * against the spec, so we do not end up rejecting
> -  * the VBT on those boards (and end up not finding the
> -  * LCD panel because of this).
> -  */
> - vbt_size = (mboxes & MBOX_ASLE_EXT) ?
> - OPREGION_ASLE_EXT_OFFSET : OPREGION_SIZE;
> - vbt_size -= OPREGION_VBT_OFFSET;
> - if (intel_bios_is_valid_vbt(vbt, vbt_size)) {
> - DRM_DEBUG_KMS("Found valid VBT in ACPI OpRegion 
> (Mailbox #4)\n");
> - opregion->vbt = vbt;
> - opregion->vbt_size = vbt_size;
> - }
>   }
>   }
>  
> +out:
>   return 0;
>  
>  err_out:



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH v4 08/11] drm/exynos: Remove custom FB helper deferred setup

[Daniel Vetter]

On Wed, Mar 29, 2017 at 04:43:58PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  6 --
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 ---
>  2 files changed, 4 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 09d3c4c3c858..08f9533ddbe8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -399,8 +399,9 @@ static int exynos_drm_bind(struct device *dev)
>   /* init kms poll for handling hpd */
>   drm_kms_helper_poll_init(drm);
>  
> - /* force connectors detection */
> - drm_helper_hpd_irq_event(drm);
> + ret = exynos_drm_fbdev_init(drm);
> + if (ret)
> + goto err_cleanup_poll;
>  
>   /* register the DRM device */
>   ret = drm_dev_register(drm, 0);
> @@ -411,6 +412,7 @@ static int exynos_drm_bind(struct device *dev)
>  
>  err_cleanup_fbdev:
>   exynos_drm_fbdev_fini(drm);
> +err_cleanup_poll:
>   drm_kms_helper_poll_fini(drm);
>   exynos_drm_device_subdrv_remove(drm);
>  err_cleanup_vblank:
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 641531243e04..e64a1041dd29 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -183,24 +183,6 @@ static const struct drm_fb_helper_funcs 
> exynos_drm_fb_helper_funcs = {
>   .fb_probe = exynos_drm_fbdev_create,
>  };
>  
> -static bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
> -{
> - struct drm_connector *connector;
> - bool ret = false;
> -
> - mutex_lock(>mode_config.mutex);
> - list_for_each_entry(connector, >mode_config.connector_list, head) {
> - if (connector->status != connector_status_connected)
> - continue;
> -
> - ret = true;
> - break;
> - }
> - mutex_unlock(>mode_config.mutex);
> -
> - return ret;
> -}
> -
>  int exynos_drm_fbdev_init(struct drm_device *dev)
>  {
>   struct exynos_drm_fbdev *fbdev;
> @@ -211,9 +193,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
>   if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
>   return 0;
>  
> - if (!exynos_drm_fbdev_is_anything_connected(dev))
> - return 0;
> -
>   fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
>   if (!fbdev)
>   return -ENOMEM;
> @@ -306,6 +285,4 @@ void exynos_drm_output_poll_changed(struct drm_device 
> *dev)
>  
>   if (fb_helper)
>   drm_fb_helper_hotplug_event(fb_helper);

Tiny nit: I think you can remove the above NULL check too. With that:

Reviewed-by: Daniel Vetter 

> - else
> - exynos_drm_fbdev_init(dev);
>  }
> -- 
> 2.12.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Fixup failure paths in drm_atomic_helper_set_config

[Daniel Vetter]

I've screwed this up when removing the legacy backoff hack.

Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from 
set_config")
Cc: Harry Wentland 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9dc67b52b905..d5915317e7d3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2294,10 +2294,11 @@ int drm_atomic_helper_set_config(struct drm_mode_set 
*set,
state->acquire_ctx = ctx;
ret = __drm_atomic_helper_set_config(set, state);
if (ret != 0)
-   return ret;
+   goto fail;
 
ret = drm_atomic_commit(state);
 
+fail:
drm_atomic_state_put(state);
return ret;
 }
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining

[Manasi Navare]

On Wed, Mar 29, 2017 at 03:11:46PM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Ville Syrjälä  wrote:
> > On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
> >> On Tue, 28 Mar 2017, Manasi Navare  wrote:
> >> > Jani,
> >> >
> >> > Should I just hold on to this until your patch series
> >> > gets merged so I can rebase this on top of it?
> >> 
> >> I think I'd prefer that, especially so because I'm not sure that this
> >> patch does the right thing. Yes, this checks that the values are within
> >> bounds, but that they are within bounds doesn't make them any more valid
> >> for the current link if they are indeed stale!
> >
> > Can they be stale and still be within the bounds somehow?
> 
> Maybe not. Maybe I just don't follow. Perhaps the commit message
> deserves a better description of the cases where we hit the case.
>

So the idea here is to avoid using higher values of link rate/lane count
which are stale now due to an intermediate step of link rate fallback.
That is why the values cached in intel_dp structure will not be
within the bounds of common rates array and hence are termed as stale now.

Is there any other way for validating the values cached in intel_dp structure?
Since we dont zero them out on link failure, the driver can still mistaken them
as valid which is what I am trying to avoid here through this patch.

 
> >> >> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
> 
> Side note, it bugs me that the function name has a grammatical error.
> 
>

Change it to intel_dp_link_params_are_valid()?

Regards
Manasi

 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v8 1/3] drm_fourcc: Add new P010, P016 video format

[clinton . a . taylor]

From: Clint Taylor 

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.

P012 is a planar 4:2:0 YUV 12 bits per channel

P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.

V3: Added P012 and fixed cpp for P010
V4: format definition refined per review
V5: Format comment block for each new pixel format
V6: reversed Cb/Cr order in comments
v7: reversed Cb/Cr order in comments of header files, remove
the wrong part of commit message.
V8: reversed V7 changes except commit message and rebased.

Cc: Daniel Stone 
Cc: Ville Syrjälä 

Signed-off-by: Randy Li 
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_fourcc.c  |3 +++
 include/uapi/drm/drm_fourcc.h |   21 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152d..6101520 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -173,6 +173,9 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
+   { .format = DRM_FORMAT_P010,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P012,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
+   { .format = DRM_FORMAT_P016,.depth = 0,  
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
};
 
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 995c8f9..c995cc4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -142,6 +142,27 @@
 #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
non-subsampled Cb:Cr plane */
 
 /*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [10:6] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
+ */
+#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 2x2 
subsampled Cr:Cb plane 10 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y:x [12:4] little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
+ */
+#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 2x2 
subsampled Cr:Cb plane 12 bits per channel */
+
+/*
+ * 2 plane YCbCr MSB aligned
+ * index 0 = Y plane, [15:0] Y little endian
+ * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
+ */
+#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
subsampled Cr:Cb plane 16 bits per channel */
+
+/*
  * 3 plane YCbCr
  * index 0: Y plane, [7:0] Y
  * index 1: Cb plane, [7:0] Cb
-- 
1.7.9.5

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/13] drm/i915: Reinstate reservation_object zapping for batch_pool objects

[Patchwork]

== Series Details ==

Series: series starting with [01/13] drm/i915: Reinstate reservation_object 
zapping for batch_pool objects
URL   : https://patchwork.freedesktop.org/series/22099/
State : success

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-bxt-t5700) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 478s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 472s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 546s
fi-bxt-t5700 total:278  pass:257  dwarn:1   dfail:0   fail:0   skip:20  
time: 581s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 507s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 503s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 438s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 432s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 444s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 517s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 498s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 500s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 605s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 491s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 625s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 500s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 532s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 472s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 556s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 462s

2f9f22b419350cafb06ba7e5342bc461fcb0afca drm-tip: 2017y-03m-29d-12h-52m-56s UTC 
integration manifest
f4e5b50 drm/i915/scheduler: Support user-defined priorities
1425cd0 drm/i915: Async GPU relocation processing
9b90269 drm/i915: Allow execbuffer to use the first object as the batch
d535b17 drm/i915: Wait upon userptr get-user-pages within execbuffer
08984f0 drm/i915: First try the previous execbuffer location
d773440 drm/i915: Eliminate lots of iterations over the execobjects array
feea01c drm/i915: Pass vma to relocate entry
78561c6 drm/i915: Store a direct lookup from object handle to vma
e093300 drm/i915: Split vma exec_link/evict_link
614da61 drm/i915: Use vma->exec_entry as our double-entry placeholder
0c5dbdd drm/i915: Amalgamate execbuffer parameter structures
8d1339b drm/i915: Copy user requested buffers into the error state
94a1311 drm/i915: Reinstate reservation_object zapping for batch_pool objects

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Extend wait-ioctl to only wait on writes

[Chris Wilson]

On Wed, Mar 29, 2017 at 03:58:26PM +0100, Chris Wilson wrote:
> Currently, we allow read-read CPU/GPU concurrency via set-domain-ioctl,
> but we don't have a similar facility for a plain wait-ioctl. If we add a
> new flag that userspace can use to opt-in for only waiting for GPU
> writes, userspace can use it to co-ordinate its own read-read
> concurrency (without the side-effect of touching cache domains on the
> GEM object).
> 
> To test whether this flag is available, userspace needs to do a query
> operation like:
> 
> bool test_wait_has_read_only(int fd)
> {
>   struct drm_i915_gem_wait arg = { .flags = I915_WAIT_READ_ONLY };
>   int err = 0;
>   if (ioctl(fd, DRM_IOCTL_I915_GEM_WAIT, ))
>   err = -errno;
>   return err == -ENOENT;
> }

Even though it is used for read-read concurrency, and that future access
should be read-only, the wait itself is only for writes, which suggests
the flag should be I915_WAIT_WRITE_ONLY.
-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 13/13] drm/i915/scheduler: Support user-defined priorities

[Chris Wilson]

Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.

Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).

Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.

Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.

This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.

For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt

EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."

so we can map

PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023

They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).

Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 20 
 include/uapi/drm/i915_drm.h |  3 +++
 2 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8895444d3a4d..5aab9f97385c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1141,6 +1141,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_BANNABLE:
args->value = i915_gem_context_is_bannable(ctx);
break;
+   case I915_CONTEXT_PARAM_PRIORITY:
+   args->value = ctx->priority;
+   break;
default:
ret = -EINVAL;
break;
@@ -1198,6 +1201,23 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
else
i915_gem_context_clear_bannable(ctx);
break;
+
+   case I915_CONTEXT_PARAM_PRIORITY:
+   {
+   int priority = args->value;
+
+   if (args->size)
+   ret = -EINVAL;
+   else if (priority >= I915_PRIORITY_MAX ||
+priority <= I915_PRIORITY_MIN)
+   ret = -EINVAL;
+   else if (priority > 0 && !capable(CAP_SYS_ADMIN))
+   ret = -EPERM;
+   else
+   ctx->priority = priority;
+   }
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6837bb5f9d13..b96830feaab0 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -395,6 +395,8 @@ typedef struct drm_i915_irq_wait {
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
+ * The initial priority for each batch is supplied by the context and is
+ * controlled via I915_CONTEXT_PARAM_PRIORITY.
  */
 #define I915_PARAM_HAS_SCHEDULER41
 #define I915_PARAM_HUC_STATUS   42
@@ -1316,6 +1318,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_GTT_SIZE0x3
 #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE0x4
 #define I915_CONTEXT_PARAM_BANNABLE0x5
+#define I915_CONTEXT_PARAM_PRIORITY0x6
__u64 value;
 };
 
-- 
2.11.0

___
Intel-gfx mailing list

[Intel-gfx] [PATCH 08/13] drm/i915: Eliminate lots of iterations over the execobjects array

[Chris Wilson]

The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.

Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.

The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.

The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.

v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 drivers/gpu/drm/i915/i915_gem_evict.c   |   95 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c  | 1713 +--
 drivers/gpu/drm/i915/i915_vma.c |2 +-
 drivers/gpu/drm/i915/i915_vma.h |1 +
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c |4 +-
 drivers/gpu/drm/i915/selftests/i915_vma.c   |   16 +-
 7 files changed, 1043 insertions(+), 790 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e3db344243f1..5e434fad2d78 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3549,7 +3549,7 @@ int __must_check i915_gem_evict_something(struct 
i915_address_space *vm,
 int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
 struct drm_mm_node *node,
 unsigned int flags);
-int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
+int i915_gem_evict_vm(struct i915_address_space *vm);
 
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index fd5c75517143..c45d58e8a53d 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -50,6 +50,30 @@ static bool ggtt_is_idle(struct drm_i915_private *dev_priv)
return true;
 }
 
+static int ggtt_flush(struct drm_i915_private *i915)
+{
+   int err;
+
+   /* Not everything in the GGTT is tracked via vma (otherwise we
+* could evict as required with minimal stalling) so we are forced
+* to idle the GPU and explicitly retire outstanding requests in
+* the hopes that we can then remove contexts and the like only
+* bound by their active reference.
+*/
+   err = i915_gem_switch_to_kernel_context(i915);
+   if (err)
+   return err;
+
+   err = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (err)
+   return err;
+
+   i915_gem_retire_requests(i915);
+   return 0;
+}
+
 static bool
 mark_free(struct drm_mm_scan *scan,
  struct i915_vma *vma,
@@ -175,23 +199,10 @@ i915_gem_evict_something(struct i915_address_space *vm,
return intel_has_pending_fb_unpin(dev_priv) ? -EAGAIN : -ENOSPC;
}
 
-   /* Not everything in the GGTT is tracked via vma (otherwise we
-* could evict as required with minimal stalling) so we are forced
-* to idle the GPU and explicitly retire outstanding requests in
-* the hopes that we can then remove contexts and the like only
-* bound by their active reference.
-*/
-   ret = i915_gem_switch_to_kernel_context(dev_priv);
-   if (ret)
-   return ret;
-
-   ret = i915_gem_wait_for_idle(dev_priv,
-I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
+   ret = ggtt_flush(dev_priv);
if (ret)
return ret;
 
-   i915_gem_retire_requests(dev_priv);
goto search_again;
 
 found:
@@ -338,10 +349,8 @@ int i915_gem_evict_for_node(struct 

[Intel-gfx] [PATCH 12/13] drm/i915: Async GPU relocation processing

[Chris Wilson]

If the user requires patching of their batch or auxiliary buffers, we
currently make the alterations on the cpu. If they are active on the GPU
at the time, we wait under the struct_mutex for them to finish executing
before we rewrite the contents. This happens if shared relocation trees
are used between different contexts with separate address space (and the
buffers then have different addresses in each), the 3D state will need
to be adjusted between execution on each context. However, we don't need
to use the CPU to do the relocation patching, as we could queue commands
to the GPU to perform it and use fences to serialise the operation with
the current activity and future - so the operation on the GPU appears
just as atomic as performing it immediately. Performing the relocation
rewrites on the GPU is not free, in terms of pure throughput, the number
of relocations/s is about halved - but more importantly so is the time
under the struct_mutex.

v2: Break out the request/batch allocation for clearer error flow.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c|   1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 223 -
 2 files changed, 217 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f800114279d3..10f2d26cb2a9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4263,7 +4263,6 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
GEM_BUG_ON(i915_gem_object_is_active(obj));
list_for_each_entry_safe(vma, vn,
 >vma_list, obj_link) {
-   GEM_BUG_ON(!i915_vma_is_ggtt(vma));
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
i915_vma_close(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 4d703e331c90..017e27b7c300 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -40,7 +40,12 @@
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
 
-#define DBG_USE_CPU_RELOC 0 /* -1 force GTT relocs; 1 force CPU relocs */
+enum {
+   FORCE_CPU_RELOC = 1,
+   FORCE_GTT_RELOC,
+   FORCE_GPU_RELOC,
+#define DBG_FORCE_RELOC 0 /* choose one of the above! */
+};
 
 #define  __EXEC_OBJECT_HAS_PIN BIT(31)
 #define  __EXEC_OBJECT_HAS_FENCE   BIT(30)
@@ -187,10 +192,15 @@ struct i915_execbuffer {
struct drm_mm_node node;
unsigned long vaddr;
unsigned int page;
+   unsigned int gen;
bool use_64bit_reloc : 1;
bool has_llc : 1;
bool has_fence : 1;
bool needs_unfenced : 1;
+
+   struct drm_i915_gem_request *rq;
+   u32 *rq_cmd;
+   unsigned int rq_size;
} reloc_cache;
u64 invalid_flags;
u32 context_flags;
@@ -441,8 +451,11 @@ static inline int use_cpu_reloc(const struct reloc_cache 
*cache,
if (!i915_gem_object_has_struct_page(obj))
return false;
 
-   if (DBG_USE_CPU_RELOC)
-   return DBG_USE_CPU_RELOC > 0;
+   if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
+   return true;
+
+   if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
+   return false;
 
return (cache->has_llc ||
obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
@@ -833,11 +846,14 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->page = -1;
cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
+   cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
-   cache->has_fence = INTEL_GEN(i915) < 4;
-   cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->use_64bit_reloc = HAS_64BIT_RELOC(i915);
+   cache->has_fence = cache->gen < 4;
+   cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.allocated = false;
+   cache->rq = NULL;
+   cache->rq_size = 0;
 }
 
 static inline void *unmask_page(unsigned long p)
@@ -859,10 +875,24 @@ static inline struct i915_ggtt *cache_to_ggtt(struct 
reloc_cache *cache)
return >ggtt;
 }
 
+static void reloc_gpu_flush(struct reloc_cache *cache)
+{
+   GEM_BUG_ON(cache->rq_size >= cache->rq->batch->obj->base.size / 
sizeof(u32));
+   cache->rq_cmd[cache->rq_size] = MI_BATCH_BUFFER_END;
+   i915_gem_object_unpin_map(cache->rq->batch->obj);
+   i915_gem_chipset_flush(cache->rq->i915);
+
+   __i915_add_request(cache->rq, true);
+   cache->rq = NULL;
+}
+
 static void reloc_cache_reset(struct reloc_cache *cache)
 {
void *vaddr;
 
+   if (cache->rq)
+ 

[Intel-gfx] [PATCH 09/13] drm/i915: First try the previous execbuffer location

[Chris Wilson]

When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset from the user, or the currently bound offset that
should hopefully achieve the goal of avoiding the rebind cost and the
relocation penalty. However, if the object is not currently bound there
we don't want to arbitrarily unbind an object in our chosen position and
so choose to rebind/relocate the incoming object instead. After we
report the new position back to the user, on the next pass the
relocations should have settled down.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 
 drivers/gpu/drm/i915/i915_gem_gtt.c|  6 ++
 drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1409d80d5962..0f7236ce65bb 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -299,10 +299,15 @@ eb_pin_vma(struct i915_execbuffer *eb,
 {
u64 flags;
 
-   flags = vma->node.start;
-   flags |= PIN_USER | PIN_NONBLOCK | PIN_OFFSET_FIXED;
+   if (vma->node.size)
+   flags = vma->node.start;
+   else
+   flags = entry->offset & PIN_OFFSET_MASK;
+
+   flags |= PIN_USER | PIN_NOEVICT | PIN_OFFSET_FIXED;
if (unlikely(entry->flags & EXEC_OBJECT_NEEDS_GTT))
flags |= PIN_GLOBAL;
+
if (unlikely(i915_vma_pin(vma, 0, 0, flags)))
return;
 
@@ -414,8 +419,7 @@ eb_add_vma(struct i915_execbuffer *eb,
entry->flags |= eb->context_flags;
 
ret = 0;
-   if (vma->node.size)
-   eb_pin_vma(eb, entry, vma);
+   eb_pin_vma(eb, entry, vma);
if (eb_vma_misplaced(entry, vma)) {
eb_unreserve_vma(vma, entry);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index cee9c4fec52a..9160733cbb09 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3288,6 +3288,9 @@ int i915_gem_gtt_reserve(struct i915_address_space *vm,
if (err != -ENOSPC)
return err;
 
+   if (flags & PIN_NOEVICT)
+   return -ENOSPC;
+
err = i915_gem_evict_for_node(vm, node, flags);
if (err == 0)
err = drm_mm_reserve_node(>mm, node);
@@ -3402,6 +3405,9 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
if (err != -ENOSPC)
return err;
 
+   if (flags & PIN_NOEVICT)
+   return -ENOSPC;
+
/* No free space, pick a slot at random.
 *
 * There is a pathological case here using a GTT shared between
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684c1d83..a528ce1380fd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -588,6 +588,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 #define PIN_MAPPABLE   BIT(1)
 #define PIN_ZONE_4GBIT(2)
 #define PIN_NONFAULT   BIT(3)
+#define PIN_NOEVICTBIT(4)
 
 #define PIN_MBZBIT(5) /* I915_VMA_PIN_OVERFLOW */
 #define PIN_GLOBAL BIT(6) /* I915_VMA_GLOBAL_BIND */
-- 
2.11.0

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

[Intel-gfx] [PATCH 03/13] drm/i915: Amalgamate execbuffer parameter structures

[Chris Wilson]

Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 550 -
 1 file changed, 233 insertions(+), 317 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index af1965774e7b..626be396c327 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,70 +50,78 @@
 
 #define BATCH_OFFSET_BIAS (256*1024)
 
-struct i915_execbuffer_params {
-   struct drm_device   *dev;
-   struct drm_file *file;
-   struct i915_vma *batch;
-   u32 dispatch_flags;
-   u32 args_batch_start_offset;
-   struct intel_engine_cs  *engine;
-   struct i915_gem_context *ctx;
-   struct drm_i915_gem_request *request;
-};
+#define __I915_EXEC_ILLEGAL_FLAGS \
+   (__I915_EXEC_UNKNOWN_FLAGS | I915_EXEC_CONSTANTS_MASK)
 
-struct eb_vmas {
+struct i915_execbuffer {
struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer2 *args;
+   struct drm_i915_gem_exec_object2 *exec;
+   struct intel_engine_cs *engine;
+   struct i915_gem_context *ctx;
+   struct i915_address_space *vm;
+   struct i915_vma *batch;
+   struct drm_i915_gem_request *request;
+   u32 batch_start_offset;
+   u32 batch_len;
+   unsigned int dispatch_flags;
+   struct drm_i915_gem_exec_object2 shadow_exec_entry;
+   bool need_relocs;
struct list_head vmas;
+   struct reloc_cache {
+   struct drm_mm_node node;
+   unsigned long vaddr;
+   unsigned int page;
+   bool use_64bit_reloc : 1;
+   } reloc_cache;
int and;
union {
-   struct i915_vma *lut[0];
-   struct hlist_head buckets[0];
+   struct i915_vma **lut;
+   struct hlist_head *buckets;
};
 };
 
-static struct eb_vmas *
-eb_create(struct drm_i915_private *i915,
- struct drm_i915_gem_execbuffer2 *args)
+static int
+eb_create(struct i915_execbuffer *eb)
 {
-   struct eb_vmas *eb = NULL;
-
-   if (args->flags & I915_EXEC_HANDLE_LUT) {
-   unsigned size = args->buffer_count;
+   eb->lut = NULL;
+   if (eb->args->flags & I915_EXEC_HANDLE_LUT) {
+   unsigned int size = eb->args->buffer_count;
size *= sizeof(struct i915_vma *);
-   size += sizeof(struct eb_vmas);
-   eb = kmalloc(size, GFP_TEMPORARY | __GFP_NOWARN | 
__GFP_NORETRY);
+   eb->lut = kmalloc(size,
+ GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
}
 
-   if (eb == NULL) {
-   unsigned size = args->buffer_count;
-   unsigned count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
+   if (!eb->lut) {
+   unsigned int size = eb->args->buffer_count;
+   unsigned int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON_NOT_POWER_OF_2(PAGE_SIZE / sizeof(struct 
hlist_head));
while (count > 2*size)
count >>= 1;
-   eb = kzalloc(count*sizeof(struct hlist_head) +
-sizeof(struct eb_vmas),
-GFP_TEMPORARY);
-   if (eb == NULL)
-   return eb;
+   eb->lut = kzalloc(count*sizeof(struct hlist_head),
+ GFP_TEMPORARY);
+   if (!eb->lut)
+   return -ENOMEM;
 
eb->and = count - 1;
-   } else
-   eb->and = -args->buffer_count;
+   } else {
+   eb->and = -eb->args->buffer_count;
+   }
 
-   eb->i915 = i915;
INIT_LIST_HEAD(>vmas);
-   return eb;
+   return 0;
 }
 
 static void
-eb_reset(struct eb_vmas *eb)
+eb_reset(struct i915_execbuffer *eb)
 {
if (eb->and >= 0)
memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
 }
 
 static struct i915_vma *
-eb_get_batch(struct eb_vmas *eb)
+eb_get_batch(struct i915_execbuffer *eb)
 {
struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_list);
 
@@ -133,34 +141,30 @@ eb_get_batch(struct eb_vmas *eb)
 }
 
 static int
-eb_lookup_vmas(struct eb_vmas *eb,
-  struct drm_i915_gem_exec_object2 *exec,
-  const struct drm_i915_gem_execbuffer2 *args,
-  struct i915_address_space *vm,
-  struct drm_file *file)
+eb_lookup_vmas(struct i915_execbuffer *eb)
 {
struct drm_i915_gem_object *obj;
struct list_head 

[Intel-gfx] [PATCH 10/13] drm/i915: Wait upon userptr get-user-pages within execbuffer

[Chris Wilson]

This simply hides the EAGAIN caused by userptr when userspace causes
resource contention. However, it is quite beneficial with highly
contended userptr users as we avoid repeating the setup costs and
kernel-user context switches.

Signed-off-by: Chris Wilson 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h| 10 +-
 drivers/gpu/drm/i915/i915_gem.c|  4 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +++
 drivers/gpu/drm/i915/i915_gem_userptr.c| 18 +++---
 5 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d8a2f3bac5be..fa1dd0590e0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -554,6 +554,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
intel_uc_fini_hw(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_context_fini(dev_priv);
+   i915_gem_cleanup_userptr(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
 
i915_gem_drain_freed_objects(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5e434fad2d78..f263715f65c9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1515,6 +1515,13 @@ struct i915_gem_mm {
struct list_head fence_list;
 
/**
+* Workqueue to fault in userptr pages, flushed by the execbuf
+* when required but otherwise left to userspace to try again
+* on EAGAIN.
+*/
+   struct workqueue_struct *userptr_wq;
+
+   /**
 * Are we in a non-interruptible section of code like
 * modesetting?
 */
@@ -3200,7 +3207,8 @@ int i915_gem_set_tiling_ioctl(struct drm_device *dev, 
void *data,
  struct drm_file *file_priv);
 int i915_gem_get_tiling_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
-void i915_gem_init_userptr(struct drm_i915_private *dev_priv);
+int i915_gem_init_userptr(struct drm_i915_private *dev_priv);
+void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv);
 int i915_gem_userptr_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file);
 int i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b93d8f2ab037..f800114279d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4671,7 +4671,9 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
-   i915_gem_init_userptr(dev_priv);
+   ret = i915_gem_init_userptr(dev_priv);
+   if (ret)
+   goto out_unlock;
 
ret = i915_gem_init_ggtt(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0f7236ce65bb..1ef9fa9feddc 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1415,6 +1415,9 @@ static int eb_relocate_slow(struct i915_execbuffer *eb)
goto out;
}
 
+   /* A frequent cause for EAGAIN are currently unavailable client pages */
+   flush_workqueue(eb->i915->mm.userptr_wq);
+
ret = i915_mutex_lock_interruptible(dev);
if (ret) {
mutex_lock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 58ccf8b8ca1c..66b09163bfba 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -378,7 +378,7 @@ __i915_mm_struct_free(struct kref *kref)
mutex_unlock(>i915->mm_lock);
 
INIT_WORK(>work, __i915_mm_struct_free__worker);
-   schedule_work(>work);
+   queue_work(mm->i915->mm.userptr_wq, >work);
 }
 
 static void
@@ -598,7 +598,7 @@ __i915_gem_userptr_get_pages_schedule(struct 
drm_i915_gem_object *obj)
get_task_struct(work->task);
 
INIT_WORK(>work, __i915_gem_userptr_get_pages_worker);
-   schedule_work(>work);
+   queue_work(to_i915(obj->base.dev)->mm.userptr_wq, >work);
 
return ERR_PTR(-EAGAIN);
 }
@@ -828,8 +828,20 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file
return 0;
 }
 
-void i915_gem_init_userptr(struct drm_i915_private *dev_priv)
+int i915_gem_init_userptr(struct drm_i915_private *dev_priv)
 {
mutex_init(_priv->mm_lock);
hash_init(dev_priv->mm_structs);
+
+   dev_priv->mm.userptr_wq =
+   alloc_workqueue("i915-userptr-acquire", WQ_HIGHPRI, 0);
+   if (!dev_priv->mm.userptr_wq)
+   return -ENOMEM;
+
+   return 0;

[Intel-gfx] [PATCH 11/13] drm/i915: Allow execbuffer to use the first object as the batch

[Chris Wilson]

Currently, the last object in the execlist is the always the batch.
However, when building the batch buffer we often know the batch object
first and if we can use the first slot in the execlist we can emit
relocation instructions relative to it immediately and avoid a separate
pass to adjust the relocations to point to the last execlist slot.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  5 -
 include/uapi/drm/i915_drm.h| 16 +++-
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fa1dd0590e0a..e98f6c90efe0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_ASYNC:
case I915_PARAM_HAS_EXEC_FENCE:
case I915_PARAM_HAS_EXEC_CAPTURE:
+   case I915_PARAM_HAS_EXEC_BATCH_FIRST:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1ef9fa9feddc..4d703e331c90 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -573,7 +573,10 @@ ht_needs_resize(const struct i915_gem_context_vma_lut *lut)
 
 static unsigned int eb_batch_index(const struct i915_execbuffer *eb)
 {
-   return eb->buffer_count - 1;
+   if (eb->args->flags & I915_EXEC_BATCH_FIRST)
+   return 0;
+   else
+   return eb->buffer_count - 1;
 }
 
 static int eb_select_context(struct i915_execbuffer *eb)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 176c5a70300b..6837bb5f9d13 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -418,6 +418,11 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_HAS_EXEC_CAPTURE 45
 
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports supplying the batch buffer
+ * as the first execobject as opposed to the last. See I915_EXEC_BATCH_FIRST.
+ */
+#define I915_PARAM_HAS_EXEC_BATCH_FIRST 46
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
@@ -902,7 +907,16 @@ struct drm_i915_gem_execbuffer2 {
  */
 #define I915_EXEC_FENCE_OUT(1<<17)
 
-#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_OUT<<1))
+/* Traditionally the execbuf ioctl has only considered the final element in
+ * the execobject[] to be the executable batch. Often though, the client
+ * will known the batch object prior to construction and being able to place
+ * it into the execobject[] array first can simplify the relocation tracking.
+ * Setting I915_EXEC_BATCH_FIRST tells execbuf to use element 0 of the
+ * execobject[] as the * batch instead (the default is to use the last
+ * element).
+ */
+#define I915_EXEC_BATCH_FIRST  (1<<18)
+#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_BATCH_FIRST<<1))
 
 #define I915_EXEC_CONTEXT_ID_MASK  (0x)
 #define i915_execbuffer2_set_context_id(eb2, context) \
-- 
2.11.0

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

[Intel-gfx] [PATCH 06/13] drm/i915: Store a direct lookup from object handle to vma

[Chris Wilson]

The advent of full-ppgtt lead to an extra indirection between the object
and its binding. That extra indirection has a noticeable impact on how
fast we can convert from the user handles to our internal vma for
execbuffer. In order to bypass the extra indirection, we use a
resizable hashtable to jump from the object to the per-ctx vma.
rhashtable was considered but we don't need the online resizing feature
and the extra complexity proved to undermine its usefulness. Instead, we
simply reallocate the hastable on demand in a background task and
serialize it before iterating.

In non-full-ppgtt modes, multiple files and multiple contexts can share
the same vma. This leads to having multiple possible handle->vma links,
so we only use the first to establish the fast path. The majority of
buffers are not shared and so we should still be able to realise
speedups with multiple clients.

v2: Prettier names, more magic.
v3: Many style tweaks, notable hiding the misuse of execobj[].rsvd2

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   6 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 drivers/gpu/drm/i915/i915_gem.c   |   5 +-
 drivers/gpu/drm/i915/i915_gem_context.c   |  86 -
 drivers/gpu/drm/i915/i915_gem_context.h   |  25 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c| 261 --
 drivers/gpu/drm/i915/i915_gem_object.h|   4 +-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 drivers/gpu/drm/i915/i915_vma.c   |  20 ++
 drivers/gpu/drm/i915/i915_vma.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_context.c |  12 +-
 11 files changed, 320 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d4904245472f..8a7f57318a87 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1988,6 +1988,12 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
seq_putc(m, '\n');
}
 
+   seq_printf(m,
+  "\tvma hashtable size=%u (actual %lu), count=%u\n",
+  ctx->vma_lut.ht_size,
+  BIT(ctx->vma_lut.ht_bits),
+  ctx->vma_lut.ht_count);
+
seq_putc(m, '\n');
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 42dce927b089..e3db344243f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,7 +37,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 84ea249c6f4f..b93d8f2ab037 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3170,6 +3170,10 @@ void i915_gem_close_object(struct drm_gem_object *gem, 
struct drm_file *file)
if (vma->vm->file == fpriv)
i915_vma_close(vma);
 
+   vma = obj->vma_hashed;
+   if (vma && vma->ctx->file_priv == fpriv)
+   i915_vma_unlink_ctx(vma);
+
if (i915_gem_object_is_active(obj) &&
!i915_gem_object_has_active_reference(obj)) {
i915_gem_object_set_active_reference(obj);
@@ -4124,7 +4128,6 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
 
INIT_LIST_HEAD(>global_link);
INIT_LIST_HEAD(>userfault_link);
-   INIT_LIST_HEAD(>obj_exec_link);
INIT_LIST_HEAD(>vma_list);
INIT_LIST_HEAD(>batch_pool_link);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8bd0c4966913..8895444d3a4d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -85,6 +85,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -92,6 +93,9 @@
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
 
+/* Initial size (as log2) to preallocate the handle->object hashtable */
+#define VMA_HT_BITS 2u /* 4 x 2 pointers, 64 bytes minimum */
+
 static int get_context_size(struct drm_i915_private *dev_priv)
 {
int ret;
@@ -119,6 +123,67 @@ static int get_context_size(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+static void resize_vma_ht(struct work_struct *work)
+{
+   struct i915_gem_context_vma_lut *lut =
+   container_of(work, typeof(*lut), resize);
+   unsigned int bits, new_bits, size, i;
+   struct hlist_head *new_ht;
+
+   GEM_BUG_ON(!(lut->ht_size & I915_CTX_RESIZE_IN_PROGRESS));
+
+   bits = 1 + ilog2(4*lut->ht_count/3 + 1);
+   new_bits = min_t(unsigned int,
+max(bits, VMA_HT_BITS),
+sizeof(unsigned int) * BITS_PER_BYTE - 1);
+   if (new_bits == lut->ht_bits)
+   goto out;
+
+  

[Intel-gfx] [PATCH 07/13] drm/i915: Pass vma to relocate entry

[Chris Wilson]

We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.

Note we have only been using a single bit to track flushing since

commit cc889e0f6ce6a63c62db17d702ecfed86d58083f
Author: Daniel Vetter 
Date:   Wed Jun 13 20:45:19 2012 +0200

drm/i915: disable flushing_list/gpu_write_list

unconditionally flushed all render caches before the breadcrumb and

commit 6ac42f4148bc27e5ffd18a9ab0eac57f58822af4
Author: Daniel Vetter 
Date:   Sat Jul 21 12:25:01 2012 +0200

drm/i915: Replace the complex flushing logic with simple invalidate/flush 
all

did away with the explicit GPU domain tracking. This was then codified
into the ABI with NO_RELOC in

commit ed5982e6ce5f106abcbf071f80730db344a6da42
Author: Daniel Vetter  # Oi! Patch stealer!
Date:   Thu Jan 17 22:23:36 2013 +0100

drm/i915: Allow userspace to hint that the relocations were known

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 101 -
 1 file changed, 41 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a3a7e0258d3f..6578429ad07c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -620,42 +620,25 @@ relocate_entry(struct drm_i915_gem_object *obj,
 }
 
 static int
-eb_relocate_entry(struct drm_i915_gem_object *obj,
+eb_relocate_entry(struct i915_vma *vma,
  struct i915_execbuffer *eb,
  struct drm_i915_gem_relocation_entry *reloc)
 {
-   struct drm_gem_object *target_obj;
-   struct drm_i915_gem_object *target_i915_obj;
-   struct i915_vma *target_vma;
-   uint64_t target_offset;
+   struct i915_vma *target;
+   u64 target_offset;
int ret;
 
/* we've already hold a reference to all valid objects */
-   target_vma = eb_get_vma(eb, reloc->target_handle);
-   if (unlikely(target_vma == NULL))
+   target = eb_get_vma(eb, reloc->target_handle);
+   if (unlikely(!target))
return -ENOENT;
-   target_i915_obj = target_vma->obj;
-   target_obj = _vma->obj->base;
-
-   target_offset = gen8_canonical_addr(target_vma->node.start);
-
-   /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
-* pipe_control writes because the gpu doesn't properly redirect them
-* through the ppgtt for non_secure batchbuffers. */
-   if (unlikely(IS_GEN6(eb->i915) &&
-reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION)) {
-   ret = i915_vma_bind(target_vma, target_i915_obj->cache_level,
-   PIN_GLOBAL);
-   if (WARN_ONCE(ret, "Unexpected failure to bind target VMA!"))
-   return ret;
-   }
 
/* Validate that the target is in a valid r/w GPU domain */
if (unlikely(reloc->write_domain & (reloc->write_domain - 1))) {
DRM_DEBUG("reloc with multiple write domains: "
- "obj %p target %d offset %d "
+ "target %d offset %d "
  "read %08x write %08x",
- obj, reloc->target_handle,
+ reloc->target_handle,
  (int) reloc->offset,
  reloc->read_domains,
  reloc->write_domain);
@@ -664,43 +647,56 @@ eb_relocate_entry(struct drm_i915_gem_object *obj,
if (unlikely((reloc->write_domain | reloc->read_domains)
 & ~I915_GEM_GPU_DOMAINS)) {
DRM_DEBUG("reloc with read/write non-GPU domains: "
- "obj %p target %d offset %d "
+ "target %d offset %d "
  "read %08x write %08x",
- obj, reloc->target_handle,
+ reloc->target_handle,
  (int) reloc->offset,
  reloc->read_domains,
  reloc->write_domain);
return -EINVAL;
}
 
-   target_obj->pending_read_domains |= reloc->read_domains;
-   target_obj->pending_write_domain |= reloc->write_domain;
+   if (reloc->write_domain)
+   target->exec_entry->flags |= EXEC_OBJECT_WRITE;
+
+   /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
+* pipe_control writes because the gpu doesn't properly redirect them
+* through the ppgtt for non_secure batchbuffers.
+*/
+   if (unlikely(IS_GEN6(eb->i915) &&
+reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION)) {
+ 

[Intel-gfx] Another week, another eb bomb

[Chris Wilson]

Just to remind everyone that this series is unstoppable and we want the
green, not to mention the small boosts we get from dramatically reducing
overhead of execbuf for many typical submission paths.
-Chris

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

[Intel-gfx] [PATCH 04/13] drm/i915: Use vma->exec_entry as our double-entry placeholder

[Chris Wilson]

This has the benefit of not requiring us to manipulate the
vma->exec_link list when tearing down the execbuffer, and is a
marginally cheaper test to detect the user error.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_evict.c  | 17 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 77 --
 drivers/gpu/drm/i915/i915_vma.c|  1 -
 3 files changed, 44 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 2da3a94fc9f3..ed34f54baef9 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -59,9 +59,6 @@ mark_free(struct drm_mm_scan *scan,
if (i915_vma_is_pinned(vma))
return false;
 
-   if (WARN_ON(!list_empty(>exec_list)))
-   return false;
-
if (flags & PIN_NONFAULT && !list_empty(>obj->userfault_link))
return false;
 
@@ -160,8 +157,6 @@ i915_gem_evict_something(struct i915_address_space *vm,
list_for_each_entry_safe(vma, next, _list, exec_list) {
ret = drm_mm_scan_remove_block(, >node);
BUG_ON(ret);
-
-   INIT_LIST_HEAD(>exec_list);
}
 
/* Can we unpin some objects such as idle hw contents,
@@ -210,17 +205,12 @@ i915_gem_evict_something(struct i915_address_space *vm,
if (drm_mm_scan_remove_block(, >node))
__i915_vma_pin(vma);
else
-   list_del_init(>exec_list);
+   list_del(>exec_list);
}
 
/* Unbinding will emit any required flushes */
ret = 0;
-   while (!list_empty(_list)) {
-   vma = list_first_entry(_list,
-  struct i915_vma,
-  exec_list);
-
-   list_del_init(>exec_list);
+   list_for_each_entry_safe(vma, next, _list, exec_list) {
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
@@ -316,7 +306,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
}
 
/* Overlap of objects in the same batch? */
-   if (i915_vma_is_pinned(vma) || !list_empty(>exec_list)) {
+   if (i915_vma_is_pinned(vma)) {
ret = -ENOSPC;
if (vma->exec_entry &&
vma->exec_entry->flags & EXEC_OBJECT_PINNED)
@@ -337,7 +327,6 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
}
 
list_for_each_entry_safe(vma, next, _list, exec_list) {
-   list_del_init(>exec_list);
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 626be396c327..d365379c166b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -109,13 +109,40 @@ eb_create(struct i915_execbuffer *eb)
eb->and = -eb->args->buffer_count;
}
 
-   INIT_LIST_HEAD(>vmas);
return 0;
 }
 
+static inline void
+__eb_unreserve_vma(struct i915_vma *vma,
+  const struct drm_i915_gem_exec_object2 *entry)
+{
+   if (unlikely(entry->flags & __EXEC_OBJECT_HAS_FENCE))
+   i915_vma_unpin_fence(vma);
+
+   if (entry->flags & __EXEC_OBJECT_HAS_PIN)
+   __i915_vma_unpin(vma);
+}
+
+static void
+eb_unreserve_vma(struct i915_vma *vma)
+{
+   struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
+
+   __eb_unreserve_vma(vma, entry);
+   entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE | __EXEC_OBJECT_HAS_PIN);
+}
+
 static void
 eb_reset(struct i915_execbuffer *eb)
 {
+   struct i915_vma *vma;
+
+   list_for_each_entry(vma, >vmas, exec_list) {
+   eb_unreserve_vma(vma);
+   i915_vma_put(vma);
+   vma->exec_entry = NULL;
+   }
+
if (eb->and >= 0)
memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
 }
@@ -147,6 +174,8 @@ eb_lookup_vmas(struct i915_execbuffer *eb)
struct list_head objects;
int i, ret;
 
+   INIT_LIST_HEAD(>vmas);
+
INIT_LIST_HEAD();
spin_lock(>file->table_lock);
/* Grab a reference to the object and release the lock so we can lookup
@@ -253,40 +282,23 @@ static struct i915_vma *eb_get_vma(struct i915_execbuffer 
*eb, unsigned long han
}
 }
 
-static void
-eb_unreserve_vma(struct i915_vma *vma)
-{
-   struct drm_i915_gem_exec_object2 *entry;
-
-   if (!drm_mm_node_allocated(>node))
-   return;
-
-   entry = vma->exec_entry;
-
-   if (entry->flags & __EXEC_OBJECT_HAS_FENCE)
-   i915_vma_unpin_fence(vma);
-
- 

[Intel-gfx] [PATCH 02/13] drm/i915: Copy user requested buffers into the error state

[Chris Wilson]

Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.

Use this at your discretion, the contents of the error state. although
compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
eternity (until the error state is destroyed).

Based on an earlier patch by Ben Widawsky 
Signed-off-by: Chris Wilson 
Cc: Ben Widawsky 
Cc: Matt Turner 
Acked-by: Ben Widawsky 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h|  3 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +
 drivers/gpu/drm/i915/i915_gem_request.c| 16 
 drivers/gpu/drm/i915/i915_gem_request.h| 11 
 drivers/gpu/drm/i915/i915_gpu_error.c  | 40 +-
 include/uapi/drm/i915_drm.h| 15 ++-
 7 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d0524fbd70c4..d8a2f3bac5be 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -350,6 +350,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_SOFTPIN:
case I915_PARAM_HAS_EXEC_ASYNC:
case I915_PARAM_HAS_EXEC_FENCE:
+   case I915_PARAM_HAS_EXEC_CAPTURE:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0cbadac02a53..42dce927b089 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1025,6 +1025,9 @@ struct i915_gpu_state {
u32 *pages[0];
} *ringbuffer, *batchbuffer, *wa_batchbuffer, *ctx, *hws_page;
 
+   struct drm_i915_error_object **user_bo;
+   long user_bo_count;
+
struct drm_i915_error_object *wa_ctx;
 
struct drm_i915_error_request {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a3e59c8ef27b..af1965774e7b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1114,6 +1114,18 @@ i915_gem_execbuffer_move_to_gpu(struct 
drm_i915_gem_request *req,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma->obj;
 
+   if (vma->exec_entry->flags & EXEC_OBJECT_CAPTURE) {
+   struct i915_gem_capture_list *capture;
+
+   capture = kmalloc(sizeof(*capture), GFP_KERNEL);
+   if (unlikely(!capture))
+   return -ENOMEM;
+
+   capture->next = req->capture_list;
+   capture->vma = vma;
+   req->capture_list = capture;
+   }
+
if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
continue;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index dbfa9db2419d..50db1568a044 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -270,6 +270,19 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
/* Space left intentionally blank */
 }
 
+static void request_free_capture_list(struct drm_i915_gem_request *request)
+{
+   struct i915_gem_capture_list *capture;
+
+   capture = request->capture_list;
+   while (capture) {
+   struct i915_gem_capture_list *next = capture->next;
+
+   kfree(capture);
+   capture = next;
+   }
+}
+
 static void i915_gem_request_retire(struct drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
@@ -304,6 +317,8 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
}
unreserve_seqno(request->engine);
 
+   request_free_capture_list(request);
+
/* Walk through the active list, calling retire on each. This allows
 * objects to track their GPU activity and mark themselves as idle
 * when their *last* active request is completed (updating state
@@ -602,6 +617,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
req->global_seqno = 0;
req->file_priv = NULL;
req->batch = NULL;
+   req->capture_list = NULL;
 
/*
 * Reserve space in the ring buffer for all the commands required to
diff --git 

[Intel-gfx] [PATCH 01/13] drm/i915: Reinstate reservation_object zapping for batch_pool objects

[Chris Wilson]

I removed the zapping of the reservation_object->fence array of shared
fences prematurely. We don't yet have the code to zap that array when
retiring the object, and so currently it remains possible to continually
grow the shared array trapping requests when reusing the batch_pool
object across many timelines.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 41aa598c4f3b..414e46e2f072 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -114,12 +114,26 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
list_for_each_entry(obj, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
if (i915_gem_object_is_active(obj)) {
-   if (!reservation_object_test_signaled_rcu(obj->resv,
- true))
+   struct reservation_object *resv = obj->resv;
+
+   if (!reservation_object_test_signaled_rcu(resv, true))
break;
 
i915_gem_retire_requests(pool->engine->i915);
GEM_BUG_ON(i915_gem_object_is_active(obj));
+
+   /* The object is now idle, clear the array of shared
+* fences before we add a new request. Although, we
+* remain on the same engine, we may be on a different
+* timeline and so may continually grow the array,
+* trapping a reference to all the old fences, rather
+* than replace the existing fence.
+*/
+   if (rcu_access_pointer(resv->fence)) {
+   reservation_object_lock(resv, NULL);
+   reservation_object_add_excl_fence(resv, NULL);
+   reservation_object_unlock(resv);
+   }
}
 
GEM_BUG_ON(!reservation_object_test_signaled_rcu(obj->resv,
-- 
2.11.0

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

[Intel-gfx] [PATCH 05/13] drm/i915: Split vma exec_link/evict_link

[Chris Wilson]

Currently the vma has one link member that is used for both holding its
place in the execbuf reservation list, and in any eviction list. This
dual property is quite tricky and error prone.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_evict.c  | 14 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 32 +++---
 drivers/gpu/drm/i915/i915_vma.h|  7 +--
 3 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index ed34f54baef9..fd5c75517143 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -62,7 +62,7 @@ mark_free(struct drm_mm_scan *scan,
if (flags & PIN_NONFAULT && !list_empty(>obj->userfault_link))
return false;
 
-   list_add(>exec_list, unwind);
+   list_add(>evict_link, unwind);
return drm_mm_scan_add_block(scan, >node);
 }
 
@@ -154,7 +154,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
} while (*++phase);
 
/* Nothing found, clean up and bail out! */
-   list_for_each_entry_safe(vma, next, _list, exec_list) {
+   list_for_each_entry_safe(vma, next, _list, evict_link) {
ret = drm_mm_scan_remove_block(, >node);
BUG_ON(ret);
}
@@ -201,16 +201,16 @@ i915_gem_evict_something(struct i915_address_space *vm,
 * calling unbind (which may remove the active reference
 * of any of our objects, thus corrupting the list).
 */
-   list_for_each_entry_safe(vma, next, _list, exec_list) {
+   list_for_each_entry_safe(vma, next, _list, evict_link) {
if (drm_mm_scan_remove_block(, >node))
__i915_vma_pin(vma);
else
-   list_del(>exec_list);
+   list_del(>evict_link);
}
 
/* Unbinding will emit any required flushes */
ret = 0;
-   list_for_each_entry_safe(vma, next, _list, exec_list) {
+   list_for_each_entry_safe(vma, next, _list, evict_link) {
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
@@ -323,10 +323,10 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
 * reference) another in our eviction list.
 */
__i915_vma_pin(vma);
-   list_add(>exec_list, _list);
+   list_add(>evict_link, _list);
}
 
-   list_for_each_entry_safe(vma, next, _list, exec_list) {
+   list_for_each_entry_safe(vma, next, _list, evict_link) {
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d365379c166b..7f9431b56276 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -137,7 +137,7 @@ eb_reset(struct i915_execbuffer *eb)
 {
struct i915_vma *vma;
 
-   list_for_each_entry(vma, >vmas, exec_list) {
+   list_for_each_entry(vma, >vmas, exec_link) {
eb_unreserve_vma(vma);
i915_vma_put(vma);
vma->exec_entry = NULL;
@@ -150,7 +150,7 @@ eb_reset(struct i915_execbuffer *eb)
 static struct i915_vma *
 eb_get_batch(struct i915_execbuffer *eb)
 {
-   struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_list);
+   struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_link);
 
/*
 * SNA is doing fancy tricks with compressing batch buffers, which leads
@@ -227,7 +227,7 @@ eb_lookup_vmas(struct i915_execbuffer *eb)
}
 
/* Transfer ownership from the objects list to the vmas list. */
-   list_add_tail(>exec_list, >vmas);
+   list_add_tail(>exec_link, >vmas);
list_del_init(>obj_exec_link);
 
vma->exec_entry = >exec[i];
@@ -286,7 +286,7 @@ static void eb_destroy(struct i915_execbuffer *eb)
 {
struct i915_vma *vma;
 
-   list_for_each_entry(vma, >vmas, exec_list) {
+   list_for_each_entry(vma, >vmas, exec_link) {
if (!vma->exec_entry)
continue;
 
@@ -752,7 +752,7 @@ static int eb_relocate(struct i915_execbuffer *eb)
struct i915_vma *vma;
int ret = 0;
 
-   list_for_each_entry(vma, >vmas, exec_list) {
+   list_for_each_entry(vma, >vmas, exec_link) {
ret = eb_relocate_vma(vma, eb);
if (ret)
break;
@@ -905,7 +905,7 @@ static int eb_reserve(struct i915_execbuffer *eb)
struct drm_i915_gem_exec_object2 *entry;
bool need_fence, need_mappable;
 
-  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Extend wait-ioctl to only wait on writes

[Patchwork]

== Series Details ==

Series: drm/i915: Extend wait-ioctl to only wait on writes
URL   : https://patchwork.freedesktop.org/series/22093/
State : success

== Summary ==

Series 22093v1 drm/i915: Extend wait-ioctl to only wait on writes
https://patchwork.freedesktop.org/api/1.0/series/22093/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 465s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 456s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 584s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 545s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 596s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 508s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 434s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 431s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 441s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 521s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 501s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 485s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 592s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 479s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 595s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 487s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 527s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 461s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 547s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 421s
fi-byt-j1900 failed to collect. IGT log at Patchwork_4344/fi-byt-j1900/igt.log

2f9f22b419350cafb06ba7e5342bc461fcb0afca drm-tip: 2017y-03m-29d-12h-52m-56s UTC 
integration manifest
f1ddd2c drm/i915: Extend wait-ioctl to only wait on writes

== Logs ==

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

[Intel-gfx] [drm-intel:drm-intel-nightly 1077/1091] drivers/gpu/drm/drm_irq.c:341:6: error: call to '__cmpxchg_called_with_bad_pointer' declared with attribute error: Bad argument size for cmpxchg

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head:   2f9f22b419350cafb06ba7e5342bc461fcb0afca
commit: 43dc7fe2b2118c76fbc2808dec0c57b3158e6dc0 [1077/1091] drm: Mark up 
accesses of vblank->enabled outside of its spinlock
config: tile-tilegx_defconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 43dc7fe2b2118c76fbc2808dec0c57b3158e6dc0
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/drm_irq.c: In function 'vblank_disable_and_save':
   drivers/gpu/drm/drm_irq.c:341:5: warning: '__x' may be used uninitialized in 
this function [-Wuninitialized]
>> drivers/gpu/drm/drm_irq.c:341:6: error: call to 
>> '__cmpxchg_called_with_bad_pointer' declared with attribute error: Bad 
>> argument size for cmpxchg

vim +/__cmpxchg_called_with_bad_pointer +341 drivers/gpu/drm/drm_irq.c

   335  
   336  /*
   337   * Only disable vblank interrupts if they're enabled. This 
avoids
   338   * calling the ->disable_vblank() operation in atomic context 
with the
   339   * hardware potentially runtime suspended.
   340   */
 > 341  if (cmpxchg_relaxed(>enabled, true, false))
   342  __disable_vblank(dev, pipe);
   343  
   344  /*

---
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/fb-helper: Deferred setup support (rev3)

[Patchwork]

== Series Details ==

Series: drm/fb-helper: Deferred setup support (rev3)
URL   : https://patchwork.freedesktop.org/series/8410/
State : warning

== Summary ==

Series 8410v3 drm/fb-helper: Deferred setup support
https://patchwork.freedesktop.org/api/1.0/series/8410/revisions/3/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bxt-t5700)
Test core_prop_blob:
Subgroup basic:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bxt-t5700)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bxt-t5700)
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bxt-t5700)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bxt-t5700)
Test gem_basic:
Subgroup bad-close:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-kbl-7500u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-bdw-5557u)
pass   -> DMESG-WARN (fi-bxt-t5700)
Subgroup create-close:
pass 

[Intel-gfx] [PATCH] drm/i915: Extend wait-ioctl to only wait on writes

[Chris Wilson]

Currently, we allow read-read CPU/GPU concurrency via set-domain-ioctl,
but we don't have a similar facility for a plain wait-ioctl. If we add a
new flag that userspace can use to opt-in for only waiting for GPU
writes, userspace can use it to co-ordinate its own read-read
concurrency (without the side-effect of touching cache domains on the
GEM object).

To test whether this flag is available, userspace needs to do a query
operation like:

bool test_wait_has_read_only(int fd)
{
struct drm_i915_gem_wait arg = { .flags = I915_WAIT_READ_ONLY };
int err = 0;
if (ioctl(fd, DRM_IOCTL_I915_GEM_WAIT, ))
err = -errno;
return err == -ENOENT;
}

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 5 +++--
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c2a660c7538b..d50710752265 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3006,7 +3006,7 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
ktime_t start;
long ret;
 
-   if (args->flags != 0)
+   if (args->flags & ~(I915_WAIT_READ_ONLY))
return -EINVAL;
 
obj = i915_gem_object_lookup(file, args->bo_handle);
@@ -3016,7 +3016,8 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file)
start = ktime_get();
 
ret = i915_gem_object_wait(obj,
-  I915_WAIT_INTERRUPTIBLE | I915_WAIT_ALL,
+  I915_WAIT_INTERRUPTIBLE |
+  (args->flags & I915_WAIT_READ_ONLY ? 0 : 
I915_WAIT_ALL),
   to_wait_timeout(args->timeout_ns),
   to_rps_client(file));
 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 72460826f818..6387a7485702 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1312,6 +1312,7 @@ struct drm_i915_gem_wait {
/** Handle of BO we shall wait on */
__u32 bo_handle;
__u32 flags;
+#define I915_WAIT_READ_ONLY0x1
/** Number of nanoseconds to wait, Returns time remaining. */
__s64 timeout_ns;
 };
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v4 06/11] drm/fb-helper: Make top-level lock more robust

[Thierry Reding]

On Wed, Mar 29, 2017 at 04:43:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The existing drm_fb_helper_hotplug_event() function needs to take the
> top-level fb-helper lock. However, the function can also be called from
> code that has already taken this lock. Introduce an unlocked variant of
> this function that can be used in the latter case.
> 
> This function calls drm_fb_helper_restore_fbdev_mode_unlocked(), via
> drm_fb_helper_set_par(), so we also need to introduce an unlocked copy
> of that to avoid recursive locking issues.
> 
> Similarly, the drm_fb_helper_initial_config() function ends up calling
> drm_fb_helper_set_par(), via register_framebuffer(), and needs an
> unlocked variant to avoid recursive locking.
> 
> Signed-off-by: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 167 
> +---
>  1 file changed, 104 insertions(+), 63 deletions(-)

Note that this could probably be squashed into 05/11, but I left it
separate for easier review since it's the only new patch in the series.

Also I had originally split this into three separate patches, but the
recursive call stack for the drm_fb_helper_hotplug_event() function and
drm_fb_helper_restore_fbdev_mode_unlocked() made it impossible to keep
bisectibility across the series.

Thierry


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

[Intel-gfx] [PATCH v4 07/11] drm/fb-helper: Support deferred setup

[Thierry Reding]

From: Thierry Reding 

FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.

The fallback is in place because VGA connectors can happen to report an
unknown connection status even when they are in fact connected.

Some drivers have custom solutions in place to defer FB helper setup
until at least one output is connected. But the logic behind these
solutions is always the same and there is nothing driver-specific about
it, so a better alterative is to fix the FB helper core and add support
for all drivers automatically.

This patch adds support for deferred FB helper setup. It checks all the
connectors for their connection status, and if all of them report to be
disconnected marks the FB helper as needing deferred setup. Whet setup
is deferred, the FB helper core will automatically retry setup after a
hotplug event, and it will keep trying until it succeeds.

Tested-by: John Stultz 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 53 +
 include/drm/drm_fb_helper.h | 23 ++
 2 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 21a90322531c..e9fe47d218e1 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -505,6 +505,9 @@ __drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
 
WARN_ON(!mutex_is_locked(_helper->lock));
 
+   if (fb_helper->deferred_setup)
+   return 0;
+
drm_modeset_lock_all(dev);
 
ret = restore_fbdev_mode(fb_helper);
@@ -1611,6 +1614,23 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo 
*var,
 }
 EXPORT_SYMBOL(drm_fb_helper_pan_display);
 
+static bool drm_fb_helper_maybe_connected(struct drm_fb_helper *helper)
+{
+   bool connected = false;
+   unsigned int i;
+
+   for (i = 0; i < helper->connector_count; i++) {
+   struct drm_fb_helper_connector *fb = helper->connector_info[i];
+
+   if (fb->connector->status != connector_status_disconnected) {
+   connected = true;
+   break;
+   }
+   }
+
+   return connected;
+}
+
 /*
  * Allocates the backing storage and sets up the fbdev info structure through
  * the ->fb_probe callback and then registers the fbdev and sets up the panic
@@ -2268,8 +2288,6 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
int i;
 
DRM_DEBUG_KMS("\n");
-   if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
-   DRM_DEBUG_KMS("No connectors reported connected with modes\n");
 
/* prevent concurrent modification of connector_count by hotplug */
lockdep_assert_held(_helper->dev->mode_config.mutex);
@@ -2351,6 +2369,7 @@ static int __drm_fb_helper_initial_config(struct 
drm_fb_helper *fb_helper,
  int bpp_sel)
 {
struct drm_device *dev = fb_helper->dev;
+   unsigned int width, height;
struct fb_info *info;
int ret;
 
@@ -2360,14 +2379,34 @@ static int __drm_fb_helper_initial_config(struct 
drm_fb_helper *fb_helper,
WARN_ON(!mutex_is_locked(_helper->lock));
 
mutex_lock(>mode_config.mutex);
-   drm_setup_crtcs(fb_helper,
-   dev->mode_config.max_width,
-   dev->mode_config.max_height);
+
+   width = dev->mode_config.max_width;
+   height = dev->mode_config.max_height;
+
+   if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
+   DRM_DEBUG_KMS("No connectors reported connected with modes\n");
+
+   /*
+* If everything's disconnected, there's no use in attempting to set
+* up fbdev.
+*/
+   if (!drm_fb_helper_maybe_connected(fb_helper)) {
+   DRM_INFO("No outputs connected, deferring setup\n");
+   fb_helper->preferred_bpp = bpp_sel;
+   fb_helper->deferred_setup = true;
+   mutex_unlock(>mode_config.mutex);
+   return 0;
+   }
+
+   drm_setup_crtcs(fb_helper, width, height);
+
ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
mutex_unlock(>mode_config.mutex);
if (ret)
return ret;
 
+   fb_helper->deferred_setup = false;
+
info = fb_helper->fbdev;
info->var.pixclock = 0;
ret = register_framebuffer(info);
@@ -2451,6 +2490,10 @@ static int __drm_fb_helper_hotplug_event(struct 
drm_fb_helper *fb_helper)
 
WARN_ON(!mutex_is_locked(_helper->lock));
 
+   if 

[Intel-gfx] [PATCH v4 08/11] drm/exynos: Remove custom FB helper deferred setup

[Thierry Reding]

From: Thierry Reding 

The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  6 --
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 ---
 2 files changed, 4 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09d3c4c3c858..08f9533ddbe8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -399,8 +399,9 @@ static int exynos_drm_bind(struct device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(drm);
 
-   /* force connectors detection */
-   drm_helper_hpd_irq_event(drm);
+   ret = exynos_drm_fbdev_init(drm);
+   if (ret)
+   goto err_cleanup_poll;
 
/* register the DRM device */
ret = drm_dev_register(drm, 0);
@@ -411,6 +412,7 @@ static int exynos_drm_bind(struct device *dev)
 
 err_cleanup_fbdev:
exynos_drm_fbdev_fini(drm);
+err_cleanup_poll:
drm_kms_helper_poll_fini(drm);
exynos_drm_device_subdrv_remove(drm);
 err_cleanup_vblank:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 641531243e04..e64a1041dd29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -183,24 +183,6 @@ static const struct drm_fb_helper_funcs 
exynos_drm_fb_helper_funcs = {
.fb_probe = exynos_drm_fbdev_create,
 };
 
-static bool exynos_drm_fbdev_is_anything_connected(struct drm_device *dev)
-{
-   struct drm_connector *connector;
-   bool ret = false;
-
-   mutex_lock(>mode_config.mutex);
-   list_for_each_entry(connector, >mode_config.connector_list, head) {
-   if (connector->status != connector_status_connected)
-   continue;
-
-   ret = true;
-   break;
-   }
-   mutex_unlock(>mode_config.mutex);
-
-   return ret;
-}
-
 int exynos_drm_fbdev_init(struct drm_device *dev)
 {
struct exynos_drm_fbdev *fbdev;
@@ -211,9 +193,6 @@ int exynos_drm_fbdev_init(struct drm_device *dev)
if (!dev->mode_config.num_crtc || !dev->mode_config.num_connector)
return 0;
 
-   if (!exynos_drm_fbdev_is_anything_connected(dev))
-   return 0;
-
fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (!fbdev)
return -ENOMEM;
@@ -306,6 +285,4 @@ void exynos_drm_output_poll_changed(struct drm_device *dev)
 
if (fb_helper)
drm_fb_helper_hotplug_event(fb_helper);
-   else
-   exynos_drm_fbdev_init(dev);
 }
-- 
2.12.0

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

[Intel-gfx] [PATCH v4 04/11] drm/fb-helper: Push down modeset lock into FB helpers

[Thierry Reding]

From: Thierry Reding 

Move the modeset locking from drivers into FB helpers.

Tested-by: John Stultz 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c| 40 +-
 drivers/gpu/drm/i915/intel_dp_mst.c|  3 ---
 drivers/gpu/drm/radeon/radeon_dp_mst.c |  7 --
 3 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 673a47445d61..18105cbe9810 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,8 +109,8 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
 
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
-   struct drm_connector *connector)
+static int __drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+struct drm_connector *connector)
 {
struct drm_fb_helper_connector *fb_conn;
struct drm_fb_helper_connector **temp;
@@ -141,8 +141,23 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
drm_connector_get(connector);
fb_conn->connector = connector;
fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
+
return 0;
 }
+
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+   struct drm_connector *connector)
+{
+   int err;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+
+   err = __drm_fb_helper_add_one_connector(fb_helper, connector);
+
+   mutex_unlock(_helper->dev->mode_config.mutex);
+
+   return err;
+}
 EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
 
 /**
@@ -172,8 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
mutex_lock(>mode_config.mutex);
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
-   ret = drm_fb_helper_add_one_connector(fb_helper, connector);
-
+   ret = __drm_fb_helper_add_one_connector(fb_helper, connector);
if (ret)
goto fail;
}
@@ -198,8 +212,8 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
 
-int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
-  struct drm_connector *connector)
+static int __drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
+   struct drm_connector *connector)
 {
struct drm_fb_helper_connector *fb_helper_connector;
int i, j;
@@ -227,6 +241,20 @@ int drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
 
return 0;
 }
+
+int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
+  struct drm_connector *connector)
+{
+   int err;
+
+   mutex_lock(_helper->dev->mode_config.mutex);
+
+   err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
+
+   mutex_unlock(_helper->dev->mode_config.mutex);
+
+   return err;
+}
 EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
 
 static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct 
drm_fb_helper *helper)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c1f62eb07c07..1e3ee32a9acb 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -484,15 +484,12 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
   struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
-   struct drm_device *dev = connector->dev;
 
drm_connector_unregister(connector);
 
/* need to nuke the connector */
-   drm_modeset_lock_all(dev);
intel_connector_remove_from_fbdev(intel_connector);
intel_connector->mst_port = NULL;
-   drm_modeset_unlock_all(dev);
 
drm_connector_unreference(_connector->base);
DRM_DEBUG_KMS("\n");
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c 
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index 6598306dca9b..ebdf1b859cb6 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -300,9 +300,7 @@ static void radeon_dp_register_mst_connector(struct 
drm_connector *connector)
struct drm_device *dev = connector->dev;
struct radeon_device *rdev = dev->dev_private;
 
-   drm_modeset_lock_all(dev);

[Intel-gfx] [PATCH v4 10/11] drm/atmel-hlcdc: Remove unnecessary NULL check

[Thierry Reding]

From: Thierry Reding 

drm_fbdev_cma_hotplug_event() already checks for NULL pointers before
dereferencing, so callers don't need to do that.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index f4a3065f7f51..31443402b9a9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -450,8 +450,7 @@ static void atmel_hlcdc_fb_output_poll_changed(struct 
drm_device *dev)
 {
struct atmel_hlcdc_dc *dc = dev->dev_private;
 
-   if (dc->fbdev)
-   drm_fbdev_cma_hotplug_event(dc->fbdev);
+   drm_fbdev_cma_hotplug_event(dc->fbdev);
 }
 
 struct atmel_hlcdc_dc_commit {
-- 
2.12.0

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

[Intel-gfx] [PATCH v4 03/11] drm/fb-helper: Improve code readability

[Thierry Reding]

From: Thierry Reding 

Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.

Tested-by: John Stultz 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1581305c1053..673a47445d61 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,31 +109,38 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
 
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
drm_connector *connector)
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper,
+   struct drm_connector *connector)
 {
+   struct drm_fb_helper_connector *fb_conn;
struct drm_fb_helper_connector **temp;
-   struct drm_fb_helper_connector *fb_helper_connector;
+   unsigned int count;
 
if (!drm_fbdev_emulation)
return 0;
 
WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
-   if (fb_helper->connector_count + 1 > 
fb_helper->connector_info_alloc_count) {
-   temp = krealloc(fb_helper->connector_info, sizeof(struct 
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
+
+   count = fb_helper->connector_count + 1;
+
+   if (count > fb_helper->connector_info_alloc_count) {
+   size_t size = count * sizeof(fb_conn);
+
+   temp = krealloc(fb_helper->connector_info, size, GFP_KERNEL);
if (!temp)
return -ENOMEM;
 
-   fb_helper->connector_info_alloc_count = 
fb_helper->connector_count + 1;
+   fb_helper->connector_info_alloc_count = count;
fb_helper->connector_info = temp;
}
 
-   fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector), 
GFP_KERNEL);
-   if (!fb_helper_connector)
+   fb_conn = kzalloc(sizeof(*fb_conn), GFP_KERNEL);
+   if (!fb_conn)
return -ENOMEM;
 
drm_connector_get(connector);
-   fb_helper_connector->connector = connector;
-   fb_helper->connector_info[fb_helper->connector_count++] = 
fb_helper_connector;
+   fb_conn->connector = connector;
+   fb_helper->connector_info[fb_helper->connector_count++] = fb_conn;
return 0;
 }
 EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-- 
2.12.0

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

[Intel-gfx] [PATCH v4 09/11] drm/hisilicon: Remove custom FB helper deferred setup

[Thierry Reding]

From: Thierry Reding 

The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index df4f50713e54..408c7cfc180c 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -55,14 +55,7 @@ static void kirin_fbdev_output_poll_changed(struct 
drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
-   if (priv->fbdev) {
-   drm_fbdev_cma_hotplug_event(priv->fbdev);
-   } else {
-   priv->fbdev = drm_fbdev_cma_init(dev, 32,
-
dev->mode_config.num_connector);
-   if (IS_ERR(priv->fbdev))
-   priv->fbdev = NULL;
-   }
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
 }
 #endif
 
@@ -129,11 +122,19 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* init kms poll for handling hpd */
drm_kms_helper_poll_init(dev);
 
-   /* force detection after connectors init */
-   (void)drm_helper_hpd_irq_event(dev);
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+dev->mode_config.num_connector);
+   if (IS_ERR(priv->fbdev)) {
+   DRM_ERROR("failed to initialize fbdev.\n");
+   ret = PTR_ERR(priv->fbdev);
+   goto err_cleanup_poll;
+   }
 
return 0;
 
+err_cleanup_poll:
+   drm_kms_helper_poll_fini(dev);
+   drm_vblank_cleanup(dev);
 err_unbind_all:
component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
-- 
2.12.0

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

[Intel-gfx] [PATCH v4 11/11] drm/rockchip: Remove unnecessary NULL check

[Thierry Reding]

From: Thierry Reding 

The expression >fbdev_helper can never be NULL, so the check is
completely unnecessary.

Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 81f9548672b0..df6bceabeca8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -168,10 +168,8 @@ rockchip_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
 static void rockchip_drm_output_poll_changed(struct drm_device *dev)
 {
struct rockchip_drm_private *private = dev->dev_private;
-   struct drm_fb_helper *fb_helper = >fbdev_helper;
 
-   if (fb_helper)
-   drm_fb_helper_hotplug_event(fb_helper);
+   drm_fb_helper_hotplug_event(>fbdev_helper);
 }
 
 static void
-- 
2.12.0

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

[Intel-gfx] [PATCH v4 06/11] drm/fb-helper: Make top-level lock more robust

[Thierry Reding]

From: Thierry Reding 

The existing drm_fb_helper_hotplug_event() function needs to take the
top-level fb-helper lock. However, the function can also be called from
code that has already taken this lock. Introduce an unlocked variant of
this function that can be used in the latter case.

This function calls drm_fb_helper_restore_fbdev_mode_unlocked(), via
drm_fb_helper_set_par(), so we also need to introduce an unlocked copy
of that to avoid recursive locking issues.

Similarly, the drm_fb_helper_initial_config() function ends up calling
drm_fb_helper_set_par(), via register_framebuffer(), and needs an
unlocked variant to avoid recursive locking.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 167 +---
 1 file changed, 104 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 860be51d92f6..21a90322531c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -491,18 +491,10 @@ static int restore_fbdev_mode(struct drm_fb_helper 
*fb_helper)
return 0;
 }
 
-/**
- * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
- * @fb_helper: fbcon to restore
- *
- * This should be called from driver's drm _driver.lastclose callback
- * when implementing an fbcon on top of kms using this helper. This ensures 
that
- * the user isn't greeted with a black screen when e.g. X dies.
- *
- * RETURNS:
- * Zero if everything went ok, negative error code otherwise.
- */
-int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+static int __drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
+
+static int
+__drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
bool do_delayed;
@@ -511,7 +503,8 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
 
-   mutex_lock(_helper->lock);
+   WARN_ON(!mutex_is_locked(_helper->lock));
+
drm_modeset_lock_all(dev);
 
ret = restore_fbdev_mode(fb_helper);
@@ -521,10 +514,31 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
fb_helper->delayed_hotplug = false;
 
drm_modeset_unlock_all(dev);
-   mutex_unlock(_helper->lock);
 
if (do_delayed)
-   drm_fb_helper_hotplug_event(fb_helper);
+   __drm_fb_helper_hotplug_event(fb_helper);
+
+   return ret;
+}
+
+/**
+ * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration
+ * @fb_helper: fbcon to restore
+ *
+ * This should be called from driver's drm _driver.lastclose callback
+ * when implementing an fbcon on top of kms using this helper. This ensures 
that
+ * the user isn't greeted with a black screen when e.g. X dies.
+ *
+ * RETURNS:
+ * Zero if everything went ok, negative error code otherwise.
+ */
+int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper)
+{
+   int ret;
+
+   mutex_lock(_helper->lock);
+   ret = __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+   mutex_unlock(_helper->lock);
 
return ret;
 }
@@ -1486,7 +1500,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
return -EINVAL;
}
 
-   drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+   __drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
 
return 0;
 }
@@ -2333,6 +2347,46 @@ static void drm_setup_crtcs(struct drm_fb_helper 
*fb_helper,
kfree(enabled);
 }
 
+static int __drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper,
+ int bpp_sel)
+{
+   struct drm_device *dev = fb_helper->dev;
+   struct fb_info *info;
+   int ret;
+
+   if (!drm_fbdev_emulation)
+   return 0;
+
+   WARN_ON(!mutex_is_locked(_helper->lock));
+
+   mutex_lock(>mode_config.mutex);
+   drm_setup_crtcs(fb_helper,
+   dev->mode_config.max_width,
+   dev->mode_config.max_height);
+   ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
+   mutex_unlock(>mode_config.mutex);
+   if (ret)
+   return ret;
+
+   info = fb_helper->fbdev;
+   info->var.pixclock = 0;
+   ret = register_framebuffer(info);
+   if (ret < 0)
+   return ret;
+
+   dev_info(dev->dev, "fb%d: %s frame buffer device\n",
+info->node, info->fix.id);
+
+   mutex_lock(_fb_helper_lock);
+   if (list_empty(_fb_helper_list))
+   register_sysrq_key('v', _drm_fb_helper_restore_op);
+
+   list_add(_helper->kernel_fb_list, _fb_helper_list);
+   mutex_unlock(_fb_helper_lock);
+
+   return 0;
+}
+
 /**
  * drm_fb_helper_initial_config - setup a sane initial 

[Intel-gfx] [PATCH v4 02/11] drm/fb-helper: Reshuffle code for subsequent patches

[Thierry Reding]

From: Thierry Reding 

An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.

Tested-by: John Stultz 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 59 -
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d06027a1b9fa..1581305c1053 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -109,6 +109,35 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
for (({ lockdep_assert_held(&(fbh)->dev->mode_config.mutex); }), \
 i__ = 0; i__ < (fbh)->connector_count; i__++)
 
+int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
drm_connector *connector)
+{
+   struct drm_fb_helper_connector **temp;
+   struct drm_fb_helper_connector *fb_helper_connector;
+
+   if (!drm_fbdev_emulation)
+   return 0;
+
+   WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
+   if (fb_helper->connector_count + 1 > 
fb_helper->connector_info_alloc_count) {
+   temp = krealloc(fb_helper->connector_info, sizeof(struct 
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
+   if (!temp)
+   return -ENOMEM;
+
+   fb_helper->connector_info_alloc_count = 
fb_helper->connector_count + 1;
+   fb_helper->connector_info = temp;
+   }
+
+   fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector), 
GFP_KERNEL);
+   if (!fb_helper_connector)
+   return -ENOMEM;
+
+   drm_connector_get(connector);
+   fb_helper_connector->connector = connector;
+   fb_helper->connector_info[fb_helper->connector_count++] = 
fb_helper_connector;
+   return 0;
+}
+EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
+
 /**
  * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
  *emulation helper
@@ -162,36 +191,6 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
 }
 EXPORT_SYMBOL(drm_fb_helper_single_add_all_connectors);
 
-int drm_fb_helper_add_one_connector(struct drm_fb_helper *fb_helper, struct 
drm_connector *connector)
-{
-   struct drm_fb_helper_connector **temp;
-   struct drm_fb_helper_connector *fb_helper_connector;
-
-   if (!drm_fbdev_emulation)
-   return 0;
-
-   WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
-   if (fb_helper->connector_count + 1 > 
fb_helper->connector_info_alloc_count) {
-   temp = krealloc(fb_helper->connector_info, sizeof(struct 
drm_fb_helper_connector *) * (fb_helper->connector_count + 1), GFP_KERNEL);
-   if (!temp)
-   return -ENOMEM;
-
-   fb_helper->connector_info_alloc_count = 
fb_helper->connector_count + 1;
-   fb_helper->connector_info = temp;
-   }
-
-
-   fb_helper_connector = kzalloc(sizeof(struct drm_fb_helper_connector), 
GFP_KERNEL);
-   if (!fb_helper_connector)
-   return -ENOMEM;
-
-   drm_connector_get(connector);
-   fb_helper_connector->connector = connector;
-   fb_helper->connector_info[fb_helper->connector_count++] = 
fb_helper_connector;
-   return 0;
-}
-EXPORT_SYMBOL(drm_fb_helper_add_one_connector);
-
 int drm_fb_helper_remove_one_connector(struct drm_fb_helper *fb_helper,
   struct drm_connector *connector)
 {
-- 
2.12.0

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

[Intel-gfx] [PATCH v4 05/11] drm/fb-helper: Add top-level lock

[Thierry Reding]

From: Thierry Reding 

Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.

Tested-by: John Stultz 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 26 +-
 include/drm/drm_fb_helper.h | 12 
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 18105cbe9810..860be51d92f6 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -119,6 +119,7 @@ static int __drm_fb_helper_add_one_connector(struct 
drm_fb_helper *fb_helper,
if (!drm_fbdev_emulation)
return 0;
 
+   WARN_ON(!mutex_is_locked(_helper->lock));
WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
 
count = fb_helper->connector_count + 1;
@@ -150,11 +151,13 @@ int drm_fb_helper_add_one_connector(struct drm_fb_helper 
*fb_helper,
 {
int err;
 
+   mutex_lock(_helper->lock);
mutex_lock(_helper->dev->mode_config.mutex);
 
err = __drm_fb_helper_add_one_connector(fb_helper, connector);
 
mutex_unlock(_helper->dev->mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
return err;
 }
@@ -184,6 +187,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return 0;
 
+   mutex_lock(_helper->lock);
mutex_lock(>mode_config.mutex);
drm_connector_list_iter_begin(dev, _iter);
drm_for_each_connector_iter(connector, _iter) {
@@ -207,6 +211,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
 out:
drm_connector_list_iter_end(_iter);
mutex_unlock(>mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
return ret;
 }
@@ -221,6 +226,7 @@ static int __drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
if (!drm_fbdev_emulation)
return 0;
 
+   WARN_ON(!mutex_is_locked(_helper->lock));
WARN_ON(!mutex_is_locked(_helper->dev->mode_config.mutex));
 
for (i = 0; i < fb_helper->connector_count; i++) {
@@ -247,11 +253,13 @@ int drm_fb_helper_remove_one_connector(struct 
drm_fb_helper *fb_helper,
 {
int err;
 
+   mutex_lock(_helper->lock);
mutex_lock(_helper->dev->mode_config.mutex);
 
err = __drm_fb_helper_remove_one_connector(fb_helper, connector);
 
mutex_unlock(_helper->dev->mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
return err;
 }
@@ -503,16 +511,21 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct 
drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return -ENODEV;
 
+   mutex_lock(_helper->lock);
drm_modeset_lock_all(dev);
+
ret = restore_fbdev_mode(fb_helper);
 
do_delayed = fb_helper->delayed_hotplug;
if (do_delayed)
fb_helper->delayed_hotplug = false;
+
drm_modeset_unlock_all(dev);
+   mutex_unlock(_helper->lock);
 
if (do_delayed)
drm_fb_helper_hotplug_event(fb_helper);
+
return ret;
 }
 EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
@@ -748,6 +761,7 @@ void drm_fb_helper_prepare(struct drm_device *dev, struct 
drm_fb_helper *helper,
INIT_WORK(>resume_work, drm_fb_helper_resume_worker);
INIT_WORK(>dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
+   mutex_init(>lock);
helper->funcs = funcs;
helper->dev = dev;
 }
@@ -913,6 +927,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
}
mutex_unlock(_fb_helper_lock);
 
+   mutex_destroy(_helper->lock);
drm_fb_helper_crtc_free(fb_helper);
 
 }
@@ -2422,25 +2437,34 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
 int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
+   int err = 0;
 
if (!drm_fbdev_emulation)
return 0;
 
+   mutex_lock(_helper->lock);
mutex_lock(>mode_config.mutex);
+
if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
mutex_unlock(>mode_config.mutex);
-   return 0;
+   goto unlock;
}
+
DRM_DEBUG_KMS("\n");
 
drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height);
 
mutex_unlock(>mode_config.mutex);
+   mutex_unlock(_helper->lock);
 
drm_fb_helper_set_par(fb_helper->fbdev);
 
return 0;
+
+unlock:
+   mutex_unlock(_helper->lock);
+   return err;
 }
 EXPORT_SYMBOL(drm_fb_helper_hotplug_event);
 

[Intel-gfx] [PATCH v4 01/11] drm/fb-helper: Cleanup checkpatch warnings

[Thierry Reding]

From: Thierry Reding 

Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.

Tested-by: John Stultz 
Reviewed-by: Daniel Vetter 
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_fb_helper.c | 54 -
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e65becd964a1..d06027a1b9fa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -213,9 +213,9 @@ int drm_fb_helper_remove_one_connector(struct drm_fb_helper 
*fb_helper,
fb_helper_connector = fb_helper->connector_info[i];
drm_connector_put(fb_helper_connector->connector);
 
-   for (j = i + 1; j < fb_helper->connector_count; j++) {
+   for (j = i + 1; j < fb_helper->connector_count; j++)
fb_helper->connector_info[j - 1] = fb_helper->connector_info[j];
-   }
+
fb_helper->connector_count--;
kfree(fb_helper_connector);
 
@@ -316,6 +316,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
 
for (i = 0; i < helper->crtc_count; i++) {
struct drm_mode_set *mode_set = >crtc_info[i].mode_set;
+
crtc = mode_set->crtc;
funcs = crtc->helper_private;
fb = drm_mode_config_fb(crtc);
@@ -346,7 +347,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper)
struct drm_plane *plane;
struct drm_atomic_state *state;
int i, ret;
-   unsigned plane_mask;
+   unsigned int plane_mask;
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -378,7 +379,7 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
*fb_helper)
goto fail;
}
 
-   for(i = 0; i < fb_helper->crtc_count; i++) {
+   for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set = 
_helper->crtc_info[i].mode_set;
 
ret = __drm_atomic_helper_set_config(mode_set, state);
@@ -488,8 +489,10 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
*fb_helper)
struct drm_crtc *crtc;
int bound = 0, crtcs_bound = 0;
 
-   /* Sometimes user space wants everything disabled, so don't steal the
-* display if there's a master. */
+   /*
+* Sometimes user space wants everything disabled, so don't steal the
+* display if there's a master.
+*/
if (READ_ONCE(dev->master))
return false;
 
@@ -537,6 +540,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
 static void drm_fb_helper_restore_work_fn(struct work_struct *ignored)
 {
bool ret;
+
ret = drm_fb_helper_force_kernel_mode();
if (ret == true)
DRM_ERROR("Failed to restore crtc configuration\n");
@@ -870,9 +874,8 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
mutex_lock(_fb_helper_lock);
if (!list_empty(_helper->kernel_fb_list)) {
list_del(_helper->kernel_fb_list);
-   if (list_empty(_fb_helper_list)) {
+   if (list_empty(_fb_helper_list))
unregister_sysrq_key('v', 
_drm_fb_helper_restore_op);
-   }
}
mutex_unlock(_fb_helper_lock);
 
@@ -1165,6 +1168,7 @@ static int setcolreg(struct drm_crtc *crtc, u16 red, u16 
green,
(blue << info->var.blue.offset);
if (info->var.transp.length > 0) {
u32 mask = (1 << info->var.transp.length) - 1;
+
mask <<= info->var.transp.offset;
value |= mask;
}
@@ -1447,7 +1451,7 @@ static int pan_display_atomic(struct fb_var_screeninfo 
*var,
struct drm_atomic_state *state;
struct drm_plane *plane;
int i, ret;
-   unsigned plane_mask;
+   unsigned int plane_mask;
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -1456,7 +1460,7 @@ static int pan_display_atomic(struct fb_var_screeninfo 
*var,
state->acquire_ctx = dev->mode_config.acquire_ctx;
 retry:
plane_mask = 0;
-   for(i = 0; i < fb_helper->crtc_count; i++) {
+   for (i = 0; i < fb_helper->crtc_count; i++) {
struct drm_mode_set *mode_set;
 
mode_set = _helper->crtc_info[i].mode_set;
@@ -1561,11 +1565,10 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
memset(, 0, sizeof(struct drm_fb_helper_surface_size));
sizes.surface_depth = 24;
sizes.surface_bpp = 32;
-   sizes.fb_width = (unsigned)-1;
-   sizes.fb_height = (unsigned)-1;
+   sizes.fb_width = (u32)-1;
+   sizes.fb_height = (u32)-1;
 
-   /* if driver picks 8 or 16 by default use that
-  for both depth/bpp */
+   /* if driver picks 

[Intel-gfx] [PATCH v4 00/11] drm/fb-helper: Deferred setup support

[Thierry Reding]

From: Thierry Reding 

This set of patches adds support for deferring FB helper setup, which is
useful to obtain a sane configuration even when no outputs are available
during probe.

One example is HDMI, where fbdev will currently fallback to a 1024x786
resolution if no monitor is connected, and will then forever stay that
way. With these patches, the FB helpers will take note that it doesn't
make sense to setup fbdev yet and will defer until a monitor is
connected, at which point the preferred mode will be selected.

Thierry

Changes in v4:
- use fb_conn for variables of type struct drm_fb_helper_connector *
  for consistency
- make top-level FB helper lock more robust
- improve kerneldoc

Changes in v3:
- fix kerneldoc for top-level FB helper lock
- drop some patches that no longer apply
- add Tested-by from John Stultz
- add cleanup patches

Changes in v2:
- now with locking

Thierry Reding (11):
  drm/fb-helper: Cleanup checkpatch warnings
  drm/fb-helper: Reshuffle code for subsequent patches
  drm/fb-helper: Improve code readability
  drm/fb-helper: Push down modeset lock into FB helpers
  drm/fb-helper: Add top-level lock
  drm/fb-helper: Make top-level lock more robust
  drm/fb-helper: Support deferred setup
  drm/exynos: Remove custom FB helper deferred setup
  drm/hisilicon: Remove custom FB helper deferred setup
  drm/atmel-hlcdc: Remove unnecessary NULL check
  drm/rockchip: Remove unnecessary NULL check

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|   3 +-
 drivers/gpu/drm/drm_fb_helper.c | 376 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c   |  23 --
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  21 +-
 drivers/gpu/drm/i915/intel_dp_mst.c |   3 -
 drivers/gpu/drm/radeon/radeon_dp_mst.c  |   7 -
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |   4 +-
 include/drm/drm_fb_helper.h |  35 +++
 9 files changed, 316 insertions(+), 162 deletions(-)

-- 
2.12.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 drm/i915: Make legacy cursor updates more unsynced (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Make legacy cursor updates more unsynced (rev2)
URL   : https://patchwork.freedesktop.org/series/22031/
State : success

== Summary ==

Series 22031v2 drm/i915: Make legacy cursor updates more unsynced
https://patchwork.freedesktop.org/api/1.0/series/22031/revisions/2/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 469s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 467s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 543s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 582s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 503s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 499s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 439s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 436s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 437s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 516s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 491s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 597s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 487s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 594s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 483s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 520s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 474s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 551s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 425s

2f9f22b419350cafb06ba7e5342bc461fcb0afca drm-tip: 2017y-03m-29d-12h-52m-56s UTC 
integration manifest
57d55b4 drm/i915: Make legacy cursor updates more unsynced

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/3] drm/i915: Rename intel_engine_cs.exec_id to uabi_id

[Patchwork]

== Series Details ==

Series: series starting with [RFC,1/3] drm/i915: Rename intel_engine_cs.exec_id 
to uabi_id
URL   : https://patchwork.freedesktop.org/series/22088/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 461s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 462s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 584s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 534s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 593s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 502s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 506s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 435s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 437s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 448s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 509s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 497s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 486s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 594s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 485s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 598s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 488s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 522s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 460s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 548s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 430s

2f9f22b419350cafb06ba7e5342bc461fcb0afca drm-tip: 2017y-03m-29d-12h-52m-56s UTC 
integration manifest
18a8f8e drm/i915: Rename intel_engine_cs.exec_id to uabi_id

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Make legacy cursor updates more unsynced

[ville . syrjala]

From: Ville Syrjälä 

We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up the commit.

Also toss in a FIXME about solving these problems in a nicer
way using the fabled vblank workers.

v2: Also unsync with legacy page flips

Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Uwe Kleine-König 
Cc: Rafael Ristovski 
Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a79063fac951..dc9be40641e2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13029,17 +13029,6 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
 
-   /*
-* The intel_legacy_cursor_update() fast path takes care
-* of avoiding the vblank waits for simple cursor
-* movement and flips. For cursor on/off and size changes,
-* we want to perform the vblank waits so that watermark
-* updates happen during the correct frames. Gen9+ have
-* double buffered watermarks and so shouldn't need this.
-*/
-   if (INTEL_GEN(dev_priv) < 9)
-   state->legacy_cursor_update = false;
-
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
@@ -13055,6 +13044,26 @@ static int intel_atomic_commit(struct drm_device *dev,
return ret;
}
 
+   /*
+* The intel_legacy_cursor_update() fast path takes care
+* of avoiding the vblank waits for simple cursor
+* movement and flips. For cursor on/off and size changes,
+* we want to perform the vblank waits so that watermark
+* updates happen during the correct frames. Gen9+ have
+* double buffered watermarks and so shouldn't need this.
+*
+* Do this after drm_atomic_helper_setup_commit() and
+* intel_atomic_prepare_commit() because we still want
+* to skip the flip and fb cleanup waits. Although that
+* does risk yanking the mapping from under the display
+* engine.
+*
+* FIXME doing watermarks and fb cleanup from a vblank worker
+* (assuming we had any) would solve these problems.
+*/
+   if (INTEL_GEN(dev_priv) < 9)
+   state->legacy_cursor_update = false;
+
drm_atomic_helper_swap_state(state, true);
dev_priv->wm.distrust_bios_wm = false;
intel_shared_dpll_swap_state(state);
-- 
2.10.2

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

Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.

[Maarten Lankhorst]

Op 29-03-17 om 16:06 schreef Daniel Vetter:
> On Wed, Mar 29, 2017 at 03:51:08PM +0200, Maarten Lankhorst wrote:
>> Op 29-03-17 om 15:31 schreef Boris Brezillon:
>>> On Wed, 29 Mar 2017 15:26:45 +0200
>>> Daniel Vetter  wrote:
>>>
 On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> mode_valid() and get_modes() called
> from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected when a connector property forces the connector
> into DVI mode.
>
> Some implementations of detect() already lock all state,
> so we have to pass an acquire_ctx to them to prevent a deadlock.
>
> This means changing the function signature of detect() slightly,
> and passing the acquire_ctx for locking multiple crtc's.
> It might be NULL, in which case expensive operations should be avoided.
>
> intel_dp.c however ignores the force flag, so still lock
> connection_mutex there if needed.
>
> Signed-off-by: Maarten Lankhorst 
> Cc: Boris Brezillon 
> Cc: Manasi Navare   
 Hm only noticed this now, but mixing up force with the acquire_ctx sounds
 like very bad interface design. Yes, the only user of the new hook works
 like that, but that's really accidental I think. I think just having the
 ctx everywhere (for atomic drivers at least) would be a lot safer. This is
 extremely surprising (and undocumented suprise at that).
>>> Yes, I was about to say the same thing: the interface is not very
>>> clear, and I don't understand why ctx = NULL implies force = false.
>> They're the same thing I fear. I could perhaps call it force_ctx instead,
>> but non-zero ctx implies force, and other way around. Though I guess we could
>> relax it, and have force = true imply ctx, but not the other way around.
>>
>> Would that be ok?
> Why can't we supply a ctx always? I didn't see any reason not to in the
> code ...
> -Daniel

Then drm_helper_hpd_irq_event and intel_hpd_irq_event have to do -EDEADLK 
handling too,
it could be done but nothing would return -EDEADLK so it's unused code.

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

Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.

[Daniel Vetter]

On Wed, Mar 29, 2017 at 03:51:08PM +0200, Maarten Lankhorst wrote:
> Op 29-03-17 om 15:31 schreef Boris Brezillon:
> > On Wed, 29 Mar 2017 15:26:45 +0200
> > Daniel Vetter  wrote:
> >
> >> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> >>> mode_valid() and get_modes() called
> >>> from drm_helper_probe_single_connector_modes()
> >>> may need to look at connector->state because what a valid mode is may
> >>> depend on connector properties being set. For example some HDMI modes
> >>> might be rejected when a connector property forces the connector
> >>> into DVI mode.
> >>>
> >>> Some implementations of detect() already lock all state,
> >>> so we have to pass an acquire_ctx to them to prevent a deadlock.
> >>>
> >>> This means changing the function signature of detect() slightly,
> >>> and passing the acquire_ctx for locking multiple crtc's.
> >>> It might be NULL, in which case expensive operations should be avoided.
> >>>
> >>> intel_dp.c however ignores the force flag, so still lock
> >>> connection_mutex there if needed.
> >>>
> >>> Signed-off-by: Maarten Lankhorst 
> >>> Cc: Boris Brezillon 
> >>> Cc: Manasi Navare   
> >> Hm only noticed this now, but mixing up force with the acquire_ctx sounds
> >> like very bad interface design. Yes, the only user of the new hook works
> >> like that, but that's really accidental I think. I think just having the
> >> ctx everywhere (for atomic drivers at least) would be a lot safer. This is
> >> extremely surprising (and undocumented suprise at that).
> > Yes, I was about to say the same thing: the interface is not very
> > clear, and I don't understand why ctx = NULL implies force = false.
> 
> They're the same thing I fear. I could perhaps call it force_ctx instead,
> but non-zero ctx implies force, and other way around. Though I guess we could
> relax it, and have force = true imply ctx, but not the other way around.
> 
> Would that be ok?

Why can't we supply a ctx always? I didn't see any reason not to in the
code ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 1/3] drm/i915: Rename intel_engine_cs.exec_id to uabi_id

[Chris Wilson]

We want to refer to the index of the engine consistently throughout the
userspace ABI. We already have such an index through the execbuffer
engine specifier, that needs to be able to refer to each engine
specifically.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c  |  8 
 drivers/gpu/drm/i915/i915_gem.c |  2 +-
 drivers/gpu/drm/i915/intel_engine_cs.c  | 14 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f110ed6678e9..3cbc7507e4a2 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1156,8 +1156,8 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
find_reg(engine, is_master, reg_addr);
 
if (!reg) {
-   DRM_DEBUG_DRIVER("CMD: Rejected register 0x%08X 
in command: 0x%08X (exec_id=%d)\n",
-reg_addr, *cmd, 
engine->exec_id);
+   DRM_DEBUG_DRIVER("CMD: Rejected register 0x%08X 
in command: 0x%08X (%s)\n",
+reg_addr, *cmd, engine->name);
return false;
}
 
@@ -1212,11 +1212,11 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
desc->bits[i].mask;
 
if (dword != desc->bits[i].expected) {
-   DRM_DEBUG_DRIVER("CMD: Rejected command 0x%08X 
for bitmask 0x%08X (exp=0x%08X act=0x%08X) (exec_id=%d)\n",
+   DRM_DEBUG_DRIVER("CMD: Rejected command 0x%08X 
for bitmask 0x%08X (exp=0x%08X act=0x%08X) (%s)\n",
 *cmd,
 desc->bits[i].mask,
 desc->bits[i].expected,
-dword, engine->exec_id);
+dword, engine->name);
return false;
}
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c2e5cb529b0f..15282eef5012 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3757,7 +3757,7 @@ __busy_set_if_active(const struct dma_fence *fence,
if (i915_gem_request_completed(rq))
return 0;
 
-   return flag(rq->engine->exec_id);
+   return flag(rq->engine->uabi_id);
 }
 
 static __always_inline unsigned int
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index bd91aa1f0deb..0f8b3312dad8 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -28,7 +28,7 @@
 
 static const struct engine_info {
const char *name;
-   unsigned int exec_id;
+   unsigned int uabi_id;
unsigned int hw_id;
u32 mmio_base;
unsigned irq_shift;
@@ -37,7 +37,7 @@ static const struct engine_info {
 } intel_engines[] = {
[RCS] = {
.name = "render ring",
-   .exec_id = I915_EXEC_RENDER,
+   .uabi_id = I915_EXEC_RENDER,
.hw_id = RCS_HW,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
@@ -46,7 +46,7 @@ static const struct engine_info {
},
[BCS] = {
.name = "blitter ring",
-   .exec_id = I915_EXEC_BLT,
+   .uabi_id = I915_EXEC_BLT,
.hw_id = BCS_HW,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
@@ -55,7 +55,7 @@ static const struct engine_info {
},
[VCS] = {
.name = "bsd ring",
-   .exec_id = I915_EXEC_BSD,
+   .uabi_id = I915_EXEC_BSD,
.hw_id = VCS_HW,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
@@ -64,7 +64,7 @@ static const struct engine_info {
},
[VCS2] = {
.name = "bsd2 ring",
-   .exec_id = I915_EXEC_BSD,
+   .uabi_id = I915_EXEC_BSD,
.hw_id = VCS2_HW,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
@@ -73,7 +73,7 @@ static const struct engine_info {
},
[VECS] = {
.name = "video enhancement ring",
-   .exec_id = I915_EXEC_VEBOX,
+   .uabi_id = I915_EXEC_VEBOX,
.hw_id = VECS_HW,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
@@ -97,7 +97,7 @@ intel_engine_setup(struct 

[Intel-gfx] [RFC 2/3] drm/i915: Add a routine to map from UABI id to engine

[Chris Wilson]

We have to mix a static UABI engine id with the potential for a varying
hw_id and layout, and so we need a way to map from the userspace id for
an engine to our internal pointers.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 17 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0f8b3312dad8..8a197f826d38 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1125,6 +1125,23 @@ void intel_engines_cleanup(struct drm_i915_private *i915)
engine->cleanup(engine);
 }
 
+struct intel_engine_cs *
+intel_engine_lookup(struct drm_i915_private *i915, u32 uabi_id)
+{
+   static const enum intel_engine_id uabi_map[] = {
+   [I915_EXEC_DEFAULT] = RCS,
+   [I915_EXEC_RENDER]  = RCS,
+   [I915_EXEC_BLT] = BCS,
+   [I915_EXEC_BSD] = VCS,
+   [I915_EXEC_VEBOX]   = VECS,
+   };
+
+   if (uabi_id >= ARRAY_SIZE(uabi_map))
+   return NULL;
+
+   return i915->engine[uabi_map[uabi_id]];
+}
+
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/mock_engine.c"
 #endif
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 53880389e6c9..7f8366da5a4c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -671,6 +671,9 @@ static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 
flags, u32 offset)
return batch + 6;
 }
 
+struct intel_engine_cs *
+intel_engine_lookup(struct drm_i915_private *i915, u32 uabi_id);
+
 bool intel_engine_is_idle(struct intel_engine_cs *engine);
 bool intel_engines_are_idle(struct drm_i915_private *dev_priv);
 
-- 
2.11.0

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

[Intel-gfx] [RFC 3/3] drm/i915: Finally assign BSD2 its own specific UABI identifier

[Chris Wilson]

3 years too late, but hopefully better late than never, start to
rectify the damage caused by commit a8ebba75b358 ("drm/i915: Use the
coarse ping-pong mechanism based on drm fd to dispatch the BSD command
on BDW GT3") and compounded by commit 8d360dffd6d8 ("drm/i915: Specify
bsd rings through exec flag") which did not allocate BSD2 its own
identifier but overloaded the existing BSD uabi id.

Worse, those patches *overrode* existing behaviour (i.e. were not
backwards or forwards compatible) which makes undoing the damage tricky.
As an ABI break seems unavoidable, make it so. The ramification is that
libva on a few bdw/skl boxes will lose access to the second BSD engine
until it is updated to request the second engine explicitly (which is
what libva preferred to do anyway!)

Signed-off-by: Chris Wilson 
Cc: Zhipeng Gong 
Cc: Zhao Yakui 
Cc: Rodrigo Vivi 
Cc: Imre Deak 
Cc: Daniel Vetter mm.lock);
INIT_LIST_HEAD(_priv->mm.request_list);
 
-   file_priv->bsd_engine = -1;
-
ret = i915_gem_context_open(dev, file);
if (ret)
kfree(file_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 21c1478a6944..a24c3ce3a871 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1948,82 +1948,6 @@ eb_submit(struct i915_execbuffer *eb)
return 0;
 }
 
-/**
- * Find one BSD ring to dispatch the corresponding BSD command.
- * The engine index is returned.
- */
-static unsigned int
-gen8_dispatch_bsd_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file)
-{
-   struct drm_i915_file_private *file_priv = file->driver_priv;
-
-   /* Check whether the file_priv has already selected one ring. */
-   if ((int)file_priv->bsd_engine < 0)
-   file_priv->bsd_engine = atomic_fetch_xor(1,
-_priv->mm.bsd_engine_dispatch_index);
-
-   return file_priv->bsd_engine;
-}
-
-#define I915_USER_RINGS (4)
-
-static const enum intel_engine_id user_ring_map[I915_USER_RINGS + 1] = {
-   [I915_EXEC_DEFAULT] = RCS,
-   [I915_EXEC_RENDER]  = RCS,
-   [I915_EXEC_BLT] = BCS,
-   [I915_EXEC_BSD] = VCS,
-   [I915_EXEC_VEBOX]   = VECS
-};
-
-static struct intel_engine_cs *
-eb_select_engine(struct drm_i915_private *dev_priv,
-struct drm_file *file,
-struct drm_i915_gem_execbuffer2 *args)
-{
-   unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
-   struct intel_engine_cs *engine;
-
-   if (user_ring_id > I915_USER_RINGS) {
-   DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
-   return NULL;
-   }
-
-   if ((user_ring_id != I915_EXEC_BSD) &&
-   ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
-   DRM_DEBUG("execbuf with non bsd ring but with invalid "
- "bsd dispatch flags: %d\n", (int)(args->flags));
-   return NULL;
-   }
-
-   if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
-   unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
-
-   if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
-   bsd_idx = gen8_dispatch_bsd_engine(dev_priv, file);
-   } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
-  bsd_idx <= I915_EXEC_BSD_RING2) {
-   bsd_idx >>= I915_EXEC_BSD_SHIFT;
-   bsd_idx--;
-   } else {
-   DRM_DEBUG("execbuf with unknown bsd ring: %u\n",
- 

Re: [Intel-gfx] [PATCH] drm/i915: Make legacy cursor updates more unsynced

[Maarten Lankhorst]

Op 28-03-17 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> We're clearing the legacy_cursor_update flag before calling
> drm_atomic_helper_setup_commit() which means the helper will
> wait for the flip to complete before cleaning up the framebuffers.
> That's not what we want for the legacy cursor, so let's clear
> the flag after setting up the commit.
>
> Also toss in a FIXME about solving these problems in a nicer
> way using the fabled vblank workers.
>
> Cc: Maarten Lankhorst 
> Cc: Daniel Vetter 
> Cc: Uwe Kleine-König 
> Cc: Rafael Ristovski 
> Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 654b8a0c28ee..05ff193f2dd8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13024,6 +13024,10 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   int ret = 0;
>  
> + ret = drm_atomic_helper_setup_commit(state, nonblock);
> + if (ret)
> + return ret;
> +
>   /*
>* The intel_legacy_cursor_update() fast path takes care
>* of avoiding the vblank waits for simple cursor
> @@ -13031,14 +13035,18 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>* we want to perform the vblank waits so that watermark
>* updates happen during the correct frames. Gen9+ have
>* double buffered watermarks and so shouldn't need this.
> +  *
> +  * Do this after drm_atomic_helper_setup_commit() because
> +  * we still want to skip the fb cleanup waits from the
> +  * atomic helper. Although that does risk yanking the
> +  * mapping from under the display engine.
> +  *
> +  * FIXME doing watermarks and fb cleanup from a vblank worker
> +  * (assuming we had any) would solve these problems.
>*/
>   if (INTEL_GEN(dev_priv) < 9)
>   state->legacy_cursor_update = false;
>  
> - ret = drm_atomic_helper_setup_commit(state, nonblock);
> - if (ret)
> - return ret;
> -
>   drm_atomic_state_get(state);
>   i915_sw_fence_init(_state->commit_ready,
>  intel_atomic_commit_ready);

From irc:
 hmm. actually should probably move that thing to happen even later. 
we should skip the flip waits from intel_atomic_prepare_commit() as well i recon


Makes sense. Not sure how much we care about legacy page flips, since they're 
on their way out.

If this is fixed and trybot is happy with v2 then I will be too. :)

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

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

[Takashi Iwai]

On Wed, 29 Mar 2017 15:34:15 +0200,
Ville Syrjälä wrote:
> 
> On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > On Mon, 27 Mar 2017 18:02:13 +0200,
> > Takashi Iwai wrote:
> > > 
> > > Hi,
> > > 
> > > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > > drm/i915: Call intel_dp_mst_resume() before resuming displays
> > > 
> > > seems to trigger a kernel panic when some modeset change happens after
> > > S3 resume.  The details are found in openSUSE bugzilla,
> > >   https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > > 
> > > In short, the following procedure causes a kernel panic (supposedly)
> > > almost 100% on Dell Latitude with Skylake with MST DP on dock:
> > > 
> > > - Boot with a docking station, DP-1 connected.
> > > - Login on X
> > > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of 
> > > eDP-1
> > >   ==> This changes the mode.
> > > - Suspend ("systemctl suspend" in my case), and close the lid.
> > > - Remove from the dock (keep the lid closed).
> > > - Open the lid, which resumes automatically.  It works.
> > > - Suspend again.
> > > - Connect to the dock again (keep the lid closed).
> > > - Open the lid, which resumes automatically.  It's still OK.
> > > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of 
> > > eDP-1
> > >   ==> Now the kernel feezes.
> > > 
> > > Reverting the commit mentioned above fixes the problem.
> > > 
> > > The problem is present in all versions I tested.  The reported kernel
> > > in the Bugzilla is 4.4.x-based one, but the issue is seen in 4.11-rc3,
> > > too.  Note that the S3 resume itself works in 4.11-rc3; the kernel
> > > panic happens when invoking xrandr manually after that.
> > > 
> > > Unfortunately, I couldn't get a kernel panic message, so far.  kdump
> > > didn't work well in this case by some reason.  There are some
> > > screenshots taken by the original reporter (could switch VT
> > > beforehand), but I don't know whether it helps.
> > > 
> > > If you have any hints for further debugging, it'd be highly
> > > appreciated.
> > 
> > It seems that the patch below works around the problem.
> > Can anyone enlighten what's going on there?
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > -- 8< --
> > From: Takashi Iwai 
> > Subject: [PATCH] drm/i915: Fix crash after S3 resume with DP MST mode change
> > 
> > We've got a bug report showing that Skylake Dell machines with a
> > docking station causes a kernel panic after S3 resume and modeset.
> > The details are found in the openSUSE bugzilla entry below.  The
> > typical test procedure is:
> > 
> > - Laptop is Dell Latitude with eDP (1366x768)
> > - Boot with docking station connected to a DP (1920x1080)
> > - Login, change the mode via
> >   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of eDP-1
> > - Suspend, and close the lid after the suspend
> >   (or close the lid to trigger the suspend)
> > - Undock while keeping the lid closed.
> > - Open the lid, which triggers the resume;
> >   the machine wakes up well, and X shows up.  No problem, so far.
> > - Suspend again, close the lid.
> > - Dock again while keeping the lid closed.
> > - Open the lid, triggering the resume; this wakes up still fine.
> > - At this moment, run xrandr again to re-setup DP-1
> >   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of eDP-1
> >   ==> This triggers a hard crash.
> > 
> > I could bisect it, and this leaded to the commit a16b7658f4e0
> > ("drm/i915: Call intel_dp_mst_resume() before resuming displays").
> > 
> > Basically the commit just shuffles the calls of intel_display_resume()
> > and intel_dp_mst_resume().  So as a workaround, I tried to split
> > intel_dp_mst_resume() call to postpone the suspected code (the
> > invocation of intel_dp_check_mst_status()), then bingo, this cured the
> > problem.
> > 
> > But don't ask me *why* this fixes.  It's still in a cargo-cult state.
> > 
> > Fixes: a16b7658f4e0 ("drm/i915: Call intel_dp_mst_resume() before resuming 
> > displays")
> > Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c  |  5 -
> >  drivers/gpu/drm/i915/intel_dp.c  | 20 +++-
> >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> >  3 files changed, 25 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 1c75402a59c1..62c40090ceed 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1559,6 +1559,7 @@ static int i915_suspend_switcheroo(struct drm_device 
> > *dev, pm_message_t state)
> >  static int i915_drm_resume(struct drm_device *dev)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > +   int mst_pending;
> > int ret;
> >  
> > disable_rpm_wakeref_asserts(dev_priv);
> > @@ -1608,10 +1609,12 @@ static int 

Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.

[Maarten Lankhorst]

Op 29-03-17 om 15:31 schreef Boris Brezillon:
> On Wed, 29 Mar 2017 15:26:45 +0200
> Daniel Vetter  wrote:
>
>> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
>>> mode_valid() and get_modes() called
>>> from drm_helper_probe_single_connector_modes()
>>> may need to look at connector->state because what a valid mode is may
>>> depend on connector properties being set. For example some HDMI modes
>>> might be rejected when a connector property forces the connector
>>> into DVI mode.
>>>
>>> Some implementations of detect() already lock all state,
>>> so we have to pass an acquire_ctx to them to prevent a deadlock.
>>>
>>> This means changing the function signature of detect() slightly,
>>> and passing the acquire_ctx for locking multiple crtc's.
>>> It might be NULL, in which case expensive operations should be avoided.
>>>
>>> intel_dp.c however ignores the force flag, so still lock
>>> connection_mutex there if needed.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> Cc: Boris Brezillon 
>>> Cc: Manasi Navare   
>> Hm only noticed this now, but mixing up force with the acquire_ctx sounds
>> like very bad interface design. Yes, the only user of the new hook works
>> like that, but that's really accidental I think. I think just having the
>> ctx everywhere (for atomic drivers at least) would be a lot safer. This is
>> extremely surprising (and undocumented suprise at that).
> Yes, I was about to say the same thing: the interface is not very
> clear, and I don't understand why ctx = NULL implies force = false.

They're the same thing I fear. I could perhaps call it force_ctx instead,
but non-zero ctx implies force, and other way around. Though I guess we could
relax it, and have force = true imply ctx, but not the other way around.

Would that be ok?

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

Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.

[Boris Brezillon]

On Wed, 29 Mar 2017 15:26:45 +0200
Daniel Vetter  wrote:

> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> > mode_valid() and get_modes() called
> > from drm_helper_probe_single_connector_modes()
> > may need to look at connector->state because what a valid mode is may
> > depend on connector properties being set. For example some HDMI modes
> > might be rejected when a connector property forces the connector
> > into DVI mode.
> > 
> > Some implementations of detect() already lock all state,
> > so we have to pass an acquire_ctx to them to prevent a deadlock.
> > 
> > This means changing the function signature of detect() slightly,
> > and passing the acquire_ctx for locking multiple crtc's.
> > It might be NULL, in which case expensive operations should be avoided.
> > 
> > intel_dp.c however ignores the force flag, so still lock
> > connection_mutex there if needed.
> > 
> > Signed-off-by: Maarten Lankhorst 
> > Cc: Boris Brezillon 
> > Cc: Manasi Navare   
> 
> Hm only noticed this now, but mixing up force with the acquire_ctx sounds
> like very bad interface design. Yes, the only user of the new hook works
> like that, but that's really accidental I think. I think just having the
> ctx everywhere (for atomic drivers at least) would be a lot safer. This is
> extremely surprising (and undocumented suprise at that).

Yes, I was about to say the same thing: the interface is not very
clear, and I don't understand why ctx = NULL implies force = false.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Ville Syrjälä]

On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> On Mon, 27 Mar 2017 18:02:13 +0200,
> Takashi Iwai wrote:
> > 
> > Hi,
> > 
> > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > drm/i915: Call intel_dp_mst_resume() before resuming displays
> > 
> > seems to trigger a kernel panic when some modeset change happens after
> > S3 resume.  The details are found in openSUSE bugzilla,
> >   https://bugzilla.suse.com/show_bug.cgi?id=1029634
> > 
> > In short, the following procedure causes a kernel panic (supposedly)
> > almost 100% on Dell Latitude with Skylake with MST DP on dock:
> > 
> > - Boot with a docking station, DP-1 connected.
> > - Login on X
> > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of 
> > eDP-1
> >   ==> This changes the mode.
> > - Suspend ("systemctl suspend" in my case), and close the lid.
> > - Remove from the dock (keep the lid closed).
> > - Open the lid, which resumes automatically.  It works.
> > - Suspend again.
> > - Connect to the dock again (keep the lid closed).
> > - Open the lid, which resumes automatically.  It's still OK.
> > - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of 
> > eDP-1
> >   ==> Now the kernel feezes.
> > 
> > Reverting the commit mentioned above fixes the problem.
> > 
> > The problem is present in all versions I tested.  The reported kernel
> > in the Bugzilla is 4.4.x-based one, but the issue is seen in 4.11-rc3,
> > too.  Note that the S3 resume itself works in 4.11-rc3; the kernel
> > panic happens when invoking xrandr manually after that.
> > 
> > Unfortunately, I couldn't get a kernel panic message, so far.  kdump
> > didn't work well in this case by some reason.  There are some
> > screenshots taken by the original reporter (could switch VT
> > beforehand), but I don't know whether it helps.
> > 
> > If you have any hints for further debugging, it'd be highly
> > appreciated.
> 
> It seems that the patch below works around the problem.
> Can anyone enlighten what's going on there?
> 
> 
> thanks,
> 
> Takashi
> 
> -- 8< --
> From: Takashi Iwai 
> Subject: [PATCH] drm/i915: Fix crash after S3 resume with DP MST mode change
> 
> We've got a bug report showing that Skylake Dell machines with a
> docking station causes a kernel panic after S3 resume and modeset.
> The details are found in the openSUSE bugzilla entry below.  The
> typical test procedure is:
> 
> - Laptop is Dell Latitude with eDP (1366x768)
> - Boot with docking station connected to a DP (1920x1080)
> - Login, change the mode via
>   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of eDP-1
> - Suspend, and close the lid after the suspend
>   (or close the lid to trigger the suspend)
> - Undock while keeping the lid closed.
> - Open the lid, which triggers the resume;
>   the machine wakes up well, and X shows up.  No problem, so far.
> - Suspend again, close the lid.
> - Dock again while keeping the lid closed.
> - Open the lid, triggering the resume; this wakes up still fine.
> - At this moment, run xrandr again to re-setup DP-1
>   xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of eDP-1
>   ==> This triggers a hard crash.
> 
> I could bisect it, and this leaded to the commit a16b7658f4e0
> ("drm/i915: Call intel_dp_mst_resume() before resuming displays").
> 
> Basically the commit just shuffles the calls of intel_display_resume()
> and intel_dp_mst_resume().  So as a workaround, I tried to split
> intel_dp_mst_resume() call to postpone the suspected code (the
> invocation of intel_dp_check_mst_status()), then bingo, this cured the
> problem.
> 
> But don't ask me *why* this fixes.  It's still in a cargo-cult state.
> 
> Fixes: a16b7658f4e0 ("drm/i915: Call intel_dp_mst_resume() before resuming 
> displays")
> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1029634
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  |  5 -
>  drivers/gpu/drm/i915/intel_dp.c  | 20 +++-
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
>  3 files changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1c75402a59c1..62c40090ceed 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1559,6 +1559,7 @@ static int i915_suspend_switcheroo(struct drm_device 
> *dev, pm_message_t state)
>  static int i915_drm_resume(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> + int mst_pending;
>   int ret;
>  
>   disable_rpm_wakeref_asserts(dev_priv);
> @@ -1608,10 +1609,12 @@ static int i915_drm_resume(struct drm_device *dev)
>   dev_priv->display.hpd_irq_setup(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  
> - intel_dp_mst_resume(dev);
> + mst_pending = intel_dp_mst_resume(dev);
>  
>   intel_display_resume(dev);
>  
> + 

Re: [Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes.

[Daniel Vetter]

On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> mode_valid() and get_modes() called
> from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected when a connector property forces the connector
> into DVI mode.
> 
> Some implementations of detect() already lock all state,
> so we have to pass an acquire_ctx to them to prevent a deadlock.
> 
> This means changing the function signature of detect() slightly,
> and passing the acquire_ctx for locking multiple crtc's.
> It might be NULL, in which case expensive operations should be avoided.
> 
> intel_dp.c however ignores the force flag, so still lock
> connection_mutex there if needed.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Boris Brezillon 
> Cc: Manasi Navare 

Hm only noticed this now, but mixing up force with the acquire_ctx sounds
like very bad interface design. Yes, the only user of the new hook works
like that, but that's really accidental I think. I think just having the
ctx everywhere (for atomic drivers at least) would be a lot safer. This is
extremely surprising (and undocumented suprise at that).

> ---
>  drivers/gpu/drm/drm_probe_helper.c   | 41 
> ++--
>  drivers/gpu/drm/i915/intel_crt.c | 29 +
>  drivers/gpu/drm/i915/intel_display.c | 25 +++---
>  drivers/gpu/drm/i915/intel_dp.c  | 22 ---
>  drivers/gpu/drm/i915/intel_drv.h |  8 +++
>  drivers/gpu/drm/i915/intel_hotplug.c |  6 +-
>  drivers/gpu/drm/i915/intel_tv.c  | 24 ++---
>  include/drm/drm_connector.h  |  5 +
>  8 files changed, 101 insertions(+), 59 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 85005d57bde6..a48cff963871 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -169,11 +169,15 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>  
>  static enum drm_connector_status
> -drm_connector_detect(struct drm_connector *connector, bool force)
> +drm_connector_detect(struct drm_connector *connector,
> +  struct drm_modeset_acquire_ctx *ctx)
>  {
> - return connector->funcs->detect ?
> - connector->funcs->detect(connector, force) :
> - connector_status_connected;
> + if (connector->funcs->detect_ctx)
> + return connector->funcs->detect_ctx(connector, ctx);
> + else if (connector->funcs->detect)
> + return connector->funcs->detect(connector, !!ctx);
> + else
> + return connector_status_connected;
>  }
>  
>  /**
> @@ -239,15 +243,27 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   struct drm_display_mode *mode;
>   const struct drm_connector_helper_funcs *connector_funcs =
>   connector->helper_private;
> - int count = 0;
> + int count = 0, ret;
>   int mode_flags = 0;
>   bool verbose_prune = true;
>   enum drm_connector_status old_status;
> + struct drm_modeset_acquire_ctx ctx;
>  
>   WARN_ON(!mutex_is_locked(>mode_config.mutex));
>  
> + drm_modeset_acquire_init(, 0);
> +
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
>   connector->name);
> +
> +retry:
> + ret = drm_modeset_lock(>mode_config.connection_mutex, );
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + } else
> + WARN_ON(ret < 0);
> +
>   /* set all old modes to the stale state */
>   list_for_each_entry(mode, >modes, head)
>   mode->status = MODE_STALE;
> @@ -263,7 +279,15 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   if (connector->funcs->force)
>   connector->funcs->force(connector);
>   } else {
> - connector->status = drm_connector_detect(connector, true);
> + ret = drm_connector_detect(connector, );
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + } else if (WARN(ret < 0, "Invalid return value %i for connector 
> detection\n", ret))
> + ret = connector_status_unknown;
> +
> + connector->status = ret;
>   }
>  
>   /*
> @@ -355,6 +379,9 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>  prune:
>   drm_mode_prune_invalid(dev, >modes, verbose_prune);
>  
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
>   if (list_empty(>modes))
>   

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

[Takashi Iwai]

On Mon, 27 Mar 2017 18:02:13 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> drm/i915: Call intel_dp_mst_resume() before resuming displays
> 
> seems to trigger a kernel panic when some modeset change happens after
> S3 resume.  The details are found in openSUSE bugzilla,
>   https://bugzilla.suse.com/show_bug.cgi?id=1029634
> 
> In short, the following procedure causes a kernel panic (supposedly)
> almost 100% on Dell Latitude with Skylake with MST DP on dock:
> 
> - Boot with a docking station, DP-1 connected.
> - Login on X
> - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of 
> eDP-1
>   ==> This changes the mode.
> - Suspend ("systemctl suspend" in my case), and close the lid.
> - Remove from the dock (keep the lid closed).
> - Open the lid, which resumes automatically.  It works.
> - Suspend again.
> - Connect to the dock again (keep the lid closed).
> - Open the lid, which resumes automatically.  It's still OK.
> - xrandr --output eDP-1 --primary --auto --output DP-1-1 --auto --left-of 
> eDP-1
>   ==> Now the kernel feezes.
> 
> Reverting the commit mentioned above fixes the problem.
> 
> The problem is present in all versions I tested.  The reported kernel
> in the Bugzilla is 4.4.x-based one, but the issue is seen in 4.11-rc3,
> too.  Note that the S3 resume itself works in 4.11-rc3; the kernel
> panic happens when invoking xrandr manually after that.
> 
> Unfortunately, I couldn't get a kernel panic message, so far.  kdump
> didn't work well in this case by some reason.  There are some
> screenshots taken by the original reporter (could switch VT
> beforehand), but I don't know whether it helps.
> 
> If you have any hints for further debugging, it'd be highly
> appreciated.

It seems that the patch below works around the problem.
Can anyone enlighten what's going on there?


thanks,

Takashi

-- 8< --
From: Takashi Iwai 
Subject: [PATCH] drm/i915: Fix crash after S3 resume with DP MST mode change

We've got a bug report showing that Skylake Dell machines with a
docking station causes a kernel panic after S3 resume and modeset.
The details are found in the openSUSE bugzilla entry below.  The
typical test procedure is:

- Laptop is Dell Latitude with eDP (1366x768)
- Boot with docking station connected to a DP (1920x1080)
- Login, change the mode via
  xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of eDP-1
- Suspend, and close the lid after the suspend
  (or close the lid to trigger the suspend)
- Undock while keeping the lid closed.
- Open the lid, which triggers the resume;
  the machine wakes up well, and X shows up.  No problem, so far.
- Suspend again, close the lid.
- Dock again while keeping the lid closed.
- Open the lid, triggering the resume; this wakes up still fine.
- At this moment, run xrandr again to re-setup DP-1
  xrandr --output eDP-1 --auto --output DP-1-1 --auto --left-of eDP-1
  ==> This triggers a hard crash.

I could bisect it, and this leaded to the commit a16b7658f4e0
("drm/i915: Call intel_dp_mst_resume() before resuming displays").

Basically the commit just shuffles the calls of intel_display_resume()
and intel_dp_mst_resume().  So as a workaround, I tried to split
intel_dp_mst_resume() call to postpone the suspected code (the
invocation of intel_dp_check_mst_status()), then bingo, this cured the
problem.

But don't ask me *why* this fixes.  It's still in a cargo-cult state.

Fixes: a16b7658f4e0 ("drm/i915: Call intel_dp_mst_resume() before resuming 
displays")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1029634
Signed-off-by: Takashi Iwai 
---
 drivers/gpu/drm/i915/i915_drv.c  |  5 -
 drivers/gpu/drm/i915/intel_dp.c  | 20 +++-
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1c75402a59c1..62c40090ceed 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1559,6 +1559,7 @@ static int i915_suspend_switcheroo(struct drm_device 
*dev, pm_message_t state)
 static int i915_drm_resume(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
+   int mst_pending;
int ret;
 
disable_rpm_wakeref_asserts(dev_priv);
@@ -1608,10 +1609,12 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->display.hpd_irq_setup(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 
-   intel_dp_mst_resume(dev);
+   mst_pending = intel_dp_mst_resume(dev);
 
intel_display_resume(dev);
 
+   intel_dp_mst_resume_post(dev, mst_pending);
+
drm_kms_helper_poll_enable(dev);
 
/*
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d1670b8afbf5..fc5ea900e6f3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6027,9 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Skip enabling GuC submission if the driver is wedged

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Skip enabling GuC submission if the driver is wedged
URL   : https://patchwork.freedesktop.org/series/22084/
State : success

== Summary ==

Series 22084v1 drm/i915/guc: Skip enabling GuC submission if the driver is 
wedged
https://patchwork.freedesktop.org/api/1.0/series/22084/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 469s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 453s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 536s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 581s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 508s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 502s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 442s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 430s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 448s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 523s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 491s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 480s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 593s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 487s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 606s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 487s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 523s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 465s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 552s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 424s

ebaabad531fb4609576b8aec9c0d7db09eb7d65c drm-tip: 2017y-03m-29d-12h-03m-37s UTC 
integration manifest
8f5448b drm/i915/guc: Skip enabling GuC submission if the driver is wedged

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Skip enabling GuC submission if the driver is wedged

[Michal Wajdeczko]

On Wed, Mar 29, 2017 at 01:35:00PM +0100, Chris Wilson wrote:
> If the driver is wedged, we will not be using the GPU. (Userspace will
> be told NO!) As we won't be using the GPU until the wedged status is
> cleared and the device restarted, we can skip enabling the guc whilst
> the driver is terminally wedged, and so avoid trying to use a truly
> wedged device.
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Oscar Mateo 
> Cc: Daniele Ceraolo Spurio 
> Cc: Michal Wajdeczko 
> Cc: Arkadiusz Hiler 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index b04b46966780..96235024e62c 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1213,6 +1213,13 @@ int i915_guc_submission_enable(struct drm_i915_private 
> *dev_priv)
>   enum intel_engine_id id;
>   int err;
>  
> + /* Don't start the guc if the driver is wedged - we won't be using
> +  * the gpu anyway until after the wedged status is cleared and we
> +  * do a restrt of the device.

s/restrt/restart

> +  */
> + if (i915_terminally_wedged(_priv->gpu_error))
> + return -EIO;
> +

Hmm, I'm wondering if maybe intel_uc_init_hw() would be a better place for this 
check.

-Michal

>   if (!client) {
>   client = guc_client_alloc(dev_priv,
> INTEL_INFO(dev_priv)->ring_mask,
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Fixes that failed to backport to v4.11-rc1

[Jani Nikula]

On Wed, 29 Mar 2017, Chris Wilson  wrote:
> On Wed, Mar 29, 2017 at 01:45:38PM +0300, Jani Nikula wrote:
>> On Tue, 21 Mar 2017, Jani Nikula  wrote:
>> > On Mon, 13 Mar 2017, Jani Nikula  wrote:
>> >> I'm already scripting my fixes backports quite a bit, and frankly don't
>> >> really manually backport anything that doesn't apply cleanly. I'm
>> >> thinking of automating some "failed to backport" reporting to authors,
>> >> not unlike the failed stable backport reports.
>> >>
>> >> This is a manual report that the following commits have been marked as
>> >> Cc: stable or fixing something in v4.11-rc1, but failed to cherry-pick
>> >> to drm-intel-fixes. Please see if they are worth backporting, and please
>> >> do so if they are.
>> >>
>> >> Feedback about the idea of this reporting is also appreciated.
>> >
>> > Refreshed list as of today:
>> >
>> > bd784b7cc41a ("drm/i915: Avoid rcu_barrier() from reclaim paths 
>> > (shrinker)")
>> > 3fc03069bc6e ("drm/i915: make context status notifier head be per engine")
>> > 2e8f9d322948 ("drm/i915: Restore engine->submit_request before unwedging")
>> 
>> Update:
>> 
>> e2a2aa36a509 ("drm/i915: Check we have an wake device before flushing GTT 
>> writes")
>
> Not worth it. The WARN is disabled in v4.11 so nobody will notice.
>
>> 450362d3fe86 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")
>
> Done.

Thanks, pushed to drm-intel-fixes.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc: Skip enabling GuC submission if the driver is wedged

[Chris Wilson]

If the driver is wedged, we will not be using the GPU. (Userspace will
be told NO!) As we won't be using the GPU until the wedged status is
cleared and the device restarted, we can skip enabling the guc whilst
the driver is terminally wedged, and so avoid trying to use a truly
wedged device.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index b04b46966780..96235024e62c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1213,6 +1213,13 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
enum intel_engine_id id;
int err;
 
+   /* Don't start the guc if the driver is wedged - we won't be using
+* the gpu anyway until after the wedged status is cleared and we
+* do a restrt of the device.
+*/
+   if (i915_terminally_wedged(_priv->gpu_error))
+   return -EIO;
+
if (!client) {
client = guc_client_alloc(dev_priv,
  INTEL_INFO(dev_priv)->ring_mask,
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid lock dropping between rescheduling

[Chris Wilson]

On Wed, Mar 29, 2017 at 10:33:47AM +0100, Tvrtko Ursulin wrote:
> 
> On 27/03/2017 21:21, Chris Wilson wrote:
> >Unlocking is dangerous. In this case we combine an early update to the
> >out-of-queue request, because we know that it will be inserted into the
> >correct FIFO priority-ordered slot when it becomes ready in the future.
> >However, given sufficient enthusiasm, it may become ready as we are
> >continuing to reschedule, and so may gazump the FIFO if we have since
> >dropped its spinlock. The result is that it may be executed too early,
> >before its dependencies.
> >
> >v2: Move all work into the second phase over the topological sort. This
> >removes the shortcut on the out-of-rbtree request to ensure that we only
> >adjust its priority after adjusting all of its dependencies.
> >
> >Fixes: 20311bd35060 ("drm/i915/scheduler: Execute requests in order of 
> >priorities")
> >Testcase: igt/gem_exec_whisper
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc:  # v4.10+
> >---
> > drivers/gpu/drm/i915/intel_lrc.c | 44 
> > ++--
> > 1 file changed, 20 insertions(+), 24 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index b0c3a029b592..91e38e80a095 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >@@ -665,8 +665,8 @@ pt_lock_engine(struct i915_priotree *pt, struct 
> >intel_engine_cs *locked)
> >   priotree)->engine;
> > if (engine != locked) {
> > if (locked)
> 
> Could replace "if (locked)" with a GEM_BUG_ON(!locked) now.
> 
> >-spin_unlock_irq(>timeline->lock);
> >-spin_lock_irq(>timeline->lock);
> >+spin_unlock(>timeline->lock);
> >+spin_lock(>timeline->lock);
> > }
> >
> > return engine;

[snip]

> Looks OK to me. Preferably with the tidy in pt_lock_engine:
> 
> Reviewed-by: Tvrtko Ursulin 

Pushed with the suggested improvement, thanks.
-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] Fixes that failed to backport to v4.11-rc1

[Chris Wilson]

On Wed, Mar 29, 2017 at 01:45:38PM +0300, Jani Nikula wrote:
> On Tue, 21 Mar 2017, Jani Nikula  wrote:
> > On Mon, 13 Mar 2017, Jani Nikula  wrote:
> >> I'm already scripting my fixes backports quite a bit, and frankly don't
> >> really manually backport anything that doesn't apply cleanly. I'm
> >> thinking of automating some "failed to backport" reporting to authors,
> >> not unlike the failed stable backport reports.
> >>
> >> This is a manual report that the following commits have been marked as
> >> Cc: stable or fixing something in v4.11-rc1, but failed to cherry-pick
> >> to drm-intel-fixes. Please see if they are worth backporting, and please
> >> do so if they are.
> >>
> >> Feedback about the idea of this reporting is also appreciated.
> >
> > Refreshed list as of today:
> >
> > bd784b7cc41a ("drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)")
> > 3fc03069bc6e ("drm/i915: make context status notifier head be per engine")
> > 2e8f9d322948 ("drm/i915: Restore engine->submit_request before unwedging")
> 
> Update:
> 
> e2a2aa36a509 ("drm/i915: Check we have an wake device before flushing GTT 
> writes")

Not worth it. The WARN is disabled in v4.11 so nobody will notice.

> 450362d3fe86 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")

Done.
-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] drm/i915/execlists: Wrap tail pointer after reset tweaking

[Chris Wilson]

If the request->wa_tail is 0 (because it landed exactly on the end of
the ringbuffer), when we reconstruct request->tail following a reset we
fill in an illegal value (-8 or 0x0018). As a result, RING_HEAD is
never able to catch up with RING_TAIL and the GPU spins endlessly. If
the ring contains a couple of breadcrumbs, even our hangcheck is unable
to catch the busy-looping as the ACTHD and seqno continually advance.

v2: Move the wrap into a common intel_ring_wrap().

Fixes: a3aabe86a340 ("drm/i915/execlists: Reinitialise context image after GPU 
hang")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc:  # v4.10+
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170327130009.4678-1-ch...@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala 
(cherry picked from commit 450362d3fe866b14304f309b5fffba0c33fbfbc3)
---
 drivers/gpu/drm/i915/intel_lrc.c| 4 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h | 8 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 471af3b480ad..91555d4e9129 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1440,7 +1440,9 @@ static void reset_common_ring(struct intel_engine_cs 
*engine,
GEM_BUG_ON(request->ctx != port[0].request->ctx);
 
/* Reset WaIdleLiteRestore:bdw,skl as well */
-   request->tail = request->wa_tail - WA_TAIL_DWORDS * sizeof(u32);
+   request->tail =
+   intel_ring_wrap(request->ring,
+   request->wa_tail - WA_TAIL_DWORDS*sizeof(u32));
 }
 
 static int intel_logical_ring_emit_pdps(struct drm_i915_gem_request *req)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 13dccb18cd43..8cb2078c5bfc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -521,11 +521,17 @@ static inline void intel_ring_advance(struct intel_ring 
*ring)
 */
 }
 
+static inline u32
+intel_ring_wrap(const struct intel_ring *ring, u32 pos)
+{
+   return pos & (ring->size - 1);
+}
+
 static inline u32 intel_ring_offset(struct intel_ring *ring, void *addr)
 {
/* Don't write ring->size (equivalent to 0) as that hangs some GPUs. */
u32 offset = addr - ring->vaddr;
-   return offset & (ring->size - 1);
+   return intel_ring_wrap(ring, offset);
 }
 
 int __intel_ring_space(int head, int tail, int size);
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Validate cached link rate and lane count before retraining

[Jani Nikula]

On Wed, 29 Mar 2017, Ville Syrjälä  wrote:
> On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
>> On Tue, 28 Mar 2017, Manasi Navare  wrote:
>> > Jani,
>> >
>> > Should I just hold on to this until your patch series
>> > gets merged so I can rebase this on top of it?
>> 
>> I think I'd prefer that, especially so because I'm not sure that this
>> patch does the right thing. Yes, this checks that the values are within
>> bounds, but that they are within bounds doesn't make them any more valid
>> for the current link if they are indeed stale!
>
> Can they be stale and still be within the bounds somehow?

Maybe not. Maybe I just don't follow. Perhaps the commit message
deserves a better description of the cases where we hit the case.

>> >> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)

Side note, it bugs me that the function name has a grammatical error.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Skip execlists_dequeue() early if the list is empty"

[Chris Wilson]

On Wed, Mar 29, 2017 at 12:18:57PM +0100, Chris Wilson wrote:
> On Wed, Mar 29, 2017 at 11:00:52AM +0100, Chris Wilson wrote:
> > This reverts commit 6c943de6686f ("drm/i915: Skip execlists_dequeue()
> > early if the list is empty").
> > 
> > The validity of using READ_ONCE there depends upon having a mb to
> > coordinate the assignment of engine->execlist_first inside
> > submit_request() and checking prior to taking the spinlock in
> > execlists_dequeue(). We wrote "the update to TASKLET_SCHED incurs a
> > memory barrier making this cross-cpu checking safe", but failed to
> > notice that this mb was *conditional* on the execlists being ready, i.e.
> > there wasn't the request mb when it was most necessary!
> 
> s/request/required/
> 
> > We could install an unconditional memory barrier to fixup the
> > READ_ONCE():
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 7dd732cb9f57..1ed164b16d44 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -616,6 +616,7 @@ static void execlists_submit_request(struct
> > drm_i915_gem_request *request)
> > 
> > if (insert_request(>priotree, >execlist_queue))
> > {
> > engine->execlist_first = >priotree.node;
> > +   smp_wmb();
> > if (execlists_elsp_ready(engine))
> > 
> > But we have opted to remove the race as it should be rarely effective,
> > and saves us having to explain the necessary memory barriers which we
> > quite clearly failed at.
> > 
> 
> Reported-and-tested-by: Tvrtko Ursulin 
> > Fixes: 6c943de6686f ("drm/i915: Skip execlists_dequeue() early if the list 
> > is empty")
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Joonas Lahtinen 
> > Cc: Michał Winiarski 

Pushed with Tvrtko's r-b from irc.
-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] [PATCHi v2] drm/i915: Enhanced disable access to stolen memory as a guest

[Daniel Vetter]

On Tue, Mar 28, 2017 at 01:28:43AM +, Zhang, Xiong Y wrote:
> > > Reviewed-by: Zhenyu Wang 
> > 
> > Entirely disabling stolen is rather massive, this stuff is supposed to
> > work ... There should be special RMRR mappings in the iommu to help the
> > guest access the stolen range correctly from the gpu.
> > 
> > Which machine where does this blow up on?
> > -Daniel
> [Zhang, Xiong Y] Yes. Stolen memory is protected by RMRR on host. But Qemu 
> couldn't support and don't have plan to support RMRR. Then EPT lack of 
> mapping for stolen memory, guest couldn't access it.
> The Qemu/Vfio is designed by Redhat engineers, Redhat has a white paper to 
> explain why Qemu don't support RMRR:
> https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

I chatted with Joonas, and he dug out the commit that changed this:

commit c875d2c1b8083cd627ea0463e20bf22c2d7421ee
Author: Alex Williamson 
Date:   Thu Jul 3 09:57:02 2014 -0600

iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains

The user of the IOMMU API domain expects to have full control of
the IOVA space for the domain.  RMRRs are fundamentally incompatible
with that idea.  We can neither map the RMRR into the IOMMU API
domain, nor can we guarantee that the device won't continue DMA with
the area described by the RMRR as part of the new domain.  Therefore
we must prevent such devices from being used by the IOMMU API.

Signed-off-by: Alex Williamson 
Cc: David Woodhouse 
Cc: sta...@vger.kernel.org
Signed-off-by: Joerg Roedel 

Please reference that commit (plus the whitepaper if you want to) in your
commit message, and resubmit it with a Fixes: and cc: stable lines. This
sounds like a bugfix that we need to backport.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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 v2] drm/i915/dp: Validate cached link rate and lane count before retraining

[Ville Syrjälä]

On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
> On Tue, 28 Mar 2017, Manasi Navare  wrote:
> > Jani,
> >
> > Should I just hold on to this until your patch series
> > gets merged so I can rebase this on top of it?
> 
> I think I'd prefer that, especially so because I'm not sure that this
> patch does the right thing. Yes, this checks that the values are within
> bounds, but that they are within bounds doesn't make them any more valid
> for the current link if they are indeed stale!

Can they be stale and still be within the bounds somehow? That doesn't
make much sense to me. Althogh the way we shrink the set of valid params
doesn't make much sense to me either since we don't monotonically reduce
the link bw.

> 
> BR,
> Jani.
> 
> 
> >
> > Regards
> > Manasi
> >
> >
> > On Mon, Mar 27, 2017 at 02:44:50PM -0700, Manasi Navare wrote:
> >> Currently intel_dp_check_link_status() tries to retrain the link if
> >> Clock recovery or Channel EQ for any of the lanes indicated by
> >> intel_dp->lane_count is not set. However these values cached in intel_dp
> >> structure can be stale if link training has failed for these values
> >> during previous modeset. Or these values can get stale since we have
> >> now re read the DPCD registers or it can be 0 in case of connected boot
> >> case.
> >> 
> >> This patch validates these values against the common_rates and max lane
> >> count values.
> >> 
> >> This is absolutely required incase the common_rates or max lane count
> >> are now different due to link fallback.
> >> 
> >> v2:
> >> * Include the FIXME commnet inside the function (Ville Syrjala)
> >> * Remove the redundant parenthesis (Ville Syrjala)
> >> 
> >> Cc: Ville Syrjala 
> >> Cc: Jani Nikula 
> >> Signed-off-by: Manasi Navare 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dp.c | 28 +---
> >>  1 file changed, 25 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index fd96a6c..d0ab307 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -295,6 +295,27 @@ static int intel_dp_link_rate_index(struct intel_dp 
> >> *intel_dp,
> >>return -1;
> >>  }
> >>  
> >> +static bool intel_dp_link_params_is_valid(struct intel_dp *intel_dp)
> >> +{
> >> +  int common_rates[DP_MAX_SUPPORTED_RATES];
> >> +  int link_rate_index;
> >> +
> >> +  /* FIXME: we need to synchronize the current link parameters with
> >> +   * hardware readout. Currently fast link training doesn't work
> >> +   * on boot-up.
> >> +   */
> >> +  link_rate_index = intel_dp_link_rate_index(intel_dp,
> >> + common_rates,
> >> + intel_dp->link_rate);
> >> +  if (link_rate_index < 0)
> >> +  return false;
> >> +  if (!intel_dp->lane_count ||
> >> +  intel_dp->lane_count > intel_dp_max_lane_count(intel_dp))
> >> +  return false;
> >> +
> >> +  return true;
> >> +}
> >> +
> >>  int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> >>int link_rate, uint8_t lane_count)
> >>  {
> >> @@ -4224,9 +4245,10 @@ intel_dp_check_link_status(struct intel_dp 
> >> *intel_dp)
> >>if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> >>return;
> >>  
> >> -  /* FIXME: we need to synchronize this sort of stuff with hardware
> >> -   * readout. Currently fast link training doesn't work on boot-up. */
> >> -  if (!intel_dp->lane_count)
> >> +  /* Validate the cached values of intel_dp->link_rate and
> >> +   * intel_dp->lane_count before attempting to retrain.
> >> +   */
> >> +  if (!intel_dp_link_params_is_valid(intel_dp))
> >>return;
> >>  
> >>/* Retrain if Channel EQ or CR not ok */
> >> -- 
> >> 2.1.4
> >> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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 v2] drm: Refactor vblank sequence number comparison

[Ville Syrjälä]

On Thu, Mar 23, 2017 at 12:23:34PM +0900, Michel Dänzer wrote:
> On 22/03/17 07:06 PM, Chris Wilson wrote:
> > Move the repeated (a - b) <= (1 << 23) to its own function.
> > 
> > v2: Catch the '1<<23' inside drm_handle_vblank() as well
> > 
> > Signed-off-by: Chris Wilson 
> 
> Reviewed-by: Michel Dänzer 

Entire series pushed to drm-misc-next. Thanks for the patches and
review.

-- 
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 v2] drm: Make the decision to keep vblank irq enabled earlier

[Ville Syrjälä]

On Fri, Mar 24, 2017 at 05:30:58PM +, Chris Wilson wrote:
> We want to provide the vblank irq shadow for pageflip events as well as
> vblank queries. Such events are completed within the vblank interrupt
> handler, and so the current check for disabling the irq will disable it
> from with the same interrupt as the last pageflip event. If we move the
> decision on whether to disable the irq (based on there no being no
> remaining vblank events, i.e. vblank->refcount == 0) to before we signal
> the events, we will only disable the irq on the interrupt after the last
> event was signaled. In the normal course of events, this will keep the
> vblank irq enabled for the entire flip sequence whereas before it would
> flip-flop around every interrupt.
> 
> v2: Move the disable_fn() call outside of the vblank_event_lock.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: Michel Dänzer 
> Cc: Laurent Pinchart 
> Cc: Dave Airlie ,
> Cc: Mario Kleiner 
> Reviewed-by: Ville Syrjälä  #v1
> Reviewed-by: Mario Kleiner  #v1

Pushed to drm-misc-next. Thanks for the patch and review.

> ---
>  drivers/gpu/drm/drm_irq.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 5b77057e91ca..a511597580d8 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
> int pipe)
>  {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>   unsigned long irqflags;
> + bool disable_irq;
>  
>   if (WARN_ON_ONCE(!dev->num_crtcs))
>   return false;
> @@ -1768,20 +1769,23 @@ bool drm_handle_vblank(struct drm_device *dev, 
> unsigned int pipe)
>   spin_unlock(>vblank_time_lock);
>  
>   wake_up(>queue);
> - drm_handle_vblank_events(dev, pipe);
>  
>   /* With instant-off, we defer disabling the interrupt until after
> -  * we finish processing the following vblank. The disable has to
> -  * be last (after drm_handle_vblank_events) so that the timestamp
> -  * is always accurate.
> +  * we finish processing the following vblank after all events have
> +  * been signaled. The disable has to be last (after
> +  * drm_handle_vblank_events) so that the timestamp is always accurate.
>*/
> - if (dev->vblank_disable_immediate &&
> - drm_vblank_offdelay > 0 &&
> - !atomic_read(>refcount))
> - vblank_disable_fn((unsigned long)vblank);
> + disable_irq = (dev->vblank_disable_immediate &&
> +drm_vblank_offdelay > 0 &&
> +!atomic_read(>refcount));
> +
> + drm_handle_vblank_events(dev, pipe);
>  
>   spin_unlock_irqrestore(>event_lock, irqflags);
>  
> + if (disable_irq)
> + vblank_disable_fn((unsigned long)vblank);
> +
>   return true;
>  }
>  EXPORT_SYMBOL(drm_handle_vblank);
> -- 
> 2.11.0

-- 
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 v2 5/5] drm/i915/uc: Move fw path check to fetch_uc_fw()

[Michal Wajdeczko]

There is no reason to separately check for valid fw path before
we try to fetch it. Let the fetch function take care of this.

Signed-off-by: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Joonas Lahtinen 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_uc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 4ab24a1..4dfde2c 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -112,6 +112,9 @@ static void fetch_uc_fw(struct drm_i915_private *dev_priv,
size_t size;
int err;
 
+   if (!uc_fw->path)
+   return;
+
uc_fw->fetch_status = INTEL_UC_FIRMWARE_PENDING;
 
DRM_DEBUG_DRIVER("before requesting firmware: uC fw fetch status %s\n",
@@ -239,11 +242,8 @@ static void fetch_uc_fw(struct drm_i915_private *dev_priv,
 
 void intel_uc_init_fw(struct drm_i915_private *dev_priv)
 {
-   if (dev_priv->huc.fw.path)
-   fetch_uc_fw(dev_priv, _priv->huc.fw);
-
-   if (dev_priv->guc.fw.path)
-   fetch_uc_fw(dev_priv, _priv->guc.fw);
+   fetch_uc_fw(dev_priv, _priv->huc.fw);
+   fetch_uc_fw(dev_priv, _priv->guc.fw);
 }
 
 void intel_uc_fini_fw(struct drm_i915_private *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 v2 4/5] drm/i915/huc: Remove unused intel_huc_fini()

[Michal Wajdeczko]

This function is no longer used. Its functionality is covered
by intel_uc_fini_fw().

Signed-off-by: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Joonas Lahtinen 
Reviewed-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_huc.c | 18 --
 drivers/gpu/drm/i915/intel_uc.h  |  1 -
 2 files changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 7af900b..9ee8196 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -251,24 +251,6 @@ int intel_huc_init_hw(struct intel_huc *huc)
 }
 
 /**
- * intel_huc_fini() - clean up resources allocated for HuC
- * @dev_priv: the drm_i915_private device
- *
- * Cleans up by releasing the huc firmware GEM obj.
- */
-void intel_huc_fini(struct drm_i915_private *dev_priv)
-{
-   struct intel_uc_fw *huc_fw = _priv->huc.fw;
-   struct drm_i915_gem_object *obj;
-
-   obj = fetch_and_zero(_fw->obj);
-   if (obj)
-   i915_gem_object_put(obj);
-
-   huc_fw->fetch_status = INTEL_UC_FIRMWARE_NONE;
-}
-
-/**
  * intel_guc_auth_huc() - authenticate ucode
  * @dev_priv: the drm_i915_device
  *
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 7139e31..d2dcde7 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -270,7 +270,6 @@ static inline u32 guc_ggtt_offset(struct i915_vma *vma)
 
 /* intel_huc.c */
 void intel_huc_select_fw(struct intel_huc *huc);
-void intel_huc_fini(struct drm_i915_private  *dev_priv);
 int intel_huc_init_hw(struct intel_huc *huc);
 void intel_guc_auth_huc(struct drm_i915_private *dev_priv);
 
-- 
2.7.4

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