Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Fri, 2016-08-05 at 02:35 +, Yang, Libin wrote:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf 
> > Of
> > Dhinakaran Pandiyan
> > Sent: Wednesday, August 3, 2016 10:15 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: alsa-de...@alsa-project.org; ti...@suse.de; libin.y...@linux.intel.com;
> > Pandiyan, Dhinakaran 
> > Subject: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST
> > 
> > DP MST provides the capability to send multiple video and audio streams via
> > one single port. This requires the API's between i915 and audio drivers to
> > distinguish between audio capable displays connected to a port. This patch
> > adds this support via an additional parameter 'int dev_id'. The existing
> > parameter 'port' does not change it's meaning.
> > 
> > dev_id =
> > MST : pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int dev_id,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > 
> > This patch makes dummy changes in the audio drivers for build to succeed.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 82 +--
> > ---
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 ++---
> >  sound/hda/hdac_i915.c  |  9 +++--
> >  sound/pci/hda/patch_hdmi.c |  7 ++--
> >  6 files changed, 82 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 65ada5d..8e4c8c8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> > 
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> 
> We may still need save the port number info.
> In non-MST mode, device entry means nothing. This means
> av_enc_map[pipe] may not get the right intel_encoder
> 
> Regards,
> Libin
> 
We find the encoder using port in get_saved_encoder()
> > 
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your
> > patch diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 8c493de..cbe44c8 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -500,6 +500,9 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = crtc->pipe;
> > +   int dev_id = -1;
> > +
> > 
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -522,14 +525,19 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)
> > dev_priv->display.audio_codec_enable(connector,
> > intel_encoder,
> >  adjusted_mode);
> > 
> > +   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > +   dev_id = pipe;
> > +
> > mutex_lock(_priv->av_mutex);
> > intel_encoder->audio_connector = connector;
> > +
> > /* referred in audio callbacks */
> > -   dev_priv->dig_port_map[port] = intel_encoder;
> > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> > mutex_unlock(_priv->av_mutex);
> > 
> > if (acomp && acomp->audio_ops && acomp->audio_ops-
> > >pin_eld_notify)
> > -   acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> > >audio_ptr, (int) port);
> > +   acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> > >audio_ptr,
> > +(int) port, dev_id);
> >  }
> > 
> >  /**
> > @@ -542,22 +550,29 @@ void intel_audio_codec_enable(struct intel_encoder
> > *intel_encoder)  void intel_audio_codec_disable(struct intel_encoder
> > *intel_encoder)  {
> > struct drm_encoder *encoder = _encoder->base;
> > +   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > struct drm_device *dev = encoder->dev;
> > struct 

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

[Ville Syrjälä]

On Fri, Aug 05, 2016 at 05:39:19AM +, Yang, Libin wrote:
> Hi Ville,
> 
> Sorry for delay reply. Please see my comments below.
> 
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Thursday, August 4, 2016 4:53 PM
> > To: libin.y...@linux.intel.com
> > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, 
> > Daniel
> > ; ti...@suse.de; Yang, Libin 
> > Subject: Re: [PATCH v3 1/3] drm/i915: set proper N/M in modeset
> > 
> > On Thu, Aug 04, 2016 at 03:58:02PM +0800, libin.y...@linux.intel.com wrote:
> > > From: Libin Yang 
> > >
> > > When modeset occurs and the LS_CLK is set to some special values in DP
> > > mode, the N/M need to be set manually if audio is playing. Otherwise
> > > the first several seconds may be silent in audio playback.
> > >
> > > The relationship of Maud and Naud is expressed in the following
> > > equation:
> > > Maud/Naud = 512 * fs / f_LS_Clk
> > >
> > > Please refer VESA DisplayPort Standard spec for details.
> > 
> > Pleas include a small changelog here so that I know what has changed with
> > each revision of the patch. Eg:
> > 
> > v2: blah
> > v3: whatever
> > 
> > >
> > > Signed-off-by: Libin Yang 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h|   6 ++
> > >  drivers/gpu/drm/i915/intel_audio.c | 133
> > > -
> > >  2 files changed, 123 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 8bfde75..2f9d00e 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7351,6 +7351,12 @@ enum {
> > >  #define _HSW_AUD_CONFIG_B0x65100
> > >  #define HSW_AUD_CFG(pipe)_MMIO_PIPE(pipe,
> > _HSW_AUD_CONFIG_A, _HSW_AUD_CONFIG_B)
> > >
> > > +#define _HSW_AUD_M_CTS_ENABLE_A  0x65028
> > > +#define _HSW_AUD_M_CTS_ENABLE_B  0x65128
> > > +#define HSW_AUD_M_CTS_ENABLE(pipe)   _MMIO_PIPE(pipe,
> > _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> > > +#define   AUD_M_CTS_M_VALUE_INDEX(1 << 21)
> > > +#define   AUD_M_CTS_M_PROG_ENABLE(1 << 20)
> > 
> > Please try to keep the register defines in order by the register offset.
> > Ie. these registers should be placed just after HSW_AUD_MISC_CTRL.
> > 
> > > +
> > >  #define _HSW_AUD_MISC_CTRL_A 0x65010
> > >  #define _HSW_AUD_MISC_CTRL_B 0x65110
> > >  #define HSW_AUD_MISC_CTRL(pipe)  _MMIO_PIPE(pipe,
> > _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 6700a7b..04e7358 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -98,6 +98,35 @@ static const struct {
> > >   { 192000, TMDS_297M, 20480, 247500 },  };
> > >
> > > +#define LC_540M 54
> > > +#define LC_270M 27
> > > +#define LC_162M 162000
> > > +static const struct {
> > > + int sample_rate;
> > > + int clock;
> > > + u16 n;
> > > + u16 m;
> > > +} aud_nm[] = {
> > > + {192000, LC_540M, 5625, 1024},
> >  ^  ^
> > 
> > Style nit: please add spaces here
> > 
> > > + {96000, LC_540M, 5625, 512},
> > > + {88200, LC_540M, 9375, 784},
> > > + {48000, LC_540M, 5625, 256},
> > > + {44100, LC_540M, 9375, 392},
> > > + {32000, LC_540M, 16875, 512},
> > > + {192000, LC_270M, 5625, 2048},
> > > + {96000, LC_270M, 5625, 1024},
> > > + {88200, LC_270M, 9375, 1568},
> > > + {48000, LC_270M, 5625, 512},
> > > + {44100, LC_270M, 9375, 784},
> > > + {32000, LC_270M, 16875, 1024},
> > > + {192000, LC_162M, 3375, 2048},
> > > + {96000, LC_162M, 3375, 1024},
> > > + {88200, LC_162M, 5625, 1568},
> > > + {48000, LC_162M, 3375, 512},
> > > + {44100, LC_162M, 5625, 784},
> > > + {32000, LC_162M, 10125, 1024},
> > 
> > The numbers looks good. But looks like you forgot about 176.4 kHz?
> > 
> > > +};
> > > +
> > >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */  static u32
> > > audio_config_hdmi_pixel_clock(const struct drm_display_mode
> > > *adjusted_mode)  { @@ -121,20 +150,50 @@ static u32
> > > audio_config_hdmi_pixel_clock(const struct drm_display_mode *adjusted
> > >   return hdmi_audio_clock[i].config;
> > >  }
> > >
> > > -static int audio_config_get_n(const struct drm_display_mode *mode,
> > > int rate)
> > > +static int audio_config_get_n(struct intel_crtc *crtc,
> > > +   const struct drm_display_mode *adjusted_mode,
> > > +   int rate)
> > >  {
> > >   int i;
> > >
> > > - for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > > - if ((rate == aud_ncts[i].sample_rate) &&
> > > - (mode->clock == aud_ncts[i].clock)) {
> > > - return aud_ncts[i].n;
> > > + if 

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/19] drm/i915: Introduce i915_gem_active_wait_unlocked()

[Patchwork]

== Series Details ==

Series: series starting with [01/19] drm/i915: Introduce 
i915_gem_active_wait_unlocked()
URL   : https://patchwork.freedesktop.org/series/10686/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-hsw-i7-4770k)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-bdw-i7-5600u)
fail   -> PASS   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-hsw-i7-4770r)

fi-hsw-i7-4770k  total:240  pass:218  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-qkkr  total:240  pass:181  dwarn:29  dfail:0   fail:4   skip:26 
fi-skl-i7-6700k  total:240  pass:204  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:240  pass:198  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:5   dfail:0   fail:0   skip:16 
ro-bdw-i7-5557U  total:240  pass:223  dwarn:1   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:240  pass:205  dwarn:1   dfail:0   fail:2   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:213  dwarn:0   dfail:0   fail:1   skip:26 
ro-ilk-i7-620lm  total:240  pass:172  dwarn:1   dfail:0   fail:2   skip:65 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:221  dwarn:1   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:198  dwarn:0   dfail:0   fail:1   skip:41 
fi-skl-i5-6260u failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1719/

deedff0 drm-intel-nightly: 2016y-08m-04d-23h-50m-15s UTC integration manifest
d1497c5 drm/i915: Assert that the request hasn't been retired
ebf04c1 drm/i915: Repack fence tiling mode and stride into a single integer
ec0049e drm/i915: Document and reject invalid tiling modes
c58f587 drm/i915: Remove locking for get_tiling
95c8415 drm/i915: Remove pinned check from madvise ioctl
4aa445e drm/i915: Reduce locking inside swfinish ioctl
e835356 drm/i915: Remove (struct_mutex) locking for busy-ioctl
35ce145 drm/i915: Remove (struct_mutex) locking for wait-ioctl
caf0112 drm/i915: Do a nonblocking wait first in pread/pwrite
bd39eb1 drm/i915: Remove unused no-shrinker-steal
7d887c9 drm/i915: Tidy generation of the GTT mmap offset
8bdc98a drm/i915/shrinker: Wait before acquiring struct_mutex under oom
5a8779e drm/i915: Simplify do_idling() (Ironlake vt-d w/a)
07185f4 drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex
90e9a7f drm/i915: Remove forced stop ring on suspend/unload
bbb5820 drm/i915/userptr: Remove superfluous interruptible=false on waiting
6837af5 drm/i915: Convert non-blocking userptr waits for requests over to using 
RCU
80f0ac3 drm/i915: Convert non-blocking waits for requests over to using RCU
1d13908 drm/i915: Introduce i915_gem_active_wait_unlocked()

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

Re: [Intel-gfx] [PATCH 05/19] drm/i915: Remove forced stop ring on suspend/unload

[Joonas Lahtinen]

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote:
> Before suspending (or unloading), we would first wait upon all rendering
> to be completed and then disable the rings. This later step is a remanent
> from DRI1 days when we did not use request tracking for all operations
> upon the ring. Now that we are sure we are waiting upon the very last
> operation by the engine, we can forgo clobbering the ring registers,
> though we do keep the assert that the engine is indeed idle before
> sleeping.
> 
> Signed-off-by: Chris Wilson 

Could use thorough testing again.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: set proper N/MCTS on more platforms

[Yang, Libin]

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, August 4, 2016 4:54 PM
> To: libin.y...@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, 
> Daniel
> ; ti...@suse.de; Yang, Libin 
> Subject: Re: [PATCH v3 2/3] drm/i915: set proper N/MCTS on more platforms
> 
> On Thu, Aug 04, 2016 at 03:58:03PM +0800, libin.y...@linux.intel.com wrote:
> > From: Libin Yang 
> >
> > This patch applies setting proper N/M, N/CTS on more platforms.
> >
> > Signed-off-by: Libin Yang 
> 
> Reviewed-by: Ville Syrjälä 
> 
> Not that I particularly like this special casing of platforms. We should 
> really try
> to unify this across the board, and I thought we already agreed that that was
> going to happen?

Yes, and based on the spec, even it is not supporting 4K resolution,
the n/mcts should also be OK. It is for clock, not for resolution.
So I agree to apply the patches to other platforms.

Regards,
Libin

> 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 04e7358..7aa0203 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -732,11 +732,7 @@ static int
> i915_audio_component_sync_audio_rate(struct device *dev,
> > int n;
> > int err = 0;
> >
> > -   /* HSW, BDW, SKL, KBL need this fix */
> > -   if (!IS_SKYLAKE(dev_priv) &&
> > -   !IS_KABYLAKE(dev_priv) &&
> > -   !IS_BROADWELL(dev_priv) &&
> > -   !IS_HASWELL(dev_priv))
> > +   if (!HAS_DDI(dev_priv))
> > return 0;
> >
> > mutex_lock(_priv->av_mutex);
> > --
> > 1.9.1
> 
> --
> 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 02/19] drm/i915: Convert non-blocking waits for requests over to using RCU

[Joonas Lahtinen]

On to, 2016-08-04 at 20:52 +0100, Chris Wilson wrote:
> We can completely avoid taking the struct_mutex around the non-blocking
> waits by switching over to the RCU request management (trading the mutex
> for a RCU read lock and some complex atomic operations). The improvement
> is that we gain further contention reduction, and overall the code
> become simpler due to the reduced mutex dancing.
> 
> v2: Move i915_gem_fault tracepoint to start of function, before the
> unlocked wait.

"Move i915_gem_fault tracepoint *back* to start of ..." to be exact :)

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

[Yang, Libin]

Hi Ville,

Sorry for delay reply. Please see my comments below.

> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, August 4, 2016 4:53 PM
> To: libin.y...@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Vetter, 
> Daniel
> ; ti...@suse.de; Yang, Libin 
> Subject: Re: [PATCH v3 1/3] drm/i915: set proper N/M in modeset
> 
> On Thu, Aug 04, 2016 at 03:58:02PM +0800, libin.y...@linux.intel.com wrote:
> > From: Libin Yang 
> >
> > When modeset occurs and the LS_CLK is set to some special values in DP
> > mode, the N/M need to be set manually if audio is playing. Otherwise
> > the first several seconds may be silent in audio playback.
> >
> > The relationship of Maud and Naud is expressed in the following
> > equation:
> > Maud/Naud = 512 * fs / f_LS_Clk
> >
> > Please refer VESA DisplayPort Standard spec for details.
> 
> Pleas include a small changelog here so that I know what has changed with
> each revision of the patch. Eg:
> 
> v2: blah
> v3: whatever
> 
> >
> > Signed-off-by: Libin Yang 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h|   6 ++
> >  drivers/gpu/drm/i915/intel_audio.c | 133
> > -
> >  2 files changed, 123 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 8bfde75..2f9d00e 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7351,6 +7351,12 @@ enum {
> >  #define _HSW_AUD_CONFIG_B  0x65100
> >  #define HSW_AUD_CFG(pipe)  _MMIO_PIPE(pipe,
> _HSW_AUD_CONFIG_A, _HSW_AUD_CONFIG_B)
> >
> > +#define _HSW_AUD_M_CTS_ENABLE_A0x65028
> > +#define _HSW_AUD_M_CTS_ENABLE_B0x65128
> > +#define HSW_AUD_M_CTS_ENABLE(pipe) _MMIO_PIPE(pipe,
> _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> > +#define   AUD_M_CTS_M_VALUE_INDEX  (1 << 21)
> > +#define   AUD_M_CTS_M_PROG_ENABLE  (1 << 20)
> 
> Please try to keep the register defines in order by the register offset.
> Ie. these registers should be placed just after HSW_AUD_MISC_CTRL.
> 
> > +
> >  #define _HSW_AUD_MISC_CTRL_A   0x65010
> >  #define _HSW_AUD_MISC_CTRL_B   0x65110
> >  #define HSW_AUD_MISC_CTRL(pipe)_MMIO_PIPE(pipe,
> _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 6700a7b..04e7358 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -98,6 +98,35 @@ static const struct {
> > { 192000, TMDS_297M, 20480, 247500 },  };
> >
> > +#define LC_540M 54
> > +#define LC_270M 27
> > +#define LC_162M 162000
> > +static const struct {
> > +   int sample_rate;
> > +   int clock;
> > +   u16 n;
> > +   u16 m;
> > +} aud_nm[] = {
> > +   {192000, LC_540M, 5625, 1024},
>  ^  ^
> 
> Style nit: please add spaces here
> 
> > +   {96000, LC_540M, 5625, 512},
> > +   {88200, LC_540M, 9375, 784},
> > +   {48000, LC_540M, 5625, 256},
> > +   {44100, LC_540M, 9375, 392},
> > +   {32000, LC_540M, 16875, 512},
> > +   {192000, LC_270M, 5625, 2048},
> > +   {96000, LC_270M, 5625, 1024},
> > +   {88200, LC_270M, 9375, 1568},
> > +   {48000, LC_270M, 5625, 512},
> > +   {44100, LC_270M, 9375, 784},
> > +   {32000, LC_270M, 16875, 1024},
> > +   {192000, LC_162M, 3375, 2048},
> > +   {96000, LC_162M, 3375, 1024},
> > +   {88200, LC_162M, 5625, 1568},
> > +   {48000, LC_162M, 3375, 512},
> > +   {44100, LC_162M, 5625, 784},
> > +   {32000, LC_162M, 10125, 1024},
> 
> The numbers looks good. But looks like you forgot about 176.4 kHz?
> 
> > +};
> > +
> >  /* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */  static u32
> > audio_config_hdmi_pixel_clock(const struct drm_display_mode
> > *adjusted_mode)  { @@ -121,20 +150,50 @@ static u32
> > audio_config_hdmi_pixel_clock(const struct drm_display_mode *adjusted
> > return hdmi_audio_clock[i].config;
> >  }
> >
> > -static int audio_config_get_n(const struct drm_display_mode *mode,
> > int rate)
> > +static int audio_config_get_n(struct intel_crtc *crtc,
> > + const struct drm_display_mode *adjusted_mode,
> > + int rate)
> >  {
> > int i;
> >
> > -   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > -   if ((rate == aud_ncts[i].sample_rate) &&
> > -   (mode->clock == aud_ncts[i].clock)) {
> > -   return aud_ncts[i].n;
> > +   if (intel_crtc_has_type(crtc->config, INTEL_OUTPUT_HDMI)) {
> > +   for (i = 0; i < ARRAY_SIZE(aud_ncts); i++) {
> > +   if ((rate == aud_ncts[i].sample_rate) &&
> > +   (adjusted_mode->clock == aud_ncts[i].clock)) {
> 
> Indent fail, and a bit 

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: Bring MIPI out of reset

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Bring MIPI out of reset
URL   : https://patchwork.freedesktop.org/series/10682/
State : failure

== Summary ==

Applying: drm/i915/bxt: Bring MIPI out of reset
fatal: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/bxt: Bring MIPI out of reset
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

[Sharma, Shashank]

Regards

Shashank


On 8/4/2016 9:39 PM, Daniel Vetter wrote:

On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:

On 4 August 2016 at 14:15, Sharma, Shashank  wrote:

On 8/4/2016 5:04 PM, Emil Velikov wrote:

On 4 August 2016 at 11:16, Sharma, Shashank 
wrote:

Hello Emil,

Thanks for your time.

I have got mixed opinion on this.

IMHO we should expose them to userspace too, as UI agents like Hardware
composer/X/Wayland must know what does these

flags means, so that they can display them on the end user screen (like
settings menu)

But few people even think thats its too complex to be exposed to
userspace
agents.


If we want these/such flags passed between kernel and user space one must:
   - Provide a kernel interface how to do that
   - Provide a userspace (acked by respective developers/maintainers)
that the approach is sane and proves useful.

Since the above can take some time, I'd suggest dropping those from
the UAPI header(s)... for now.

-Emil

Please guide me a bit more on this problem, Emil, Daniel.
The reason why I want to pass this to userspace is, so that, HWC/X/any other
UI manager, can send a modeset
which is accurate upto aspect ratio.


Nobody(?) is arguing that you don't to pass such information to/from
userspace :-)
Your series does the internal parsing/management of the attribute and
has no actual UAPI implementation and/or userspace references (to
code/discussions). Thus the UAPI changes should _not_ be part of these
patches.

Daniel's blog [1] has many educational materials why and how things
are done upstream. I would kindly invite you to give them (another?)
courtesy read.

It reuses the already existing uapi mode structure. And since it extends
them both on the probe side and on the modeset set this means userspace
can just pass through the right probed mode and it'll all magically work.
At least that's the idea.

Now if you actually care about the different bits then you can select the
right mode, but that's about it. So if you want to compensate for the
non-square pixels in rendering then you need to look at it, but otherwise
it's just a case of select the mode you want. I don't see what new
userspace we'd need for that really, current one should all work nicely
as-is. At least the entire point of doing this was seamless support with
existing userspace.
-Daniel

Thanks Daniel, you explained the zest of this series better than me :)

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Yang, Libin]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Dhinakaran Pandiyan
> Sent: Wednesday, August 3, 2016 10:15 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: alsa-de...@alsa-project.org; ti...@suse.de; libin.y...@linux.intel.com;
> Pandiyan, Dhinakaran 
> Subject: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST
> 
> DP MST provides the capability to send multiple video and audio streams via
> one single port. This requires the API's between i915 and audio drivers to
> distinguish between audio capable displays connected to a port. This patch
> adds this support via an additional parameter 'int dev_id'. The existing
> parameter 'port' does not change it's meaning.
> 
> dev_id =
>   MST : pipe that the stream originates from
>   Non-MST : -1
> 
> Affected APIs:
> struct i915_audio_component_ops
> -   int (*sync_audio_rate)(struct device *, int port, int rate);
> + int (*sync_audio_rate)(struct device *, int port, int dev_id,
> +  int rate);
> 
> -   int (*get_eld)(struct device *, int port, bool *enabled,
> -   unsigned char *buf, int max_bytes);
> +   int (*get_eld)(struct device *, int port, int dev_id,
> +bool *enabled, unsigned char *buf, int max_bytes);
> 
> struct i915_audio_component_audio_ops
> -   void (*pin_eld_notify)(void *audio_ptr, int port);
> +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> 
> This patch makes dummy changes in the audio drivers for build to succeed.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 +-
>  drivers/gpu/drm/i915/intel_audio.c | 82 +--
> ---
>  include/drm/i915_component.h   |  6 +--
>  include/sound/hda_i915.h   | 11 ++---
>  sound/hda/hdac_i915.c  |  9 +++--
>  sound/pci/hda/patch_hdmi.c |  7 ++--
>  6 files changed, 82 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 65ada5d..8e4c8c8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2054,7 +2054,7 @@ struct drm_i915_private {
>   /* perform PHY state sanity checks? */
>   bool chv_phy_assert[2];
> 
> - struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> + struct intel_encoder *av_enc_map[I915_MAX_PIPES];

We may still need save the port number info.
In non-MST mode, device entry means nothing. This means
av_enc_map[pipe] may not get the right intel_encoder

Regards,
Libin

> 
>   /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your
> patch diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 8c493de..cbe44c8 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -500,6 +500,9 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder)
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_dig_port->port;
> + enum pipe pipe = crtc->pipe;
> + int dev_id = -1;
> +
> 
>   connector = drm_select_eld(encoder);
>   if (!connector)
> @@ -522,14 +525,19 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder)
>   dev_priv->display.audio_codec_enable(connector,
> intel_encoder,
>adjusted_mode);
> 
> + if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> + dev_id = pipe;
> +
>   mutex_lock(_priv->av_mutex);
>   intel_encoder->audio_connector = connector;
> +
>   /* referred in audio callbacks */
> - dev_priv->dig_port_map[port] = intel_encoder;
> + dev_priv->av_enc_map[pipe] = intel_encoder;
>   mutex_unlock(_priv->av_mutex);
> 
>   if (acomp && acomp->audio_ops && acomp->audio_ops-
> >pin_eld_notify)
> - acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> >audio_ptr, (int) port);
> + acomp->audio_ops->pin_eld_notify(acomp->audio_ops-
> >audio_ptr,
> +  (int) port, dev_id);
>  }
> 
>  /**
> @@ -542,22 +550,29 @@ void intel_audio_codec_enable(struct intel_encoder
> *intel_encoder)  void intel_audio_codec_disable(struct intel_encoder
> *intel_encoder)  {
>   struct drm_encoder *encoder = _encoder->base;
> + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>   struct drm_device *dev = encoder->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct i915_audio_component *acomp = dev_priv->audio_component;
>   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
>   enum port port = intel_dig_port->port;
> + enum pipe pipe = crtc->pipe;
> 

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Yang, Libin]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Ville Syrjälä
> Sent: Friday, August 5, 2016 4:48 AM
> To: Takashi Iwai 
> Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; alsa-
> de...@alsa-project.org; Pandiyan, Dhinakaran
> 
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST
> 
> On Thu, Aug 04, 2016 at 07:55:09PM +0200, Takashi Iwai wrote:
> > On Thu, 04 Aug 2016 19:35:16 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote:
> > > > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > DP MST provides the capability to send multiple video and
> > > > > > audio streams via one single port. This requires the API's
> > > > > > between i915 and audio drivers to distinguish between audio
> > > > > > capable displays connected to a port. This patch adds this
> > > > > > support via an additional parameter 'int dev_id'. The existing
> parameter 'port' does not change it's meaning.
> > > > > >
> > > > > > dev_id =
> > > > > > MST : pipe that the stream originates from
> > > > > > Non-MST : -1
> > > > > >
> > > > > > Affected APIs:
> > > > > > struct i915_audio_component_ops
> > > > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > > > +   int (*sync_audio_rate)(struct device *, int port, int
> > > > > > +dev_id,
> > > > >
> > > > > Does the term 'dev_id' have some special meaning on the audio
> > > > > side? On the i915 side things would be less confusing if we just
> > > > > called it 'pipe'.
> > > >
> > > > Yeah, it does.  All of the documentation on the audio side is
> > > > written in terms of device ID, so they asked for that nomenclature.
> > >
> > > And is the device ID always the same as the pipe? Until now we've
> > > made due with passing the port instead of the pipe, so either the
> > > audio side didn't use the device ID, or its meaning changes based on
> > > how we drive things, or they dug it out from somewhere else based on the
> port?
> >
> > This is my concern, too.  Currently we have a very wild assumption
> > even for the port mapping.  In the audio side, there is neither port
> > nor pipe.  There are only the widget node id and the device id.  The
> > former is supposedly corresponding to the port, and the latter to the
> > pipe.  But the audio side has absolutely no clue about how these are
> > connected.
> 
> So I tried to study this a bit, and MST and device are mentioned a few
> times in the description of some audio registers in the GPU docs. Looks like a
> bunch of bits overlap somehow with pin vs. device usage. I don't understand
> how that's supposed to work. Eg:

For SST & HDMI, port is mapping to pin.

For MST, in audio, each pin has several device entries. Each device entry
can transfer audio stream. And we confirmed with silicon team,
device entry is related to pipe.

Device entry is always the right concept in audio driver. We are not sure
the relationship will be always right between pipe and device entry.

We are worry that the relationship may be changed in the future between
pipe and device entry. I mean maybe the pipe is not related to device
entry in the new platforms, but some other conception, such as transcoder.
If so, if we are using pipe now, maybe we need change the API again.
For the stability, we are thinking device entry is suitable.

I think your concern is right. It is not good to use audio conception 
in gfx driver, which will cause confusion. If we can confirm that
pipe will always be the fixed mapping to device entry, it will be
better to use pipe.

>  AUD_PWRSTAUD_PWRST
>  1:0   PinB Widget PwrSt Set
>  PinB Widget power state that was setFor DP MST this represents Device1
> power state

For this register, it means different in different scenario:
In DP SST & HDMI, it is for PinB
In DP MST, it is for device entry 1 (on whichever pin). 

> 
> It's anyone's guees what those bits are suppoosed to reflect when you're doing
> MST with device1/pipe A, and at the same time you're driving port B in
> HDMI/SST mode.

I did the similar test before. I remember (but I didn't remember clearly now)
If one pin is used as DP MST, all the pins are used as DP MST. This means if
PinB is used as DP MST, 1:0 represents Device 1 and 5:4 represents Device 2.
Let's say PinC is connected to HDMI audio, it is now looked as Device 2 (or
other device id) not as PinC audio.

Regards,
Libin

> 
> Anyways, it doesn't help that this whole device widget aspect of hda seems to
> be undocumented. No spec I've found seems to know anything about any
> device widgets, and yet those are how MST rolls apparently.
> 
> In conclusion, I'd say that consistency's sake we should use either
> dev+pin or pipe+port in the interface, not mix both. In case of pin I
> 

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

[Matt Roper]

On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> Reviewed-by: Lyude 

Merged to dinq.  Thanks for the quick review.


Matt

> 
> On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote:
> > The bspec was updated a couple weeks ago to add an extra block per
> > line
> > to plane watermark calculations for linear pixel formats.
> > 
> > Bspec update 115327 description:
> >   "Gen9+ - Updated the plane blocks per line calculation for linear
> >   cases. Adds +1 for all linear cases to handle the non-block aligned
> >   stride cases."
> > 
> > Cc: Lyude 
> > Signed-off-by: Matt Roper 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 4317cdf..6bd352a 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t
> > pixel_rate, uint32_t pipe_htotal,
> >     plane_bytes_per_line *= 4;
> >     plane_blocks_per_line =
> > DIV_ROUND_UP(plane_bytes_per_line, 512);
> >     plane_blocks_per_line /= 4;
> > +   } else if (tiling == DRM_FORMAT_MOD_NONE) {
> > +   plane_blocks_per_line =
> > DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
> >     } else {
> >     plane_blocks_per_line =
> > DIV_ROUND_UP(plane_bytes_per_line, 512);
> >     }
> -- 
> Cheers,
>   Lyude

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
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: Fix enc_to_dig_port for MST encoders

[Lyude]

There was some discussion that happened on the original version of this
patch:

https://patchwork.kernel.org/patch/8960831/

The general consensus was while this fixed the issue, it probably isn't
the way we want to fix it. It would be a better idea just to have
enc_to_mst_primary() or something along those lines, or just use
enc_to_mst()->primary explicitly.

On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> When a MST encoder is passed to enc_to_dig_port(), the container_of()
> macro
> does not return the digital port. Handle this by returning the member
> "primary" in "struct intel_dp_mst_encoder"
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_drv.h | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 45020d2..66af444 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1023,18 +1023,22 @@ intel_attached_encoder(struct drm_connector
> *connector)
>   return to_intel_connector(connector)->encoder;
>  }
>  
> -static inline struct intel_digital_port *
> -enc_to_dig_port(struct drm_encoder *encoder)
> -{
> - return container_of(encoder, struct intel_digital_port,
> base.base);
> -}
> -
>  static inline struct intel_dp_mst_encoder *
>  enc_to_mst(struct drm_encoder *encoder)
>  {
>   return container_of(encoder, struct intel_dp_mst_encoder,
> base.base);
>  }
>  
> +static inline struct intel_digital_port *
> +enc_to_dig_port(struct drm_encoder *encoder)
> +{
> + if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST)
> + return enc_to_mst(encoder)->primary;
> + else
> + return container_of(encoder, struct
> intel_digital_port,
> + base.base);
> +}
> +
>  static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder
> *encoder)
>  {
>   return _to_dig_port(encoder)->dp;
-- 
Cheers,
Lyude
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Move audio_connector to intel_encoder

[Lyude]

Reviewed-by: Lyude 

On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> With DP MST, a digital_port can carry more than one audio stream.
> Hence,
> more than one audio_connector needs to be attached to
> intel_digital_port in
> such cases. However, each stream is associated with an unique
> encoder. So,
> instead of creating an array of audio_connectors per port, move
> audio_connector from struct intel_digital_port to struct
> intel_encoder.
> This also simplifies access to the right audio_connector from codec
> functions in intel_audio.c that receive intel_encoder.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 10 --
>  drivers/gpu/drm/i915/intel_drv.h   |  4 ++--
>  2 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 6700a7b..8c493de 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -523,7 +523,7 @@ void intel_audio_codec_enable(struct
> intel_encoder *intel_encoder)
>    adjusted_mode);
>  
>   mutex_lock(_priv->av_mutex);
> - intel_dig_port->audio_connector = connector;
> + intel_encoder->audio_connector = connector;
>   /* referred in audio callbacks */
>   dev_priv->dig_port_map[port] = intel_encoder;
>   mutex_unlock(_priv->av_mutex);
> @@ -552,7 +552,7 @@ void intel_audio_codec_disable(struct
> intel_encoder *intel_encoder)
>   dev_priv-
> >display.audio_codec_disable(intel_encoder);
>  
>   mutex_lock(_priv->av_mutex);
> - intel_dig_port->audio_connector = NULL;
> + intel_encoder->audio_connector = NULL;
>   dev_priv->dig_port_map[port] = NULL;
>   mutex_unlock(_priv->av_mutex);
>  
> @@ -707,7 +707,6 @@ static int i915_audio_component_get_eld(struct
> device *dev, int port,
>  {
>   struct drm_i915_private *dev_priv = dev_to_i915(dev);
>   struct intel_encoder *intel_encoder;
> - struct intel_digital_port *intel_dig_port;
>   const u8 *eld;
>   int ret = -EINVAL;
>  
> @@ -716,10 +715,9 @@ static int i915_audio_component_get_eld(struct
> device *dev, int port,
>   /* intel_encoder might be NULL for DP MST */
>   if (intel_encoder) {
>   ret = 0;
> - intel_dig_port = enc_to_dig_port(_encoder-
> >base);
> - *enabled = intel_dig_port->audio_connector != NULL;
> + *enabled = intel_encoder->audio_connector != NULL;
>   if (*enabled) {
> - eld = intel_dig_port->audio_connector->eld;
> + eld = intel_encoder->audio_connector->eld;
>   ret = drm_eld_size(eld);
>   memcpy(buf, eld, min(max_bytes, ret));
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index f73de63c..45020d2 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -220,6 +220,8 @@ struct intel_encoder {
>   void (*suspend)(struct intel_encoder *);
>   int crtc_mask;
>   enum hpd_pin hpd_pin;
> + /* for communication with audio component; protected by
> av_mutex */
> + const struct drm_connector *audio_connector;
>  };
>  
>  struct intel_panel {
> @@ -929,8 +931,6 @@ struct intel_digital_port {
>   enum irqreturn (*hpd_pulse)(struct intel_digital_port *,
> bool);
>   bool release_cl2_override;
>   uint8_t max_lanes;
> - /* for communication with audio component; protected by
> av_mutex */
> - const struct drm_connector *audio_connector;
>  };
>  
>  struct intel_dp_mst_encoder {
-- 
Cheers,
Lyude
___
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: start adding dp mst audio

[Lyude]

This should be added after patch #3, since that's the one that fixes
enc_to_mst(). Otherwise:

Reviewed-by: Lyude 

On Tue, 2016-08-02 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> From: Libin Yang 
> 
> (This patch is developed by Dave Airlie 
> originally)
> 
> This patch adds support for DP MST audio in i915.
> 
> Enable audio codec when DP MST is enabled if has_audio flag is set.
> Disable audio codec when DP MST is disabled if has_audio flag is set.
> 
> Another separated patches to support DP MST audio will be implemented
> in audio driver.
> 
> Signed-off-by: Libin Yang 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
>  drivers/gpu/drm/i915/intel_ddi.c| 20 +++-
>  drivers/gpu/drm/i915/intel_dp_mst.c | 21 +
>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
>  4 files changed, 56 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 531ca02..56e38b1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2961,6 +2961,20 @@ static void intel_dp_info(struct seq_file *m,
>   intel_panel_info(m, _connector->panel);
>  }
>  
> +static void intel_dp_mst_info(struct seq_file *m,
> +   struct intel_connector *intel_connector)
> +{
> + struct intel_encoder *intel_encoder = intel_connector-
> >encoder;
> + struct intel_dp_mst_encoder *intel_mst =
> + enc_to_mst(_encoder->base);
> + struct intel_digital_port *intel_dig_port = intel_mst-
> >primary;
> + struct intel_dp *intel_dp = _dig_port->dp;
> + bool has_audio = drm_dp_mst_port_has_audio(_dp-
> >mst_mgr,
> + intel_connector->port);
> +
> + seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
> +}
> +
>  static void intel_hdmi_info(struct seq_file *m,
>   struct intel_connector *intel_connector)
>  {
> @@ -3003,7 +3017,10 @@ static void intel_connector_info(struct
> seq_file *m,
>   switch (connector->connector_type) {
>   case DRM_MODE_CONNECTOR_DisplayPort:
>   case DRM_MODE_CONNECTOR_eDP:
> - intel_dp_info(m, intel_connector);
> + if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> + intel_dp_mst_info(m, intel_connector);
> + else
> + intel_dp_info(m, intel_connector);
>   break;
>   case DRM_MODE_CONNECTOR_LVDS:
>   if (intel_encoder->type == INTEL_OUTPUT_LVDS)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index dd1d6fe..cbb4e7a 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2154,6 +2154,19 @@ void intel_ddi_fdi_disable(struct drm_crtc
> *crtc)
>   I915_WRITE(FDI_RX_CTL(PIPE_A), val);
>  }
>  
> +bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
> +  struct intel_crtc *intel_crtc)
> +{
> + u32 temp;
> +
> + if (intel_display_power_is_enabled(dev_priv,
> POWER_DOMAIN_AUDIO)) {
> + temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> + if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> + return true;
> + }
> + return false;
> +}
> +
>  void intel_ddi_get_config(struct intel_encoder *encoder,
>     struct intel_crtc_state *pipe_config)
>  {
> @@ -2219,11 +2232,8 @@ void intel_ddi_get_config(struct intel_encoder
> *encoder,
>   break;
>   }
>  
> - if (intel_display_power_is_enabled(dev_priv,
> POWER_DOMAIN_AUDIO)) {
> - temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
> - if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
> - pipe_config->has_audio = true;
> - }
> + pipe_config->has_audio =
> + intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
>  
>   if (encoder->type == INTEL_OUTPUT_EDP && dev_priv-
> >vbt.edp.bpp &&
>   pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 68a005d..84dbb50 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -76,6 +76,8 @@ static bool intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>   return false;
>   }
>  
> + if (drm_dp_mst_port_has_audio(_dp->mst_mgr, found-
> >port))
> + pipe_config->has_audio = true;
>   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock,
> bpp);
>  
>   pipe_config->pbn = mst_pbn;
> @@ -97,6 +99,10 @@ static void intel_mst_disable_dp(struct
> intel_encoder *encoder)
>   struct intel_dp_mst_encoder *intel_mst =
> enc_to_mst(>base);
>   struct intel_digital_port *intel_dig_port = intel_mst-

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

[Lyude]

Reviewed-by: Lyude 

On Thu, 2016-08-04 at 14:08 -0700, Matt Roper wrote:
> The bspec was updated a couple weeks ago to add an extra block per
> line
> to plane watermark calculations for linear pixel formats.
> 
> Bspec update 115327 description:
>   "Gen9+ - Updated the plane blocks per line calculation for linear
>   cases. Adds +1 for all linear cases to handle the non-block aligned
>   stride cases."
> 
> Cc: Lyude 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 4317cdf..6bd352a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t
> pixel_rate, uint32_t pipe_htotal,
>   plane_bytes_per_line *= 4;
>   plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line, 512);
>   plane_blocks_per_line /= 4;
> + } else if (tiling == DRM_FORMAT_MOD_NONE) {
> + plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line, 512) + 1;
>   } else {
>   plane_blocks_per_line =
> DIV_ROUND_UP(plane_bytes_per_line, 512);
>   }
-- 
Cheers,
Lyude
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gen9: Give one extra block per line for SKL plane WM calculations

[Matt Roper]

The bspec was updated a couple weeks ago to add an extra block per line
to plane watermark calculations for linear pixel formats.

Bspec update 115327 description:
  "Gen9+ - Updated the plane blocks per line calculation for linear
  cases. Adds +1 for all linear cases to handle the non-block aligned
  stride cases."

Cc: Lyude 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4317cdf..6bd352a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3352,6 +3352,8 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate, 
uint32_t pipe_htotal,
plane_bytes_per_line *= 4;
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
plane_blocks_per_line /= 4;
+   } else if (tiling == DRM_FORMAT_MOD_NONE) {
+   plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512) 
+ 1;
} else {
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
}
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

[Takashi Iwai]

[dropped stable ML and add a few other relevant people to Cc]

On Thu, 04 Aug 2016 20:05:27 +0200,
Takashi Iwai wrote:
> 
> On Thu, 04 Aug 2016 18:44:11 +0200,
> Daniel Vetter wrote:
> > 
> > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote:
> > > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display
> > > power well and so the sna-hda audio codec acquires the display power
> > > well while it is operational. However, Skylake separates the powerwells
> > > again, but yet we still need the audio powerwell to setup the registers.
> > > (But then the hardware uses those registers even while powered off???)
> > 
> > Yeah feels fishy, but will at least duct-tape over the breakage from the
> > audio side. Most likely the reg writes go exactly nowhere and there's a
> > bug on the audio side. And this patch doesn't fix that.
> 
> Well, if the relevant code paths are only over these callbacks, I
> guess the following fix would work instead.
> 
> Can anyone check?

Scratch the previous one.  There is another place calling similarly.

Now looking back at the code again, I believe that the better way
would be to properly do power up / down at the resume callbacks.

Below is an untested patch.  Let me know if this actually works.


thanks,

Takashi

-- 8< --
From: Takashi Iwai 
Subject: [PATCH] ALSA: hda - Manage power well properly for resume

For SKL and later Intel chips, we control the power well per codec
basis via link_power callback since the commit [03b135cebc47: ALSA:
hda - remove dependency on i915 power well for SKL].
However, there are a few exceptional cases where the gfx registers are
accessed from the audio driver: namely the wakeup override bit
toggling at (both system and runtime) resume.  This seems causing a
kernel warning when accessed during the power well down (and likely
resulting in the bogus register accesses).

This patch puts the proper power up / down sequence around the resume
code so that the wakeup bit is fiddled properly while the power is
up.  (The other callback, sync_audio_rate, is used only in the PCM
callback, so it's guaranteed in the power-on.)

Also, by this proper power up/down, the instantaneous flip of wakeup
bit in the resume callback that was introduced by the commit
[033ea349a7cd: ALSA: hda - Fix Skylake codec timeout] becomes
superfluous, as snd_hdac_display_power() already does it.  So we can
clean it up together.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214
Fixes: 03b135cebc47 ('ALSA: hda - remove dependency on i915 power well for SKL')
Signed-off-by: Takashi Iwai 
---
 sound/pci/hda/hda_intel.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 89dacf9b4e6c..160c7f713722 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -906,20 +906,23 @@ static int azx_resume(struct device *dev)
struct snd_card *card = dev_get_drvdata(dev);
struct azx *chip;
struct hda_intel *hda;
+   struct hdac_bus *bus;
 
if (!card)
return 0;
 
chip = card->private_data;
hda = container_of(chip, struct hda_intel, chip);
+   bus = azx_bus(chip);
if (chip->disabled || hda->init_failed || !chip->running)
return 0;
 
-   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL
-   && hda->need_i915_power) {
-   snd_hdac_display_power(azx_bus(chip), true);
-   snd_hdac_i915_set_bclk(azx_bus(chip));
+   if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
+   snd_hdac_display_power(bus, true);
+   if (hda->need_i915_power)
+   snd_hdac_i915_set_bclk(bus);
}
+
if (chip->msi)
if (pci_enable_msi(pci) < 0)
chip->msi = 0;
@@ -929,6 +932,11 @@ static int azx_resume(struct device *dev)
 
hda_intel_init_chip(chip, true);
 
+   /* power down again for link-controlled chips */
+   if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) &&
+   !hda->need_i915_power)
+   snd_hdac_display_power(bus, false);
+
snd_power_change_state(card, SNDRV_CTL_POWER_D0);
 
trace_azx_resume(chip);
@@ -1008,6 +1016,7 @@ static int azx_runtime_resume(struct device *dev)
 
chip = card->private_data;
hda = container_of(chip, struct hda_intel, chip);
+   bus = azx_bus(chip);
if (chip->disabled || hda->init_failed)
return 0;
 
@@ -1015,15 +1024,9 @@ static int azx_runtime_resume(struct device *dev)
return 0;
 
if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) {
-   bus = azx_bus(chip);
-   if (hda->need_i915_power) {
-   snd_hdac_display_power(bus, true);
+   snd_hdac_display_power(bus, true);
+   if (hda->need_i915_power)
   

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Ville Syrjälä]

On Thu, Aug 04, 2016 at 07:55:09PM +0200, Takashi Iwai wrote:
> On Thu, 04 Aug 2016 19:35:16 +0200,
> Ville Syrjälä wrote:
> > 
> > On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote:
> > > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > > DP MST provides the capability to send multiple video and audio 
> > > > > streams via
> > > > > one single port. This requires the API's between i915 and audio 
> > > > > drivers to
> > > > > distinguish between audio capable displays connected to a port. This 
> > > > > patch
> > > > > adds this support via an additional parameter 'int dev_id'. The 
> > > > > existing
> > > > > parameter 'port' does not change it's meaning.
> > > > > 
> > > > > dev_id =
> > > > >   MST : pipe that the stream originates from
> > > > >   Non-MST : -1
> > > > > 
> > > > > Affected APIs:
> > > > > struct i915_audio_component_ops
> > > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > > + int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > > > 
> > > > Does the term 'dev_id' have some special meaning on the audio side? On
> > > > the i915 side things would be less confusing if we just called it
> > > > 'pipe'.
> > > 
> > > Yeah, it does.  All of the documentation on the audio side is written
> > > in terms of device ID, so they asked for that nomenclature.
> > 
> > And is the device ID always the same as the pipe? Until now we've made
> > due with passing the port instead of the pipe, so either the audio side
> > didn't use the device ID, or its meaning changes based on how we drive
> > things, or they dug it out from somewhere else based on the port?
> 
> This is my concern, too.  Currently we have a very wild assumption
> even for the port mapping.  In the audio side, there is neither port
> nor pipe.  There are only the widget node id and the device id.  The
> former is supposedly corresponding to the port, and the latter to the
> pipe.  But the audio side has absolutely no clue about how these are
> connected.

So I tried to study this a bit, and MST and device are mentioned a few
times in the description of some audio registers in the GPU docs. Looks
like a bunch of bits overlap somehow with pin vs. device usage. I don't
understand how that's supposed to work. Eg:
 AUD_PWRSTAUD_PWRST
 1:0 PinB Widget PwrSt Set
 PinB Widget power state that was setFor DP MST this represents Device1
 power state

It's anyone's guees what those bits are suppoosed to reflect when you're
doing MST with device1/pipe A, and at the same time you're driving
port B in HDMI/SST mode.

Anyways, it doesn't help that this whole device widget aspect of hda
seems to be undocumented. No spec I've found seems to know anything
about any device widgets, and yet those are how MST rolls apparently.

In conclusion, I'd say that consistency's sake we should use either
dev+pin or pipe+port in the interface, not mix both. In case of
dev+pin I don't think we should use the NID (I'm assuming device
widgets have one too), but rather the index. i915 could then do
the mapping somethign like dev=pipe and pin=port-1, and then
snd-hda can do the idx<->nid conversion however it sees fit
(just use base_nid, or walk some per-type widget lists, or whatever).

That's assuming the widgets really are somehow ordered consistently so
we can index them like that. I also might have understtod everyhing I
read abou hda.

-- 
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 i-g-t] igt_kms: Use proper panning coordinates for legacy primary plane updates

[Matt Roper]

On Wed, Aug 03, 2016 at 10:35:15AM -0700, Bob Paauwe wrote:
> On Wed, 3 Aug 2016 09:15:41 -0700
> Matt Roper  wrote:
> 
> > A copy/paste error resulted in us using src_x for both the x and y
> > panning coordinates; make sure we use src_y instead for the appropriate
> > parameter.
> > 
> > Fixes: 0e29ce3265b ("igt_kms: Remove pan members from igt_plane, v2.")
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Matt Roper 
> 
> Reviewed-by: Bob Paauwe 

Merged; thanks for the review.


Matt

> 
> > ---
> >  lib/igt_kms.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > index 7d7a53c..ed91688 100644
> > --- a/lib/igt_kms.c
> > +++ b/lib/igt_kms.c
> > @@ -1937,13 +1937,13 @@ static int 
> > igt_primary_plane_commit_legacy(igt_plane_t *primary,
> > igt_output_name(output),
> > kmstest_pipe_name(pipe->pipe),
> > fb_id,
> > -   primary->src_x, primary->src_x,
> > +   primary->src_x, primary->src_y,
> > mode->hdisplay, mode->vdisplay);
> >  
> > ret = drmModeSetCrtc(display->drm_fd,
> >  crtc_id,
> >  fb_id,
> > -primary->src_x, primary->src_x,
> > +primary->src_x, primary->src_y,
> >  >id,
> >  1,
> >  mode);
> 
> 
> 
> -- 
> --
> Bob Paauwe  
> bob.j.paa...@intel.com
> IOTG / PED Software Organization
> Intel Corp.  Folsom, CA
> (916) 356-6193
> 

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Minor clean up related to link training function declarations

[Dhinakaran Pandiyan]

No functional change. Organizing the declarations for functions
implemented in intel_dp_link_training.c

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_drv.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b846623..c921c3a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1357,8 +1357,6 @@ bool intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 struct intel_connector *intel_connector);
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  const struct intel_crtc_state *pipe_config);
-void intel_dp_start_link_train(struct intel_dp *intel_dp);
-void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
 void intel_dp_encoder_reset(struct drm_encoder *encoder);
 void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
@@ -1412,6 +1410,10 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
return ~((1 << lane_count) - 1) & 0xf;
 }
 
+/* intel_dp_link_training.c */
+void intel_dp_start_link_train(struct intel_dp *intel_dp);
+void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+
 /* intel_dp_aux_backlight.c */
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 0/2] Improve logging for DP link training

[Dhinakaran Pandiyan]

We do not currently output enough information to help debugging DP link
training issues. For e.g., training pattern and link status information.
This series aims to correct that by adding debug messages that can help
developers.

v2: Rebased.
Removed patches that are unrelated and/or need more changes.
Addressed review comments from Jani and Chris.

Dhinakaran Pandiyan (2):
  drm/i915/dp: Add debug messages to print DP link training pattern
  drm/i915/dp: Dump DP link status when link training stages fail

 drivers/gpu/drm/i915/intel_dp.c   | 13 +++--
 drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++
 2 files changed, 18 insertions(+), 6 deletions(-)

-- 
2.5.0

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Dump DP link status when link training stages fail

[Dhinakaran Pandiyan]

A full dump of link status can be handy in debugging link training
failures. Let's add that to the debug messages when link training fails.

v2: Removing unrelated clean up (Jani)
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 60fb39c..0deebed 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -24,6 +24,15 @@
 #include "intel_drv.h"
 
 static void
+intel_dp_dump_link_status(const uint8_t link_status[DP_LINK_STATUS_SIZE])
+{
+
+   DRM_DEBUG_KMS("ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x 
adj_req0_1:0x%x adj_req2_3:0x%x",
+ link_status[0], link_status[1], link_status[2],
+ link_status[3], link_status[4], link_status[5]);
+}
+
+static void
 intel_get_adjust_train(struct intel_dp *intel_dp,
   const uint8_t link_status[DP_LINK_STATUS_SIZE])
 {
@@ -168,6 +177,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
++loop_tries;
if (loop_tries == 5) {
DRM_ERROR("too many full retries, give up\n");
+   intel_dp_dump_link_status(link_status);
break;
}
intel_dp_reset_link_train(intel_dp,
@@ -254,6 +264,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp 
*intel_dp)
 
if (cr_tries > 5) {
DRM_ERROR("failed to train DP, aborting\n");
+   intel_dp_dump_link_status(link_status);
break;
}
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Add debug messages to print DP link training pattern

[Dhinakaran Pandiyan]

Currently we do not print the training pattern used in any of the DP link
training stages. Including this piece of information in debug messages will
help debugging.

Also, use the wrapper intel_dp_program_link_training_pattern() in
intel_dp_enable_port() instead of implementing it.

v2: Downgraded log level from error to debug (Chris)

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 53d97f6..9a80628 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2548,6 +2548,10 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = to_i915(dev);
enum port port = intel_dig_port->port;
 
+   if (dp_train_pat & DP_TRAINING_PATTERN_MASK)
+   DRM_DEBUG_KMS("Using DP training pattern TPS%d\n",
+ dp_train_pat & DP_TRAINING_PATTERN_MASK);
+
if (HAS_DDI(dev)) {
uint32_t temp = I915_READ(DP_TP_CTL(port));
 
@@ -2589,7 +2593,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
*DP |= DP_LINK_TRAIN_PAT_2_CPT;
break;
case DP_TRAINING_PATTERN_3:
-   DRM_ERROR("DP training pattern 3 not supported\n");
+   DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
instead\n");
*DP |= DP_LINK_TRAIN_PAT_2_CPT;
break;
}
@@ -2614,7 +2618,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
if (IS_CHERRYVIEW(dev)) {
*DP |= DP_LINK_TRAIN_PAT_3_CHV;
} else {
-   DRM_ERROR("DP training pattern 3 not 
supported\n");
+   DRM_DEBUG_KMS("TPS3 not supported, using TPS2 
instead\n");
*DP |= DP_LINK_TRAIN_PAT_2;
}
break;
@@ -2630,11 +2634,8 @@ static void intel_dp_enable_port(struct intel_dp 
*intel_dp)
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
 
/* enable with pattern 1 (as per spec) */
-   _intel_dp_set_link_train(intel_dp, _dp->DP,
-DP_TRAINING_PATTERN_1);
 
-   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
-   POSTING_READ(intel_dp->output_reg);
+   intel_dp_program_link_training_pattern(intel_dp, DP_TRAINING_PATTERN_1);
 
/*
 * Magic for VLV/CHV. We _must_ first set up the register
-- 
2.5.0

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

[Intel-gfx] [PATCH 08/19] drm/i915/shrinker: Wait before acquiring struct_mutex under oom

[Chris Wilson]

We can now wait for the GPU (all engines) to become idle without
requiring the struct_mutex. Inside the shrinker, we need to currently
take the struct_mutex in order to purge objects and to purge the objects
we need the GPU to be idle - causing a stall whilst we hold the
struct_mutex. We can hide most of that stall by performing the wait
before taking the struct_mutex and only doing essential waits for
new rendering on objects to be freed.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 23d70376b104..9b92b6470ccc 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -323,17 +323,22 @@ i915_gem_shrinker_lock_uninterruptible(struct 
drm_i915_private *dev_priv,
   struct shrinker_lock_uninterruptible 
*slu,
   int timeout_ms)
 {
-   unsigned long timeout = msecs_to_jiffies(timeout_ms) + 1;
+   unsigned long timeout = jiffies + msecs_to_jiffies_timeout(timeout_ms);
+
+   do {
+   if (i915_gem_wait_for_idle(dev_priv, false) == 0 &&
+   i915_gem_shrinker_lock(_priv->drm, >unlock))
+   break;
 
-   while (!i915_gem_shrinker_lock(_priv->drm, >unlock)) {
schedule_timeout_killable(1);
if (fatal_signal_pending(current))
return false;
-   if (--timeout == 0) {
+
+   if (time_after(jiffies, timeout)) {
pr_err("Unable to lock GPU to purge memory.\n");
return false;
}
-   }
+   } while (1);
 
slu->was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
-- 
2.8.1

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

[Intel-gfx] [PATCH 06/19] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

[Chris Wilson]

The principal motivation for this was to try and eliminate the
struct_mutex from i915_gem_suspend - but we still need to hold the mutex
current for the i915_gem_context_lost(). (The issue there is that there
may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and
struct_mutex via the stop_machine().) For the moment, enabling last
request tracking for the engine, allows us to do busyness checking and
waiting without requiring the struct_mutex - which is useful in its own
right.

v2: Pass along "bool interruptible" as being unlocked we cannot rely on
i915->mm.interruptible being stable or even under our control.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c  | 33 +++-
 drivers/gpu/drm/i915/i915_gem_evict.c|  6 +++---
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_request.c  |  7 ---
 drivers/gpu/drm/i915/i915_gem_request.h  | 11 +++
 drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
 drivers/gpu/drm/i915/i915_irq.c  |  3 +--
 drivers/gpu/drm/i915/intel_engine_cs.c   |  8 +++-
 drivers/gpu/drm/i915/intel_pm.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 18 -
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 33 
 13 files changed, 68 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 24d63e271f4b..1faea382dfeb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4925,7 +4925,7 @@ i915_drop_caches_set(void *data, u64 val)
return ret;
 
if (val & DROP_ACTIVE) {
-   ret = i915_gem_wait_for_idle(dev_priv);
+   ret = i915_gem_wait_for_idle(dev_priv, true);
if (ret)
goto unlock;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index abdfb97096e2..6eff31202336 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3233,7 +3233,8 @@ int __must_check i915_gem_init(struct drm_device *dev);
 int __must_check i915_gem_init_hw(struct drm_device *dev);
 void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_engines(struct drm_device *dev);
-int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv);
+int __must_check i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
+   bool interruptible);
 int __must_check i915_gem_suspend(struct drm_device *dev);
 void i915_gem_resume(struct drm_device *dev);
 int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8946c52e09fb..0872de359bd7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2438,13 +2438,18 @@ static void i915_gem_reset_engine_status(struct 
intel_engine_cs *engine)
 
 static void i915_gem_reset_engine_cleanup(struct intel_engine_cs *engine)
 {
+   struct drm_i915_gem_request *request;
struct intel_ring *ring;
 
+   request = i915_gem_active_peek(>last_request,
+  >i915->drm.struct_mutex);
+
/* Mark all pending requests as complete so that any concurrent
 * (lockless) lookup doesn't try and wait upon the request as we
 * reset it.
 */
-   intel_engine_init_seqno(engine, engine->last_submitted_seqno);
+   if (request)
+   intel_engine_init_seqno(engine, request->fence.seqno);
 
/*
 * Clear the execlists queue up before freeing the requests, as those
@@ -2466,15 +2471,9 @@ static void i915_gem_reset_engine_cleanup(struct 
intel_engine_cs *engine)
 * implicit references on things like e.g. ppgtt address spaces through
 * the request.
 */
-   if (!list_empty(>request_list)) {
-   struct drm_i915_gem_request *request;
-
-   request = list_last_entry(>request_list,
- struct drm_i915_gem_request,
- link);
-
+   if (request)
i915_gem_request_retire_upto(request);
-   }
+   GEM_BUG_ON(intel_engine_is_active(engine));
 
/* Having flushed all requests from all queues, we know that all
 * ringbuffers must now be empty. However, since we do not reclaim
@@ -2897,18 +2896,17 @@ destroy:
return 0;
 }
 
-int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv)
+int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
+  bool interruptible)
 {
struct intel_engine_cs *engine;
int ret;
 
-   lockdep_assert_held(_priv->drm.struct_mutex);
-
  

[Intel-gfx] [PATCH 10/19] drm/i915: Remove unused no-shrinker-steal

[Chris Wilson]

After removing the user of this wart, we can remove the wart entirely.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 -
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6eff31202336..31a614fe9ed7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1318,7 +1318,6 @@ struct i915_gem_mm {
struct notifier_block oom_notifier;
struct notifier_block vmap_notifier;
struct shrinker shrinker;
-   bool shrinker_no_lock_stealing;
 
/** LRU list of objects with fence regs on them. */
struct list_head fence_list;
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 9b92b6470ccc..b80802b35353 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -244,9 +244,6 @@ static bool i915_gem_shrinker_lock(struct drm_device *dev, 
bool *unlock)
if (!mutex_is_locked_by(>struct_mutex, current))
return false;
 
-   if (to_i915(dev)->mm.shrinker_no_lock_stealing)
-   return false;
-
*unlock = false;
} else
*unlock = true;
-- 
2.8.1

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

[Intel-gfx] [PATCH 04/19] drm/i915/userptr: Remove superfluous interruptible=false on waiting

[Chris Wilson]

Inside the kthread context, we can't be interrupted by signals so
touching the mm.interruptible flag is pointless and wait-request now
consumes EIO itself.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 96ab6161903a..57218cca7e05 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -84,16 +84,9 @@ static void cancel_userptr(struct work_struct *work)
obj->userptr.work = NULL;
 
if (obj->pages != NULL) {
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   bool was_interruptible;
-
-   was_interruptible = dev_priv->mm.interruptible;
-   dev_priv->mm.interruptible = false;
-
+   /* We are inside a kthread context and can't be interrupted */
WARN_ON(i915_gem_object_unbind(obj));
WARN_ON(i915_gem_object_put_pages(obj));
-
-   dev_priv->mm.interruptible = was_interruptible;
}
 
i915_gem_object_put(obj);
-- 
2.8.1

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

[Intel-gfx] [PATCH 09/19] drm/i915: Tidy generation of the GTT mmap offset

[Chris Wilson]

If we make the observation that mmap-offsets are only released when we
free an object, we can then deduce that the shrinker only creates free
space in the mmap arena indirectly by flushing the request list and
freeing expired objects. If we combine this with the lockless
vma-manager and lockless idling, we can avoid taking our big struct_mutex
until we need to actually free the requests.

One side-effect is that we defer the madvise checking until we need the
pages (i.e. the fault handler). This brings us into line with the other
delayed checks (and madvise in general).

v2: s/ret/err/ and use if (!err) rather than if (ret == 0)

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 69 +
 1 file changed, 22 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0872de359bd7..ee222961c62a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1898,36 +1898,28 @@ u64 i915_gem_get_ggtt_alignment(struct drm_i915_private 
*dev_priv, u64 size,
 static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   int ret;
-
-   dev_priv->mm.shrinker_no_lock_stealing = true;
+   int err;
 
-   ret = drm_gem_create_mmap_offset(>base);
-   if (ret != -ENOSPC)
-   goto out;
+   err = drm_gem_create_mmap_offset(>base);
+   if (!err)
+   return 0;
 
-   /* Badly fragmented mmap space? The only way we can recover
-* space is by destroying unwanted objects. We can't randomly release
-* mmap_offsets as userspace expects them to be persistent for the
-* lifetime of the objects. The closest we can is to release the
-* offsets on purgeable objects by truncating it and marking it purged,
-* which prevents userspace from ever using that object again.
+   /* We can idle the GPU locklessly to flush stale objects, but in order
+* to claim that space for ourselves, we need to take the big
+* struct_mutex to free the requests+objects and allocate our slot.
 */
-   i915_gem_shrink(dev_priv,
-   obj->base.size >> PAGE_SHIFT,
-   I915_SHRINK_BOUND |
-   I915_SHRINK_UNBOUND |
-   I915_SHRINK_PURGEABLE);
-   ret = drm_gem_create_mmap_offset(>base);
-   if (ret != -ENOSPC)
-   goto out;
+   err = i915_gem_wait_for_idle(dev_priv, true);
+   if (err)
+   return err;
 
-   i915_gem_shrink_all(dev_priv);
-   ret = drm_gem_create_mmap_offset(>base);
-out:
-   dev_priv->mm.shrinker_no_lock_stealing = false;
+   err = i915_mutex_lock_interruptible(_priv->drm);
+   if (!err) {
+   i915_gem_retire_requests(dev_priv);
+   err = drm_gem_create_mmap_offset(>base);
+   mutex_unlock(_priv->drm.struct_mutex);
+   }
 
-   return ret;
+   return err;
 }
 
 static void i915_gem_object_free_mmap_offset(struct drm_i915_gem_object *obj)
@@ -1944,32 +1936,15 @@ i915_gem_mmap_gtt(struct drm_file *file,
struct drm_i915_gem_object *obj;
int ret;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
-
-   if (obj->madv != I915_MADV_WILLNEED) {
-   DRM_DEBUG("Attempting to mmap a purgeable buffer\n");
-   ret = -EFAULT;
-   goto out;
-   }
+   if (!obj)
+   return -ENOENT;
 
ret = i915_gem_object_create_mmap_offset(obj);
-   if (ret)
-   goto out;
+   if (ret == 0)
+   *offset = drm_vma_node_offset_addr(>base.vma_node);
 
-   *offset = drm_vma_node_offset_addr(>base.vma_node);
-
-out:
-   i915_gem_object_put(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
+   i915_gem_object_put_unlocked(obj);
return ret;
 }
 
-- 
2.8.1

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

[Intel-gfx] [PATCH 07/19] drm/i915: Simplify do_idling() (Ironlake vt-d w/a)

[Chris Wilson]

Now that we pass along the expected interruptible nature for the
wait-for-idle, we do not need to modify the global
i915->mm.interruptible for this single call. (Only the immediate call to
i915_gem_wait_for_idle() takes the interruptible status as the other
action, dma_map_sg(), is independent of i915.ko)

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

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c1d79978f409..8b4f2f35019c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2241,31 +2241,6 @@ static bool needs_idle_maps(struct drm_i915_private 
*dev_priv)
return false;
 }
 
-static bool do_idling(struct drm_i915_private *dev_priv)
-{
-   struct i915_ggtt *ggtt = _priv->ggtt;
-   bool ret = dev_priv->mm.interruptible;
-
-   if (unlikely(ggtt->do_idle_maps)) {
-   dev_priv->mm.interruptible = false;
-   if (i915_gem_wait_for_idle(dev_priv, false)) {
-   DRM_ERROR("Failed to wait for idle; VT'd may hang.\n");
-   /* Wait a bit, in hopes it avoids the hang */
-   udelay(10);
-   }
-   }
-
-   return ret;
-}
-
-static void undo_idling(struct drm_i915_private *dev_priv, bool interruptible)
-{
-   struct i915_ggtt *ggtt = _priv->ggtt;
-
-   if (unlikely(ggtt->do_idle_maps))
-   dev_priv->mm.interruptible = interruptible;
-}
-
 void i915_check_and_clear_faults(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
@@ -2713,14 +2688,18 @@ void i915_gem_gtt_finish_object(struct 
drm_i915_gem_object *obj)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   bool interruptible;
+   struct i915_ggtt *ggtt = _priv->ggtt;
 
-   interruptible = do_idling(dev_priv);
+   if (unlikely(ggtt->do_idle_maps)) {
+   if (i915_gem_wait_for_idle(dev_priv, false)) {
+   DRM_ERROR("Failed to wait for idle; VT'd may hang.\n");
+   /* Wait a bit, in hopes it avoids the hang */
+   udelay(10);
+   }
+   }
 
dma_unmap_sg(>pdev->dev, obj->pages->sgl, obj->pages->nents,
 PCI_DMA_BIDIRECTIONAL);
-
-   undo_idling(dev_priv, interruptible);
 }
 
 static void i915_gtt_color_adjust(struct drm_mm_node *node,
-- 
2.8.1

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

[Intel-gfx] [PATCH 12/19] drm/i915: Remove (struct_mutex) locking for wait-ioctl

[Chris Wilson]

With a bit of care (and leniency) we can iterate over the object and
wait for previous rendering to complete with judicial use of atomic
reference counting. The ABI requires us to ensure that an active object
is eventually flushed (like the busy-ioctl) which is guaranteed by our
management of requests (i.e. everything that is submitted to hardware is
flushed in the same request). All we have to do is ensure that we can
detect when the requests are complete for reporting when the object is
idle (without triggering ETIME), locklessly - this is handled by
i915_gem_active_wait_unlocked().

The impact of this is actually quite small - the return to userspace
following the wait was already lockless and so we don't see much gain in
latency improvement upon completing the wait. What we do achieve here is
completing an already finished wait without hitting the struct_mutex,
our hold is quite short and so we are typically just a victim of
contention rather than a cause - but it is still one less contention
point!

v2: Break up a long line.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 43 -
 1 file changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fa0936a787a7..4ef3f704b8b2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2620,47 +2620,28 @@ int
 i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
 {
struct drm_i915_gem_wait *args = data;
+   struct intel_rps_client *rps = to_rps_client(file);
struct drm_i915_gem_object *obj;
-   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   int i, n = 0;
-   int ret;
+   unsigned long active;
+   int idx, ret = 0;
 
if (args->flags != 0)
return -EINVAL;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, args->bo_handle);
-   if (!obj) {
-   mutex_unlock(>struct_mutex);
+   if (!obj)
return -ENOENT;
-   }
-
-   if (!i915_gem_object_is_active(obj))
-   goto out;
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct drm_i915_gem_request *req;
-
-   req = i915_gem_active_get(>last_read[i],
- >base.dev->struct_mutex);
-   if (req)
-   requests[n++] = req;
+   active = __I915_BO_ACTIVE(obj);
+   for_each_active(active, idx) {
+   s64 *timeout = args->timeout_ns >= 0 ? >timeout_ns : NULL;
+   ret = i915_gem_active_wait_unlocked(>last_read[idx], true,
+   timeout, rps);
+   if (ret)
+   break;
}
 
-out:
-   i915_gem_object_put(obj);
-   mutex_unlock(>struct_mutex);
-
-   for (i = 0; i < n; i++) {
-   if (ret == 0)
-   ret = i915_wait_request(requests[i], true,
-   args->timeout_ns > 0 ? 
>timeout_ns : NULL,
-   to_rps_client(file));
-   i915_gem_request_put(requests[i]);
-   }
+   i915_gem_object_put_unlocked(obj);
return ret;
 }
 
-- 
2.8.1

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

[Intel-gfx] [PATCH 11/19] drm/i915: Do a nonblocking wait first in pread/pwrite

[Chris Wilson]

If we try and read or write to an active request, we first must wait
upon the GPU completing that request. Let's do that without holding the
mutex (and so allow someone else to access the GPU whilst we wait). Upn
completion, we will reacquire the mutex and only then start the
operation (i.e. we do not rely on state from before dropping the mutex).

v2: Repaint the goto labels

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 62 +++--
 1 file changed, 35 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ee222961c62a..fa0936a787a7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -956,25 +956,26 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
   args->size))
return -EFAULT;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Bounds check source.  */
if (args->offset > obj->base.size ||
args->size > obj->base.size - args->offset) {
ret = -EINVAL;
-   goto out;
+   goto err;
}
 
-   trace_i915_gem_object_pread(obj, args->offset, args->size);
+   ret = __unsafe_wait_rendering(obj, to_rps_client(file), true);
+   if (ret)
+   goto err;
 
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   goto err;
+
+   trace_i915_gem_object_pread(obj, args->offset, args->size);
ret = i915_gem_shmem_pread(dev, obj, args, file);
 
/* pread for non shmem backed objects */
@@ -985,10 +986,13 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
intel_runtime_pm_put(to_i915(dev));
}
 
-out:
i915_gem_object_put(obj);
-unlock:
mutex_unlock(>struct_mutex);
+
+   return ret;
+
+err:
+   i915_gem_object_put_unlocked(obj);
return ret;
 }
 
@@ -1374,27 +1378,28 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
return -EFAULT;
}
 
-   intel_runtime_pm_get(dev_priv);
-
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   goto put_rpm;
-
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Bounds check destination. */
if (args->offset > obj->base.size ||
args->size > obj->base.size - args->offset) {
ret = -EINVAL;
-   goto out;
+   goto err;
}
 
-   trace_i915_gem_object_pwrite(obj, args->offset, args->size);
+   ret = __unsafe_wait_rendering(obj, to_rps_client(file), false);
+   if (ret)
+   goto err;
 
+   intel_runtime_pm_get(dev_priv);
+
+   ret = i915_mutex_lock_interruptible(dev);
+   if (ret)
+   goto err_rpm;
+
+   trace_i915_gem_object_pwrite(obj, args->offset, args->size);
ret = -EFAULT;
/* We can only do the GTT pwrite on untiled buffers, as otherwise
 * it would end up going through the fenced access, and we'll get
@@ -1419,14 +1424,17 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
*data,
ret = -ENODEV;
}
 
-out:
i915_gem_object_put(obj);
-unlock:
mutex_unlock(>struct_mutex);
-put_rpm:
intel_runtime_pm_put(dev_priv);
 
return ret;
+
+err_rpm:
+   intel_runtime_pm_put(dev_priv);
+err:
+   i915_gem_object_put_unlocked(obj);
+   return ret;
 }
 
 static enum fb_op_origin
-- 
2.8.1

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

[Intel-gfx] [PATCH 18/19] drm/i915: Repack fence tiling mode and stride into a single integer

[Chris Wilson]

In the previous commit, we moved the obj->tiling_mode out of a bitfield
and into its own integer so that we could safely use READ_ONCE(). Let us
now repair some of that damage by sharing the tiling_mode with its
companion, the fence stride.

v2: New magic

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 30 +--
 drivers/gpu/drm/i915/i915_gem.c| 20 ---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_fence.c  | 39 ++
 drivers/gpu/drm/i915/i915_gem_tiling.c | 19 +--
 drivers/gpu/drm/i915/i915_gpu_error.c  |  2 +-
 drivers/gpu/drm/i915/intel_display.c   | 34 +-
 drivers/gpu/drm/i915/intel_fbc.c   |  2 +-
 drivers/gpu/drm/i915/intel_overlay.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c|  2 +-
 drivers/gpu/drm/i915/intel_sprite.c| 12 -
 12 files changed, 98 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1faea382dfeb..0620a84d00ca 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -101,7 +101,7 @@ static char get_pin_flag(struct drm_i915_gem_object *obj)
 
 static char get_tiling_flag(struct drm_i915_gem_object *obj)
 {
-   switch (obj->tiling_mode) {
+   switch (i915_gem_object_get_tiling(obj)) {
default:
case I915_TILING_NONE: return ' ';
case I915_TILING_X: return 'X';
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f18d8761305c..feec00f769e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2214,13 +2214,11 @@ struct drm_i915_gem_object {
 
atomic_t frontbuffer_bits;
 
-   /**
-* Current tiling mode for the object.
-*/
-   unsigned int tiling_mode;
-
/** Current tiling stride for the object, if it's tiled. */
-   uint32_t stride;
+   unsigned int tiling_and_stride;
+#define FENCE_MINIMUM_STRIDE 128 /* See i915_tiling_ok() */
+#define TILING_MASK (FENCE_MINIMUM_STRIDE-1)
+#define STRIDE_MASK (~TILING_MASK)
 
unsigned int has_wc_mmap;
/** Count of VMA actually bound by this object */
@@ -2359,6 +2357,24 @@ i915_gem_object_has_active_engine(const struct 
drm_i915_gem_object *obj,
return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
 }
 
+static inline unsigned int
+i915_gem_object_get_tiling(struct drm_i915_gem_object *obj)
+{
+   return obj->tiling_and_stride & TILING_MASK;
+}
+
+static inline bool
+i915_gem_object_is_tiled(struct drm_i915_gem_object *obj)
+{
+   return i915_gem_object_get_tiling(obj) != I915_TILING_NONE;
+}
+
+static inline unsigned int
+i915_gem_object_get_stride(struct drm_i915_gem_object *obj)
+{
+   return obj->tiling_and_stride & STRIDE_MASK;
+}
+
 /*
  * Optimised SGL iterator for GEM objects
  */
@@ -3457,7 +3473,7 @@ static inline bool 
i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_objec
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
 
return dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17 &&
-   obj->tiling_mode != I915_TILING_NONE;
+   i915_gem_object_is_tiled(obj);
 }
 
 /* i915_debugfs.c */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eb7b0f4d8a53..2b5cd63bca44 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1041,7 +1041,7 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
int ret;
bool hit_slow_path = false;
 
-   if (obj->tiling_mode != I915_TILING_NONE)
+   if (i915_gem_object_is_tiled(obj))
return -EFAULT;
 
ret = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
@@ -1669,7 +1669,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
 
/* Use a partial view if the object is bigger than the aperture. */
if (obj->base.size >= ggtt->mappable_end &&
-   obj->tiling_mode == I915_TILING_NONE) {
+   !i915_gem_object_is_tiled(obj)) {
static const unsigned int chunk_size = 256; // 1 MiB
 
memset(, 0, sizeof(view));
@@ -2187,7 +2187,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
 
-   if (obj->tiling_mode != I915_TILING_NONE &&
+   if (i915_gem_object_is_tiled(obj) &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES)
i915_gem_object_pin_pages(obj);
 
@@ -2936,10 +2936,12 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
 
size = max(size, 

[Intel-gfx] [PATCH 13/19] drm/i915: Remove (struct_mutex) locking for busy-ioctl

[Chris Wilson]

By applying the same logic as for wait-ioctl, we can query whether a
request has completed without holding struct_mutex. The biggest impact
system-wide is removing the flush_active and the contention that causes.

Testcase: igt/gem_busy
Signed-off-by: Chris Wilson 
Cc: Akash Goel 
---
 drivers/gpu/drm/i915/i915_gem.c | 126 ++--
 1 file changed, 96 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4ef3f704b8b2..5ec3ebf33bc8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3734,49 +3734,115 @@ i915_gem_object_ggtt_unpin_view(struct 
drm_i915_gem_object *obj,
i915_vma_unpin(i915_gem_obj_to_ggtt_view(obj, view));
 }
 
+static __always_inline unsigned __busy_read_flag(unsigned int id)
+{
+   /* Note that we could alias engines in the execbuf API, but
+* that would be very unwise as it prevents userspace from
+* fine control over engine selection. Ahem.
+*
+* This should be something like EXEC_MAX_ENGINE instead of
+* I915_NUM_ENGINES.
+*/
+   BUILD_BUG_ON(I915_NUM_ENGINES > 16);
+   return 0x1 << id;
+}
+
+static __always_inline unsigned int __busy_write_flag(unsigned int id)
+{
+   return id;
+}
+
+static __always_inline unsigned
+__busy_flag(const struct i915_gem_active *active,
+   unsigned int (*flag)(unsigned int id))
+{
+   /* For more discussion about the barriers and locking concerns,
+* see __i915_gem_active_get_rcu().
+*/
+   do {
+   struct drm_i915_gem_request *request;
+   unsigned int id;
+
+   request = rcu_dereference(active->request);
+   if (!request || i915_gem_request_completed(request))
+   return 0;
+
+   id = request->engine->exec_id;
+
+   /* Check that the pointer wasn't reassigned and overwritten. */
+   if (request == rcu_access_pointer(active->request))
+   return flag(id);
+   } while (1);
+}
+
+static inline unsigned
+busy_read_flag(const struct i915_gem_active *active)
+{
+   return __busy_flag(active, __busy_read_flag);
+}
+
+static inline unsigned
+busy_write_flag(const struct i915_gem_active *active)
+{
+   return __busy_flag(active, __busy_write_flag);
+}
+
 int
 i915_gem_busy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
 {
struct drm_i915_gem_busy *args = data;
struct drm_i915_gem_object *obj;
-   int ret;
-
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
+   unsigned long active;
 
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
-   /* Count all active objects as busy, even if they are currently not used
-* by the gpu. Users of this interface expect objects to eventually
-* become non-busy without any further actions.
-*/
args->busy = 0;
-   if (i915_gem_object_is_active(obj)) {
-   struct drm_i915_gem_request *req;
-   int i;
+   active = __I915_BO_ACTIVE(obj);
+   if (active) {
+   int idx;
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   req = i915_gem_active_peek(>last_read[i],
-  
>base.dev->struct_mutex);
-   if (req)
-   args->busy |= 1 << (16 + req->engine->exec_id);
-   }
-   req = i915_gem_active_peek(>last_write,
-  >base.dev->struct_mutex);
-   if (req)
-   args->busy |= req->engine->exec_id;
+   /* Yes, the lookups are intentionally racy.
+*
+* Even though we guard the pointer lookup by RCU, that only
+* guarantees that the pointer and its contents remain
+* dereferencable and does *not* mean that the request we
+* have is the same as the one being tracked by the object.
+*
+* Consider that we lookup the request just as it is being
+* retired and free. We take a local copy of the pointer,
+* but before we add its engine into the busy set, the other
+* thread reallocates it and assigns it to a task on another
+* engine with a fresh and incomplete seqno.
+*
+* So after we lookup the engine's id, we double check that
+* the active request is the same and only then do we add it
+* into the busy set.
+*/
+

[Intel-gfx] [PATCH 19/19] drm/i915: Assert that the request hasn't been retired

[Chris Wilson]

With all callers now not playing tricks with dropping the struct_mutex
between waiting and retiring, we can assert that the request is ready to
be retired.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 1f91dc8c4171..b317a672040f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -170,7 +170,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
struct i915_gem_active *active, *next;
 
trace_i915_gem_request_retire(request);
-   list_del_init(>link);
+   list_del(>link);
 
/* We know the GPU must have read the request to have
 * sent us the seqno + interrupt, so use the position
@@ -228,9 +228,7 @@ void i915_gem_request_retire_upto(struct 
drm_i915_gem_request *req)
struct drm_i915_gem_request *tmp;
 
lockdep_assert_held(>i915->drm.struct_mutex);
-
-   if (list_empty(>link))
-   return;
+   GEM_BUG_ON(list_empty(>link));
 
do {
tmp = list_first_entry(>request_list,
-- 
2.8.1

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

[Intel-gfx] [PATCH 17/19] drm/i915: Document and reject invalid tiling modes

[Chris Wilson]

Through the GTT interface to the fence registers, we can only handle
linear, X and Y tiling. The more esoteric tiling patterns are ignored.
Document that the tiling ABI only supports upto Y tiling, and reject any
attempts to set a tiling mode other than NONE, X or Y.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_tiling.c | 3 +++
 include/uapi/drm/i915_drm.h| 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index c0e01333bddf..6817f69947d9 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -68,6 +68,9 @@ i915_tiling_ok(struct drm_device *dev, int stride, int size, 
int tiling_mode)
if (tiling_mode == I915_TILING_NONE)
return true;
 
+   if (tiling_mode > I915_TILING_LAST)
+   return false;
+
if (IS_GEN2(dev) ||
(tiling_mode == I915_TILING_Y && HAS_128_BYTE_Y_TILING(dev)))
tile_width = 128;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 0f292733cffc..452629de7a57 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -926,6 +926,7 @@ struct drm_i915_gem_caching {
 #define I915_TILING_NONE   0
 #define I915_TILING_X  1
 #define I915_TILING_Y  2
+#define I915_TILING_LAST   I915_TILING_Y
 
 #define I915_BIT_6_SWIZZLE_NONE0
 #define I915_BIT_6_SWIZZLE_9   1
-- 
2.8.1

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

[Intel-gfx] [PATCH 15/19] drm/i915: Remove pinned check from madvise ioctl

[Chris Wilson]

We don't need to incur the overhead of checking whether the object is
pinned prior to changing its madvise. If the object is pinned, the
madvise will not take effect until it is unpinned and so we cannot free
the pages being pointed at by hardware. Marking a pinned object with
allocated pages as DONTNEED will not trigger any undue warnings. The check
is therefore superfluous, and by removing it we can remove a linear walk
over all the vma the object has.

Still despite it being an overzealous check, that error code is part of
the current ABI and so we must proceed with caution.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e18e30dfac4d..eb7b0f4d8a53 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3876,11 +3876,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void 
*data,
goto unlock;
}
 
-   if (i915_gem_obj_is_pinned(obj)) {
-   ret = -EINVAL;
-   goto out;
-   }
-
if (obj->pages &&
obj->tiling_mode != I915_TILING_NONE &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
@@ -3899,7 +3894,6 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
 
args->retained = obj->madv != __I915_MADV_PURGED;
 
-out:
i915_gem_object_put(obj);
 unlock:
mutex_unlock(>struct_mutex);
-- 
2.8.1

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

[Intel-gfx] [PATCH 16/19] drm/i915: Remove locking for get_tiling

[Chris Wilson]

Since we are not concerned with userspace racing itself with set-tiling
(the order is indeterminant even if we take a lock), then we can safely
read back the single obj->tiling_mode and do the static lookup of
swizzle mode without having to take a lock.

get-tiling is reasonably frequent due to the back-channel passing around
of tiling parameters in DRI2/DRI3.

v2: Make tiling_mode a full unsigned int so that we can trivially use it
with READ_ONCE(). Separating it out into manual control over the flags
field was too noisy for a simple patch. Note that we could use the lower
bits of obj->stride for the tiling mode.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h| 15 ---
 drivers/gpu/drm/i915/i915_gem_tiling.c | 10 +++---
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 31a614fe9ed7..f18d8761305c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2183,10 +2183,6 @@ struct drm_i915_gem_object {
unsigned int madv:2;
 
/**
-* Current tiling mode for the object.
-*/
-   unsigned int tiling_mode:2;
-   /**
 * Whether the tiling parameters for the currently associated fence
 * register have changed. Note that for the purposes of tracking
 * tiling changes we also treat the unfenced register, the register
@@ -2218,6 +2214,14 @@ struct drm_i915_gem_object {
 
atomic_t frontbuffer_bits;
 
+   /**
+* Current tiling mode for the object.
+*/
+   unsigned int tiling_mode;
+
+   /** Current tiling stride for the object, if it's tiled. */
+   uint32_t stride;
+
unsigned int has_wc_mmap;
/** Count of VMA actually bound by this object */
unsigned int bind_count;
@@ -2245,9 +2249,6 @@ struct drm_i915_gem_object {
struct i915_gem_active last_write;
struct i915_gem_active last_fence;
 
-   /** Current tiling stride for the object, if it's tiled. */
-   uint32_t stride;
-
/** References from framebuffers, locks out tiling changes. */
unsigned long framebuffer_references;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index b7f9875f69b4..c0e01333bddf 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -303,10 +303,8 @@ i915_gem_get_tiling(struct drm_device *dev, void *data,
if (!obj)
return -ENOENT;
 
-   mutex_lock(>struct_mutex);
-
-   args->tiling_mode = obj->tiling_mode;
-   switch (obj->tiling_mode) {
+   args->tiling_mode = READ_ONCE(obj->tiling_mode);
+   switch (args->tiling_mode) {
case I915_TILING_X:
args->swizzle_mode = dev_priv->mm.bit_6_swizzle_x;
break;
@@ -330,8 +328,6 @@ i915_gem_get_tiling(struct drm_device *dev, void *data,
if (args->swizzle_mode == I915_BIT_6_SWIZZLE_9_10_17)
args->swizzle_mode = I915_BIT_6_SWIZZLE_9_10;
 
-   i915_gem_object_put(obj);
-   mutex_unlock(>struct_mutex);
-
+   i915_gem_object_put_unlocked(obj);
return 0;
 }
-- 
2.8.1

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

[Intel-gfx] [PATCH 14/19] drm/i915: Reduce locking inside swfinish ioctl

[Chris Wilson]

We only need to take the struct_mutex if the object is pinned to the
display engine and so requires checking for clflush. (The race with
userspace pinning the object to a framebuffer is irrelevant.)

v2: Use access once for compiler hints (or not as it is a bitfield)
v3: READ_ONCE, obj->pin_display is not a bitfield anymore
v4: Don't be creative with goto.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ec3ebf33bc8..e18e30dfac4d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1516,26 +1516,23 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
 {
struct drm_i915_gem_sw_finish *args = data;
struct drm_i915_gem_object *obj;
-   int ret = 0;
-
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
+   int err = 0;
 
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Pinned buffers may be scanout, so flush the cache */
-   if (obj->pin_display)
-   i915_gem_object_flush_cpu_write_domain(obj);
+   if (READ_ONCE(obj->pin_display)) {
+   err = i915_mutex_lock_interruptible(dev);
+   if (!err) {
+   i915_gem_object_flush_cpu_write_domain(obj);
+   mutex_unlock(>struct_mutex);
+   }
+   }
 
-   i915_gem_object_put(obj);
-unlock:
-   mutex_unlock(>struct_mutex);
-   return ret;
+   i915_gem_object_put_unlocked(obj);
+   return err;
 }
 
 /**
-- 
2.8.1

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

[Intel-gfx] [PATCH 03/19] drm/i915: Convert non-blocking userptr waits for requests over to using RCU

[Chris Wilson]

We can completely avoid taking the struct_mutex around the non-blocking
waits by switching over to the RCU request management (trading the mutex
for a RCU read lock and some complex atomic operations). The improvement
is that we gain further contention reduction, and overall the code
become simpler due to the reduced mutex dancing.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 34 +++--
 1 file changed, 7 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 53f64fcc89ef..96ab6161903a 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -63,32 +63,12 @@ struct i915_mmu_object {
 
 static void wait_rendering(struct drm_i915_gem_object *obj)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   int i, n;
-
-   if (!i915_gem_object_is_active(obj))
-   return;
-
-   n = 0;
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct drm_i915_gem_request *req;
+   unsigned long active = __I915_BO_ACTIVE(obj);
+   int idx;
 
-   req = i915_gem_active_get(>last_read[i],
- >base.dev->struct_mutex);
-   if (req)
-   requests[n++] = req;
-   }
-
-   mutex_unlock(>struct_mutex);
-
-   for (i = 0; i < n; i++)
-   i915_wait_request(requests[i], false, NULL, NULL);
-
-   mutex_lock(>struct_mutex);
-
-   for (i = 0; i < n; i++)
-   i915_gem_request_put(requests[i]);
+   for_each_active(active, idx)
+   i915_gem_active_wait_unlocked(>last_read[idx],
+ false, NULL, NULL);
 }
 
 static void cancel_userptr(struct work_struct *work)
@@ -97,6 +77,8 @@ static void cancel_userptr(struct work_struct *work)
struct drm_i915_gem_object *obj = mo->obj;
struct drm_device *dev = obj->base.dev;
 
+   wait_rendering(obj);
+
mutex_lock(>struct_mutex);
/* Cancel any active worker and force us to re-evaluate gup */
obj->userptr.work = NULL;
@@ -105,8 +87,6 @@ static void cancel_userptr(struct work_struct *work)
struct drm_i915_private *dev_priv = to_i915(dev);
bool was_interruptible;
 
-   wait_rendering(obj);
-
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
 
-- 
2.8.1

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

[Intel-gfx] [PATCH 05/19] drm/i915: Remove forced stop ring on suspend/unload

[Chris Wilson]

Before suspending (or unloading), we would first wait upon all rendering
to be completed and then disable the rings. This later step is a remanent
from DRI1 days when we did not use request tracking for all operations
upon the ring. Now that we are sure we are waiting upon the very last
operation by the engine, we can forgo clobbering the ring registers,
though we do keep the assert that the engine is indeed idle before
sleeping.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem.c | 18 --
 drivers/gpu/drm/i915/intel_lrc.c| 26 --
 drivers/gpu/drm/i915/intel_ringbuffer.c | 16 
 4 files changed, 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db5dc5bd78d8..abdfb97096e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2004,7 +2004,6 @@ struct drm_i915_private {
/* Abstract the submission mechanism (legacy ringbuffer or execlists) 
away */
struct {
void (*cleanup_engine)(struct intel_engine_cs *engine);
-   void (*stop_engine)(struct intel_engine_cs *engine);
 
/**
 * Is the GPU currently considered idle, or busy executing
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c600f2366d2c..8946c52e09fb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4080,16 +4080,6 @@ struct i915_vma *i915_gem_obj_to_ggtt_view(struct 
drm_i915_gem_object *obj,
return NULL;
 }
 
-static void
-i915_gem_stop_engines(struct drm_device *dev)
-{
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_engine_cs *engine;
-
-   for_each_engine(engine, dev_priv)
-   dev_priv->gt.stop_engine(engine);
-}
-
 int
 i915_gem_suspend(struct drm_device *dev)
 {
@@ -4118,12 +4108,6 @@ i915_gem_suspend(struct drm_device *dev)
 
i915_gem_retire_requests(dev_priv);
 
-   /* Note that rather than stopping the engines, all we have to do
-* is assert that every RING_HEAD == RING_TAIL (all execution complete)
-* and similar for all logical context images (to ensure they are
-* all ready for hibernation).
-*/
-   i915_gem_stop_engines(dev);
i915_gem_context_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
@@ -4308,10 +4292,8 @@ int i915_gem_init(struct drm_device *dev)
 
if (!i915.enable_execlists) {
dev_priv->gt.cleanup_engine = intel_engine_cleanup;
-   dev_priv->gt.stop_engine = intel_engine_stop;
} else {
dev_priv->gt.cleanup_engine = intel_logical_ring_cleanup;
-   dev_priv->gt.stop_engine = intel_logical_ring_stop;
}
 
/* This is just a security blanket to placate dragons.
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a07da548ff49..309c5d9b1c57 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -760,31 +760,6 @@ void intel_execlists_cancel_requests(struct 
intel_engine_cs *engine)
}
 }
 
-void intel_logical_ring_stop(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-   int ret;
-
-   if (!intel_engine_initialized(engine))
-   return;
-
-   ret = intel_engine_idle(engine);
-   if (ret)
-   DRM_ERROR("failed to quiesce %s whilst cleaning up: %d\n",
- engine->name, ret);
-
-   /* TODO: Is this correct with Execlists enabled? */
-   I915_WRITE_MODE(engine, _MASKED_BIT_ENABLE(STOP_RING));
-   if (intel_wait_for_register(dev_priv,
-   RING_MI_MODE(engine->mmio_base),
-   MODE_IDLE, MODE_IDLE,
-   1000)) {
-   DRM_ERROR("%s :timed out trying to stop ring\n", engine->name);
-   return;
-   }
-   I915_WRITE_MODE(engine, _MASKED_BIT_DISABLE(STOP_RING));
-}
-
 static int intel_lr_context_pin(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
 {
@@ -1717,7 +1692,6 @@ void intel_logical_ring_cleanup(struct intel_engine_cs 
*engine)
dev_priv = engine->i915;
 
if (engine->buffer) {
-   intel_logical_ring_stop(engine);
WARN_ON((I915_READ_MODE(engine) & MODE_IDLE) == 0);
}
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a862234ccf18..4593a65cae84 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2203,7 +2203,6 @@ void intel_engine_cleanup(struct intel_engine_cs *engine)
dev_priv = engine->i915;
 
if (engine->buffer) {
-   

[Intel-gfx] [PATCH 02/19] drm/i915: Convert non-blocking waits for requests over to using RCU

[Chris Wilson]

We can completely avoid taking the struct_mutex around the non-blocking
waits by switching over to the RCU request management (trading the mutex
for a RCU read lock and some complex atomic operations). The improvement
is that we gain further contention reduction, and overall the code
become simpler due to the reduced mutex dancing.

v2: Move i915_gem_fault tracepoint to start of function, before the
unlocked wait.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 114 +---
 1 file changed, 48 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index aa40d6c35c30..c600f2366d2c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -349,24 +349,20 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
return 0;
 }
 
-/* A nonblocking variant of the above wait. This is a highly dangerous routine
- * as the object state may change during this call.
+/* A nonblocking variant of the above wait. Must be called prior to
+ * acquiring the mutex for the object, as the object state may change
+ * during this call. A reference must be held by the caller for the object.
  */
 static __must_check int
-i915_gem_object_wait_rendering__nonblocking(struct drm_i915_gem_object *obj,
-   struct intel_rps_client *rps,
-   bool readonly)
+__unsafe_wait_rendering(struct drm_i915_gem_object *obj,
+   struct intel_rps_client *rps,
+   bool readonly)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
struct i915_gem_active *active;
unsigned long active_mask;
-   int ret, i, n = 0;
-
-   lockdep_assert_held(>struct_mutex);
-   GEM_BUG_ON(!to_i915(dev)->mm.interruptible);
+   int idx;
 
-   active_mask = i915_gem_object_get_active(obj);
+   active_mask = __I915_BO_ACTIVE(obj);
if (!active_mask)
return 0;
 
@@ -377,25 +373,16 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
active = >last_write;
}
 
-   for_each_active(active_mask, i) {
-   struct drm_i915_gem_request *req;
+   for_each_active(active_mask, idx) {
+   int ret;
 
-   req = i915_gem_active_get([i],
- >base.dev->struct_mutex);
-   if (req)
-   requests[n++] = req;
+   ret = i915_gem_active_wait_unlocked([idx],
+   true, NULL, rps);
+   if (ret)
+   return ret;
}
 
-   mutex_unlock(>struct_mutex);
-   ret = 0;
-   for (i = 0; ret == 0 && i < n; i++)
-   ret = i915_wait_request(requests[i], true, NULL, rps);
-   mutex_lock(>struct_mutex);
-
-   for (i = 0; i < n; i++)
-   i915_gem_request_put(requests[i]);
-
-   return ret;
+   return 0;
 }
 
 static struct intel_rps_client *to_rps_client(struct drm_file *file)
@@ -1467,10 +1454,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
int ret;
 
/* Only handle setting domains to types used by the CPU. */
-   if (write_domain & I915_GEM_GPU_DOMAINS)
-   return -EINVAL;
-
-   if (read_domains & I915_GEM_GPU_DOMAINS)
+   if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
return -EINVAL;
 
/* Having something in the write domain implies it's in the read
@@ -1479,25 +1463,21 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
if (write_domain != 0 && read_domains != write_domain)
return -EINVAL;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   return ret;
-
obj = i915_gem_object_lookup(file, args->handle);
-   if (!obj) {
-   ret = -ENOENT;
-   goto unlock;
-   }
+   if (!obj)
+   return -ENOENT;
 
/* Try to flush the object off the GPU without holding the lock.
 * We will repeat the flush holding the lock in the normal manner
 * to catch cases where we are gazumped.
 */
-   ret = i915_gem_object_wait_rendering__nonblocking(obj,
- to_rps_client(file),
- !write_domain);
+   ret = __unsafe_wait_rendering(obj, to_rps_client(file), !write_domain);
+   if (ret)
+   goto err;
+
+   ret = i915_mutex_lock_interruptible(dev);
if (ret)
-   goto unref;
+   goto err;
 
if (read_domains & I915_GEM_DOMAIN_GTT)
  

[Intel-gfx] [PATCH 01/19] drm/i915: Introduce i915_gem_active_wait_unlocked()

[Chris Wilson]

It is useful to be able to wait on pending rendering without grabbing
the struct_mutex. We can do this by using the i915_gem_active_get_rcu()
primitive to acquire a reference to the pending request without
requiring struct_mutex, just the RCU read lock, and then call
i915_wait_request().

v2: Rebase onto new i915_gem_active_get_unlocked() semantics that take
the RCU read lock on behalf of the caller.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.h | 40 +
 1 file changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 6002adc43523..15495d1e48e8 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -569,6 +569,46 @@ i915_gem_active_wait(const struct i915_gem_active *active, 
struct mutex *mutex)
 }
 
 /**
+ * i915_gem_active_wait_unlocked - waits until the request is completed
+ * @active - the active request on which to wait
+ * @interruptible - whether the wait can be woken by a userspace signal
+ * @timeout - how long to wait at most
+ * @rps - userspace client to charge for a waitboost
+ *
+ * i915_gem_active_wait_unlocked() waits until the request is completed before
+ * returning, without requiring any locks to be held. Note that it does not
+ * retire any requests before returning.
+ *
+ * This function relies on RCU in order to acquire the reference to the active
+ * request without holding any locks. See __i915_gem_active_get_rcu() for the
+ * glory details on how that is managed. Once the reference is acquired, we
+ * can then wait upon the request, and afterwards release our reference,
+ * free of any locking.
+ *
+ * This function wraps i915_wait_request(), see it for the full details on
+ * the arguments.
+ *
+ * Returns 0 if successful, or a negative error code.
+ */
+static inline int
+i915_gem_active_wait_unlocked(const struct i915_gem_active *active,
+ bool interruptible,
+ s64 *timeout,
+ struct intel_rps_client *rps)
+{
+   struct drm_i915_gem_request *request;
+   int ret = 0;
+
+   request = i915_gem_active_get_unlocked(active);
+   if (request) {
+   ret = i915_wait_request(request, interruptible, timeout, rps);
+   i915_gem_request_put(request);
+   }
+
+   return ret;
+}
+
+/**
  * i915_gem_active_retire - waits until the request is retired
  * @active - the active request on which to wait
  *
-- 
2.8.1

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

[Intel-gfx] Using RCU requests, take 2

[Chris Wilson]

Joonas has gone through this series once and now hopefully this captures
his feedback. Join in, have fun!
-Chris

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

Re: [Intel-gfx] linux-firmware-i915 pull request (bxt dmc, kbl dmc)

[David Weinehall]

On Wed, Aug 03, 2016 at 03:48:02PM +, Vivi, Rodrigo wrote:
> On Wed, 2016-08-03 at 17:26 +0200, Daniel Vetter wrote:
> > On Wed, Aug 3, 2016 at 5:12 PM, Vivi, Rodrigo  > > wrote:
> > > 
> > > 
> > > But we know that 1.23 is bad and cause issues regardless the kernel
> > > version. And please keep in mind this is the most common case.
> > > Usually a previous minor version was dropped in favor of a new one
> > > because we found a bug that got fixed in a following minor version.
> > > This is the minor version idea. So regardless the kernel version,
> > > the
> > > newest minor is probably safest than the previous one.
> > > 
> > > So, I don't want to keep all versions in linux-firmware.git,
> > > specially
> > > those that we know that cause bad issues.
> > > 
> > > And here is the case were only symbolic link would help imho.
> > If a system goes from "mostly works" to "fails because DMC isn't
> > there
> > any more" then that's a regression. Which means we _must_ resstore
> > 1.23.
> 
> From what I can remember it causes GPU Hangs depending on what you are
> running on the GPU.

Sounds like we should submit a fix to stable that makes the minimum
required version 1.26 if that's indeed the case. I wonder if this
the cause of all the hangs I've seen on my Skylake laptop lately;
I have both 1.23 and 1.26 installed, so I hadn't noticed that it's
loading 1.23 instead of 1.26.


Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

[David Weinehall]

On Tue, Aug 02, 2016 at 04:09:49PM +0200, Daniel Vetter wrote:
> On Mon, Aug 01, 2016 at 11:18:15PM +0530, Kamble, Sagar A wrote:
> > Reviewed-by: Sagar Arun Kamble  > >
> 
> You're mailer wreaks havoc with your reviewed-by tags. Pleas fix this.
> 
> 
> > On 6/27/2016 8:10 PM, akash.g...@intel.com wrote:
> > > From: Akash Goel 
> > > 
> > > Updated the i915_drpc_info debugfs with coarse power gating & forcewake
> > > info for Gen9.
> > > 
> > > v2: Change all IS_GEN9() by gen >= 9 (Damien)

For future reference, please use IS_GEN(dev_priv) >= 9 for expressions
such as this. My bad for not spotting this until the patch got merged.
Fret not, however, I've got a few patches that'll clean this up :)


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

[Intel-gfx] [PATCH] drm/i915/bxt: Bring MIPI out of reset

[Bob Paauwe]

and power up the DSI regulator when initializing a MIPI display.

Signed-off-by: Bob Paauwe 
---
 drivers/gpu/drm/i915/i915_reg.h  |  8 
 drivers/gpu/drm/i915/intel_dsi.c | 13 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6607aaf..da29d74 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1262,11 +1262,19 @@ enum skl_disp_power_wells {
 #define CHV_TX_DW14(ch, lane) _TXLANE(ch, lane, 0xb8)
 #define   DPIO_UPAR_SHIFT  30
 
+/* BXT DSI Regulator registers */
+#define BXT_DSI_CFG_MMIO(0x160020)
+#define   STRAP_SELECT (1 << 0)
+
+#define BXT_DSI_TXCNTRL_MMIO(0x160054)
+#define   HS_IO_CONTROL_SELECT 0x0
+
 /* BXT PHY registers */
 #define _BXT_PHY(phy, a, b)_MMIO_PIPE((phy), (a), (b))
 
 #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
 #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
+#define   MIPIO_RST_CTRL(1 << 2)
 
 #define _PHY_CTL_FAMILY_EDP0x64C80
 #define _PHY_CTL_FAMILY_DDI0x64C90
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b2d2cba..c2aa9e1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -549,6 +549,19 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
I915_WRITE(DSPCLK_GATE_D, tmp);
}
 
+   if (IS_BROXTON(dev)) {
+   /*
+* Bring the MIPI IO out of reset and power up
+* the DSI regulator.
+*/
+   tmp = I915_READ(BXT_P_CR_GT_DISP_PWRON);
+   tmp |= MIPIO_RST_CTRL;
+   I915_WRITE(BXT_P_CR_GT_DISP_PWRON, tmp);
+
+   I915_WRITE(BXT_DSI_CFG, STRAP_SELECT);
+   I915_WRITE(BXT_DSI_TXCNTRL, HS_IO_CONTROL_SELECT);
+   }
+
/* put device in ready state */
intel_dsi_device_ready(encoder);
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

[Takashi Iwai]

On Thu, 04 Aug 2016 18:44:11 +0200,
Daniel Vetter wrote:
> 
> On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote:
> > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display
> > power well and so the sna-hda audio codec acquires the display power
> > well while it is operational. However, Skylake separates the powerwells
> > again, but yet we still need the audio powerwell to setup the registers.
> > (But then the hardware uses those registers even while powered off???)
> 
> Yeah feels fishy, but will at least duct-tape over the breakage from the
> audio side. Most likely the reg writes go exactly nowhere and there's a
> bug on the audio side. And this patch doesn't fix that.

Well, if the relevant code paths are only over these callbacks, I
guess the following fix would work instead.

Can anyone check?


Takashi

---
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 89dacf9b4e6c..88ad391452ae 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1021,8 +1021,8 @@ static int azx_runtime_resume(struct device *dev)
snd_hdac_i915_set_bclk(bus);
} else {
/* toggle codec wakeup bit for STATESTS read */
-   snd_hdac_set_codec_wakeup(bus, true);
-   snd_hdac_set_codec_wakeup(bus, false);
+   snd_hdac_display_power(bus, true);
+   snd_hdac_display_power(bus, false);
}
}
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Takashi Iwai]

On Thu, 04 Aug 2016 19:35:16 +0200,
Ville Syrjälä wrote:
> 
> On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote:
> > On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > DP MST provides the capability to send multiple video and audio streams 
> > > > via
> > > > one single port. This requires the API's between i915 and audio drivers 
> > > > to
> > > > distinguish between audio capable displays connected to a port. This 
> > > > patch
> > > > adds this support via an additional parameter 'int dev_id'. The existing
> > > > parameter 'port' does not change it's meaning.
> > > > 
> > > > dev_id =
> > > > MST : pipe that the stream originates from
> > > > Non-MST : -1
> > > > 
> > > > Affected APIs:
> > > > struct i915_audio_component_ops
> > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > > 
> > > Does the term 'dev_id' have some special meaning on the audio side? On
> > > the i915 side things would be less confusing if we just called it
> > > 'pipe'.
> > 
> > Yeah, it does.  All of the documentation on the audio side is written
> > in terms of device ID, so they asked for that nomenclature.
> 
> And is the device ID always the same as the pipe? Until now we've made
> due with passing the port instead of the pipe, so either the audio side
> didn't use the device ID, or its meaning changes based on how we drive
> things, or they dug it out from somewhere else based on the port?

This is my concern, too.  Currently we have a very wild assumption
even for the port mapping.  In the audio side, there is neither port
nor pipe.  There are only the widget node id and the device id.  The
former is supposedly corresponding to the port, and the latter to the
pipe.  But the audio side has absolutely no clue about how these are
connected.


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

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Ville Syrjälä]

On Thu, Aug 04, 2016 at 10:18:52AM -0700, Jim Bride wrote:
> On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > DP MST provides the capability to send multiple video and audio streams 
> > > via
> > > one single port. This requires the API's between i915 and audio drivers to
> > > distinguish between audio capable displays connected to a port. This patch
> > > adds this support via an additional parameter 'int dev_id'. The existing
> > > parameter 'port' does not change it's meaning.
> > > 
> > > dev_id =
> > >   MST : pipe that the stream originates from
> > >   Non-MST : -1
> > > 
> > > Affected APIs:
> > > struct i915_audio_component_ops
> > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > + int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > 
> > Does the term 'dev_id' have some special meaning on the audio side? On
> > the i915 side things would be less confusing if we just called it
> > 'pipe'.
> 
> Yeah, it does.  All of the documentation on the audio side is written
> in terms of device ID, so they asked for that nomenclature.

And is the device ID always the same as the pipe? Until now we've made
due with passing the port instead of the pipe, so either the audio side
didn't use the device ID, or its meaning changes based on how we drive
things, or they dug it out from somewhere else based on the port?

> 
> Jim
> 
> 
> > > +  int rate);
> > > 
> > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > -   unsigned char *buf, int max_bytes);
> > > +   int (*get_eld)(struct device *, int port, int dev_id,
> > > +bool *enabled, unsigned char *buf, int max_bytes);
> > > 
> > > struct i915_audio_component_audio_ops
> > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > > 
> > > This patch makes dummy changes in the audio drivers for build to succeed.
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> > >  drivers/gpu/drm/i915/intel_audio.c | 82 
> > > +-
> > >  include/drm/i915_component.h   |  6 +--
> > >  include/sound/hda_i915.h   | 11 ++---
> > >  sound/hda/hdac_i915.c  |  9 +++--
> > >  sound/pci/hda/patch_hdmi.c |  7 ++--
> > >  6 files changed, 82 insertions(+), 35 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 65ada5d..8e4c8c8 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > >   /* perform PHY state sanity checks? */
> > >   bool chv_phy_assert[2];
> > >  
> > > - struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > > + struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> > >  
> > >   /*
> > >* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > > b/drivers/gpu/drm/i915/intel_audio.c
> > > index 8c493de..cbe44c8 100644
> > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > @@ -500,6 +500,9 @@ void intel_audio_codec_enable(struct intel_encoder 
> > > *intel_encoder)
> > >   struct i915_audio_component *acomp = dev_priv->audio_component;
> > >   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > >   enum port port = intel_dig_port->port;
> > > + enum pipe pipe = crtc->pipe;
> > > + int dev_id = -1;
> > > +
> > >  
> > >   connector = drm_select_eld(encoder);
> > >   if (!connector)
> > > @@ -522,14 +525,19 @@ void intel_audio_codec_enable(struct intel_encoder 
> > > *intel_encoder)
> > >   dev_priv->display.audio_codec_enable(connector, intel_encoder,
> > >adjusted_mode);
> > >  
> > > + if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > > + dev_id = pipe;
> > > +
> > >   mutex_lock(_priv->av_mutex);
> > >   intel_encoder->audio_connector = connector;
> > > +
> > >   /* referred in audio callbacks */
> > > - dev_priv->dig_port_map[port] = intel_encoder;
> > > + dev_priv->av_enc_map[pipe] = intel_encoder;
> > >   mutex_unlock(_priv->av_mutex);
> > >  
> > >   if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > > - acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> > > (int) port);
> > > + acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > > +  (int) port, dev_id);
> > >  }
> > >  
> > >  /**
> > > @@ -542,22 +550,29 @@ void intel_audio_codec_enable(struct intel_encoder 
> > > *intel_encoder)
> > >  void intel_audio_codec_disable(struct intel_encoder *intel_encoder)

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Jim Bride]

On Wed, Aug 03, 2016 at 10:08:12PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > DP MST provides the capability to send multiple video and audio streams via
> > one single port. This requires the API's between i915 and audio drivers to
> > distinguish between audio capable displays connected to a port. This patch
> > adds this support via an additional parameter 'int dev_id'. The existing
> > parameter 'port' does not change it's meaning.
> > 
> > dev_id =
> > MST : pipe that the stream originates from
> > Non-MST : -1
> > 
> > Affected APIs:
> > struct i915_audio_component_ops
> > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> 
> Does the term 'dev_id' have some special meaning on the audio side? On
> the i915 side things would be less confusing if we just called it
> 'pipe'.

Yeah, it does.  All of the documentation on the audio side is written
in terms of device ID, so they asked for that nomenclature.

Jim


> > +int rate);
> > 
> > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > -   unsigned char *buf, int max_bytes);
> > +   int (*get_eld)(struct device *, int port, int dev_id,
> > +  bool *enabled, unsigned char *buf, int max_bytes);
> > 
> > struct i915_audio_component_audio_ops
> > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > +   void (*pin_eld_notify)(void *audio_ptr, int port, int dev_id);
> > 
> > This patch makes dummy changes in the audio drivers for build to succeed.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> >  drivers/gpu/drm/i915/intel_audio.c | 82 
> > +-
> >  include/drm/i915_component.h   |  6 +--
> >  include/sound/hda_i915.h   | 11 ++---
> >  sound/hda/hdac_i915.c  |  9 +++--
> >  sound/pci/hda/patch_hdmi.c |  7 ++--
> >  6 files changed, 82 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 65ada5d..8e4c8c8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2054,7 +2054,7 @@ struct drm_i915_private {
> > /* perform PHY state sanity checks? */
> > bool chv_phy_assert[2];
> >  
> > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> >  
> > /*
> >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 8c493de..cbe44c8 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -500,6 +500,9 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = crtc->pipe;
> > +   int dev_id = -1;
> > +
> >  
> > connector = drm_select_eld(encoder);
> > if (!connector)
> > @@ -522,14 +525,19 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> > dev_priv->display.audio_codec_enable(connector, intel_encoder,
> >  adjusted_mode);
> >  
> > +   if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
> > +   dev_id = pipe;
> > +
> > mutex_lock(_priv->av_mutex);
> > intel_encoder->audio_connector = connector;
> > +
> > /* referred in audio callbacks */
> > -   dev_priv->dig_port_map[port] = intel_encoder;
> > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> > mutex_unlock(_priv->av_mutex);
> >  
> > if (acomp && acomp->audio_ops && acomp->audio_ops->pin_eld_notify)
> > -   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr, 
> > (int) port);
> > +   acomp->audio_ops->pin_eld_notify(acomp->audio_ops->audio_ptr,
> > +(int) port, dev_id);
> >  }
> >  
> >  /**
> > @@ -542,22 +550,29 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder)
> >  void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
> >  {
> > struct drm_encoder *encoder = _encoder->base;
> > +   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > struct drm_device *dev = encoder->dev;
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
> > enum port port = intel_dig_port->port;
> > +   enum pipe pipe = crtc->pipe;
> > +   int dev_id = -1;
> > +
> > 

Re: [Intel-gfx] [PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

[ch...@chris-wilson.co.uk]

On Thu, Aug 04, 2016 at 04:50:35PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote:
> > On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote:
> > > The causes of clock recovery and channel equalization failures are not
> > > explicitly printed in debug messages. Help debugging link training
> > > failures by printing why it failed.
> > > 
> > > Doing this in the driver would mean re-implementing some of the drm static
> > > functions that decode link status. Let's avoid that with these debug
> > > messages in drm.
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 12 +---
> > >  1 file changed, 9 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 091053e..d763b57 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -64,12 +64,16 @@ bool drm_dp_channel_eq_ok(const u8 
> > > link_status[DP_LINK_STATUS_SIZE],
> > >  
> > >   lane_align = dp_link_status(link_status,
> > >   DP_LANE_ALIGN_STATUS_UPDATED);
> > > - if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
> > > + if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0) {
> > > + DRM_DEBUG_KMS("Inter-lane alignment not done\n");
> > >   return false;
> > > + }
> > >   for (lane = 0; lane < lane_count; lane++) {
> > >   lane_status = dp_get_lane_status(link_status, lane);
> > > - if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS)
> > > + if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS) {
> > > + DRM_DEBUG_KMS("Channel equalization not done for lane 
> > > %d\n", lane);
> > >   return false;
> > > + }
> > >   }
> > >   return true;
> > >  }
> > > @@ -83,8 +87,10 @@ bool drm_dp_clock_recovery_ok(const u8 
> > > link_status[DP_LINK_STATUS_SIZE],
> > >  
> > >   for (lane = 0; lane < lane_count; lane++) {
> > >   lane_status = dp_get_lane_status(link_status, lane);
> > > - if ((lane_status & DP_LANE_CR_DONE) == 0)
> > > + if ((lane_status & DP_LANE_CR_DONE) == 0) {
> > > + DRM_DEBUG_KMS("Clock recovery not done for lane %d\n", 
> > > lane);
> > 
> > Please petition, with patch, for DRM_DEBUG_DP.
> > 
> Is that because DRM_DEBUG_KMS in not appropriate or that we have plenty
> of DP related debug messages that it warrants it's own debug macro?

In the case of link failure, we will have plenty of messages from DP.
One debug category just for DP may be overkill, and we may want
something more like DRM_DEBUG_KMS_LOWLEVEL (or DRM_DEBUG_KMS_DRIVER, or
DRM_DEBUG_KMS_HW etc) that suits all similar link training without
cluttering up either the high levels telling what the user selected, and
what the driver picked and the control flow through the modesetting.
-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] ✗ Ro.CI.BAT: failure for drm: Paper over locking inversion after registration rework (rev2)

[Patchwork]

== Series Details ==

Series: drm: Paper over locking inversion after registration rework (rev2)
URL   : https://patchwork.freedesktop.org/series/10653/
State : failure

== Summary ==

Series 10653v2 drm: Paper over locking inversion after registration rework
http://patchwork.freedesktop.org/api/1.0/series/10653/revisions/2/mbox

Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-snb-i7-2600)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-bdw-i7-5600u)
fail   -> PASS   (ro-bdw-i5-5250u)
fail   -> DMESG-FAIL (fi-skl-i7-6700k)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> DMESG-FAIL (fi-skl-i7-6700k)
pass   -> FAIL   (ro-snb-i7-2620M)
pass   -> FAIL   (ro-bdw-i5-5250u)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (ro-byt-n2820)
pass   -> FAIL   (ro-bdw-i7-5600u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)

fi-hsw-i7-4770k  total:240  pass:218  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-qkkr  total:240  pass:181  dwarn:27  dfail:2   fail:3   skip:27 
fi-skl-i5-6260u  total:240  pass:220  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:204  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:240  pass:197  dwarn:0   dfail:0   fail:0   skip:43 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:5   dfail:0   fail:1   skip:16 
ro-bdw-i7-5557U  total:240  pass:223  dwarn:1   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:240  pass:205  dwarn:1   dfail:0   fail:2   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:172  dwarn:1   dfail:0   fail:2   skip:65 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:1   dfail:0   fail:3   skip:14 
ro-snb-i7-2620M  total:240  pass:197  dwarn:0   dfail:0   fail:2   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1717/

8b0dfb8 drm-intel-nightly: 2016y-08m-04d-13h-05m-22s UTC integration manifest
9496c6e drm: Paper over locking inversion after registration rework

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable stolen on 865G

[Chris Wilson]

On Thu, Aug 04, 2016 at 07:44:14PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 04, 2016 at 06:31:21PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 10:56:04AM +0100, Chris Wilson wrote:
> > > It appears our calculation for the address of stolen memory is incorrect
> > > for 865G, so for the time being disable our use of that memory.
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
> > > Fixes: 0ad98c74e093 ("drm/i915: Deatermine the stolen memory base 
> > > address...")
> > > Signed-off-by: Chris Wilson 
> > > Cc: Ville Syrjälä 
> > > Cc: Daniel Vetter 
> > > Cc: sta...@vger.kernel.org
> > 
> > Acked-by: Daniel Vetter 
> 
> There's a potentially better patch (one that actually fixes the stolen
> base calculation) attached to the bug.

Yup, holding off on this and thanks for the patch :)
-Chris

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: Add debug messages to print DP link training pattern

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 04:07 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 08:07:38PM -0700, Dhinakaran Pandiyan wrote:
> > @@ -2588,7 +2592,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > *DP |= DP_LINK_TRAIN_PAT_2_CPT;
> > break;
> > case DP_TRAINING_PATTERN_3:
> > -   DRM_ERROR("DP training pattern 3 not supported\n");
> > +   DRM_ERROR("TPS3 not supported, using TPS2 instead\n");
> > *DP |= DP_LINK_TRAIN_PAT_2_CPT;
> > break;
> > }
> > @@ -2613,7 +2617,7 @@ _intel_dp_set_link_train(struct intel_dp *intel_dp,
> > if (IS_CHERRYVIEW(dev)) {
> > *DP |= DP_LINK_TRAIN_PAT_3_CHV;
> > } else {
> > -   DRM_ERROR("DP training pattern 3 not 
> > supported\n");
> > +   DRM_ERROR("TPS3 not supported, using TPS2 
> > instead\n");
> > *DP |= DP_LINK_TRAIN_PAT_2;
> 
> Given that you have a fallback plan and if the fallback plan fails you
> alert the user with an error already, these aren't errors but debug.
> -Chris
> 
I will make that change. Thanks for the review.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/dp: Clarify clock recovery and channel equalization failures

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote:
> On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote:
> > The causes of clock recovery and channel equalization failures are not
> > explicitly printed in debug messages. Help debugging link training
> > failures by printing why it failed.
> > 
> > Doing this in the driver would mean re-implementing some of the drm static
> > functions that decode link status. Let's avoid that with these debug
> > messages in drm.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 091053e..d763b57 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -64,12 +64,16 @@ bool drm_dp_channel_eq_ok(const u8 
> > link_status[DP_LINK_STATUS_SIZE],
> >  
> > lane_align = dp_link_status(link_status,
> > DP_LANE_ALIGN_STATUS_UPDATED);
> > -   if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0)
> > +   if ((lane_align & DP_INTERLANE_ALIGN_DONE) == 0) {
> > +   DRM_DEBUG_KMS("Inter-lane alignment not done\n");
> > return false;
> > +   }
> > for (lane = 0; lane < lane_count; lane++) {
> > lane_status = dp_get_lane_status(link_status, lane);
> > -   if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS)
> > +   if ((lane_status & DP_CHANNEL_EQ_BITS) != DP_CHANNEL_EQ_BITS) {
> > +   DRM_DEBUG_KMS("Channel equalization not done for lane 
> > %d\n", lane);
> > return false;
> > +   }
> > }
> > return true;
> >  }
> > @@ -83,8 +87,10 @@ bool drm_dp_clock_recovery_ok(const u8 
> > link_status[DP_LINK_STATUS_SIZE],
> >  
> > for (lane = 0; lane < lane_count; lane++) {
> > lane_status = dp_get_lane_status(link_status, lane);
> > -   if ((lane_status & DP_LANE_CR_DONE) == 0)
> > +   if ((lane_status & DP_LANE_CR_DONE) == 0) {
> > +   DRM_DEBUG_KMS("Clock recovery not done for lane %d\n", 
> > lane);
> 
> Please petition, with patch, for DRM_DEBUG_DP.
> -Chris
> 
Is that because DRM_DEBUG_KMS in not appropriate or that we have plenty
of DP related debug messages that it warrants it's own debug macro?

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915/dp: Dump DP link status when link training stages fails

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 10:46 +0300, Jani Nikula wrote:
> On Thu, 04 Aug 2016, Dhinakaran Pandiyan  
> wrote:
> > A full dump of link status can be handy in debugging link training
> > failures. Let's add that to the debug messages when link training fails.
> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++
> >  drivers/gpu/drm/i915/intel_drv.h  |  6 --
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index c0a858d..ab7d1a6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -24,6 +24,15 @@
> >  #include "intel_drv.h"
> >  
> >  static void
> > +intel_dp_dump_link_status(const uint8_t link_status[DP_LINK_STATUS_SIZE])
> > +{
> > +
> > +   DRM_DEBUG_KMS("ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x 
> > adj_req0_1:0x%x adj_req2_3:0x%x",
> > + link_status[0], link_status[1], link_status[2],
> > + link_status[3], link_status[4], link_status[5]);
> > +}
> > +
> > +static void
> >  intel_get_adjust_train(struct intel_dp *intel_dp,
> >const uint8_t link_status[DP_LINK_STATUS_SIZE])
> >  {
> > @@ -170,6 +179,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
> > *intel_dp)
> > ++loop_tries;
> > if (loop_tries == 5) {
> > DRM_ERROR("too many full retries, give up\n");
> > +   intel_dp_dump_link_status(link_status);
> > break;
> > }
> > intel_dp_reset_link_train(intel_dp,
> > @@ -257,6 +267,7 @@ intel_dp_link_training_channel_equalization(struct 
> > intel_dp *intel_dp)
> >  
> > if (cr_tries > 5) {
> > DRM_ERROR("failed to train DP, aborting\n");
> > +   intel_dp_dump_link_status(link_status);
> > break;
> > }
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 87069ba..549a8fd 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1356,8 +1356,6 @@ bool intel_dp_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> >  struct intel_connector *intel_connector);
> >  void intel_dp_set_link_params(struct intel_dp *intel_dp,
> >   const struct intel_crtc_state *pipe_config);
> > -void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > -void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> >  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> >  void intel_dp_encoder_reset(struct drm_encoder *encoder);
> >  void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
> > @@ -1409,6 +1407,10 @@ static inline unsigned int 
> > intel_dp_unused_lane_mask(int lane_count)
> > return ~((1 << lane_count) - 1) & 0xf;
> >  }
> >  
> > +/* intel_dp_link_training.c */
> > +void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > +void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> 
> Unrelated cleanup change. Should be a (standalone) separate patch, and
> if it were, it could have been merged already.
> 
> Pro-tip: In general, you'll want to organize your series in a way that
> allows the early patches to be merged even when the review rounds are
> still in progress on the later patches. Crucial fixes first (so they can
> be backported without conflicts), trivial and non-controversial things
> next, and so on. You'll have a feeling of making progress, you'll have
> fewer rebases and conflicts later on, and it'll be easier for the
> reviewers too as the number of patches in later versions shrinks.
> 
> BR,
> Jani.
> 

Thanks for the tip Jani, will keep that in mind. I will split this patch
when I send the next version of the series.
> > +
> >  /* intel_dp_aux_backlight.c */
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> > *intel_connector);
> 

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Thu, 2016-08-04 at 15:49 +0300, Ville Syrjälä wrote:
> On Wed, Aug 03, 2016 at 09:42:53PM +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2016-08-03 at 23:28 +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 03, 2016 at 07:43:06PM +, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2016-08-03 at 22:08 +0300, Ville Syrjälä wrote:
> > > > > On Tue, Aug 02, 2016 at 07:14:30PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > DP MST provides the capability to send multiple video and audio 
> > > > > > streams via
> > > > > > one single port. This requires the API's between i915 and audio 
> > > > > > drivers to
> > > > > > distinguish between audio capable displays connected to a port. 
> > > > > > This patch
> > > > > > adds this support via an additional parameter 'int dev_id'. The 
> > > > > > existing
> > > > > > parameter 'port' does not change it's meaning.
> > > > > > 
> > > > > > dev_id =
> > > > > > MST : pipe that the stream originates from
> > > > > > Non-MST : -1
> > > > > > 
> > > > > > Affected APIs:
> > > > > > struct i915_audio_component_ops
> > > > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > > > +   int (*sync_audio_rate)(struct device *, int port, int dev_id,
> > > > > 
> > > > > Does the term 'dev_id' have some special meaning on the audio side? On
> > > > > the i915 side things would be less confusing if we just called it
> > > > > 'pipe'.
> > > > > 
> > > > 
> > > > There was quite a bit of back and forth on this. "pipe" seemed to tie us
> > > > to the gfx hardware architecture. In case, there is no 1:1 mapping from
> > > > pipes to encoders, this will get confusing as i915 audio registers
> > > > (E.g.HSW_AUD_PIN_ELD_CP_VLD) are encoder based.
> > > 
> > > I'm not following. Looking at the current i915 audio code, on HSW+
> > > everything is pipe based.
> > > 
> > Although we pass "pipe" to these macros, the definition here and in the
> > BSpec seem to indicate they are based on the encoder.
> > 
> > Eg: #define HSW_AUD_PIN_ELD_CP_VLD  _MMIO(0x650c0)
> > #define   AUDIO_INACTIVE(trans) ((1 << 3) << ((trans) * 4))
> > #define   AUDIO_OUTPUT_ENABLE(trans)((1 << 2) << ((trans) * 4))
> > #define   AUDIO_CP_READY(trans) ((1 << 1) << ((trans) * 4))
> > #define   AUDIO_ELD_VALID(trans)((1 << 0) << ((trans) * 4))
> 
> That's transcoder, not encoder. transcoder is the tail end of the pipe.
> For all the external ports transcoder==pipe, and for port A there is the
> special edp transcoder which can be fed by any pipe. The edp transcoder
> doesn't support audio though, and I can't see anything in the spec to
> suggest that it would gain audio capabilities, in the near future at
> least. So from that point of view passing around the pipe would seem
> like a safe approach.
> 
> We could of course pass around transcoder instead of pipe. Since we
> don't ever need to enable audio on the edp transcoder, we don't even
> have to worry about what number we assign to it. And hence it is
> actually the same as passing the pipe, except in name.
> 

Thanks for the detailed explanation, makes sense to change it to "pipe".
I will send out a new version. Do you recommend I send this patch with 
"Prep. for DP audio MST support" series
(https://lists.freedesktop.org/archives/intel-gfx/2016-August/102399.html)? 
This patch depends on the some of the patches in that. I had separated this 
patch out because of the audio driver changes in this.
> > 
> > 
> > > > Whereas, dev_id is
> > > > generic - HDA spec calls them "devices" or "device entry"
> > > 
> > > Generic and totally unclear what it means from graphics side.
> > > 
> > > pipe and port are the only things we really have in i915. If those aren't
> > > good enough for the audio side, then I think we should have some decent
> > > code to remap between the pipe+port vs. whatever audio side id is needed.
> > > I don't really care on which side of the border such code would live, as
> > > long as it's clear what it's doing.
> > > 
> > 
> > I agree, dev_id can be misleading within i915.
> > > > 
> > > > > > +int rate);
> > > > > > 
> > > > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > > > -   unsigned char *buf, int max_bytes);
> > > > > > +   int (*get_eld)(struct device *, int port, int dev_id,
> > > > > > +  bool *enabled, unsigned char *buf, int 
> > > > > > max_bytes);
> > > > > > 
> > > > > > struct i915_audio_component_audio_ops
> > > > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int 
> > > > > > dev_id);
> > > > > > 
> > > > > > This patch makes dummy changes in the audio drivers for build to 
> > > > > > succeed.
> > > > > > 
> > > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/i915_drv.h|  2 +-
> > > > > >  

Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers

[Daniel Vetter]

On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote:
> On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display
> power well and so the sna-hda audio codec acquires the display power
> well while it is operational. However, Skylake separates the powerwells
> again, but yet we still need the audio powerwell to setup the registers.
> (But then the hardware uses those registers even while powered off???)

Yeah feels fishy, but will at least duct-tape over the breakage from the
audio side. Most likely the reg writes go exactly nowhere and there's a
bug on the audio side. And this patch doesn't fix that.

But it does what it says on the tin, and it gets the job done.

Reviewed-by: Daniel Vetter 
> 
> v2: Grab both rpm wakelock and audio wakelock
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214
> Fixes: 03b135cebc47 "ALSA: hda - remove dependency on i915 power well for 
> SKL")
> Signed-off-by: Chris Wilson 
> Cc: Libin Yang 
> Cc: Takashi Iwai 
> Cc: Marius Vlad 
> Tested-by: Hans de Goede 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 5d5f6bc10e85..948a7a52e3f8 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -600,6 +600,8 @@ static void 
> i915_audio_component_codec_wake_override(struct device *dev,
>   if (!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv))
>   return;
>  
> + i915_audio_component_get_power(dev);
> +
>   /*
>* Enable/disable generating the codec wake signal, overriding the
>* internal logic to generate the codec wake to controller.
> @@ -615,6 +617,8 @@ static void 
> i915_audio_component_codec_wake_override(struct device *dev,
>   I915_WRITE(HSW_AUD_CHICKENBIT, tmp);
>   usleep_range(1000, 1500);
>   }
> +
> + i915_audio_component_put_power(dev);
>  }
>  
>  /* Get CDCLK in kHz  */
> @@ -648,6 +652,7 @@ static int i915_audio_component_sync_audio_rate(struct 
> device *dev,
>   !IS_HASWELL(dev_priv))
>   return 0;
>  
> + i915_audio_component_get_power(dev);
>   mutex_lock(_priv->av_mutex);
>   /* 1. get the pipe */
>   intel_encoder = dev_priv->dig_port_map[port];
> @@ -698,6 +703,7 @@ static int i915_audio_component_sync_audio_rate(struct 
> device *dev,
>  
>   unlock:
>   mutex_unlock(_priv->av_mutex);
> + i915_audio_component_put_power(dev);
>   return err;
>  }
>  
> -- 
> 2.8.1
> 
> ___
> 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

Re: [Intel-gfx] [PATCH] drm/i915: Disable stolen on 865G

[Ville Syrjälä]

On Thu, Aug 04, 2016 at 06:31:21PM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 10:56:04AM +0100, Chris Wilson wrote:
> > It appears our calculation for the address of stolen memory is incorrect
> > for 865G, so for the time being disable our use of that memory.
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
> > Fixes: 0ad98c74e093 ("drm/i915: Deatermine the stolen memory base 
> > address...")
> > Signed-off-by: Chris Wilson 
> > Cc: Ville Syrjälä 
> > Cc: Daniel Vetter 
> > Cc: sta...@vger.kernel.org
> 
> Acked-by: Daniel Vetter 

There's a potentially better patch (one that actually fixes the stolen
base calculation) attached to the bug.

> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index e1791fe96674..8b501ddbc784 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -122,6 +122,7 @@ static unsigned long i915_stolen_to_physical(struct 
> > drm_device *dev)
> >  * always at TOUD? Ie. is it always the last
> >  * one to be allocated by the BIOS?
> >  */
> > +   if (0) /* https://bugs.freedesktop.org/show_bug.cgi?id=96473 */
> > pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
> >  I865_TOUD, );
> >  
> > -- 
> > 2.8.1
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

[Daniel Vetter]

On Thu, Aug 04, 2016 at 09:31:20AM +0300, Jani Nikula wrote:
> On Wed, 03 Aug 2016, Chris Wilson  wrote:
> > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled
> >
> > "Display flickering may occur when both FBC (Frame Buffer Compression)
> > and VT - d (Intel® Virtualization Technology for Directed I/O) are enabled
> > and in use by the display controller."
> >
> > Ville found the w/a name in the database:
> > WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl
> >
> > v2: Log when the quirk is applied.
> > v3: Ensure i915.enable_fbc is false when !HAS_FBC()
> > v4: Fix function name after rebase
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Paulo Zanoni 
> > Cc: Ville Syrjälä 
> 
> Cc: sta...@vger.kernel.org

fbc isn't enabled by default, so imo no.
-Daniel

> 
> ?
> 
> > ---
> >  drivers/gpu/drm/i915/intel_fbc.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 8147eb9e8475..b673c7c54a46 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1229,12 +1229,28 @@ static int intel_sanitize_fbc_option(struct 
> > drm_i915_private *dev_priv)
> > if (i915.enable_fbc >= 0)
> > return !!i915.enable_fbc;
> >  
> > +   if (!HAS_FBC(dev_priv))
> > +   return 0;
> > +
> > if (IS_BROADWELL(dev_priv))
> > return 1;
> >  
> > return 0;
> >  }
> >  
> > +static bool need_fbc_wa(struct drm_i915_private *dev_priv)
> > +{
> > +#ifdef CONFIG_INTEL_IOMMU
> > +   /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl */
> > +   if (intel_iommu_gfx_mapped && IS_SKYLAKE(dev_priv)) {
> > +   DRM_INFO("Disabling framebuffer compression (FBC) to prevent 
> > screen flicker with VT-d enabled\n");
> > +   return true;
> > +   }
> > +#endif
> > +
> > +   return false;
> > +}
> > +
> >  /**
> >   * intel_fbc_init - Initialize FBC
> >   * @dev_priv: the i915 device
> > @@ -1252,6 +1268,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
> > fbc->active = false;
> > fbc->work.scheduled = false;
> >  
> > +   if (need_fbc_wa(dev_priv))
> > +   mkwrite_device_info(dev_priv)->has_fbc = false;
> > +
> > i915.enable_fbc = intel_sanitize_fbc_option(dev_priv);
> > DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n", i915.enable_fbc);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> 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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Update MOCS tests

[Daniel Vetter]

On Thu, Aug 04, 2016 at 01:54:10PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: Update MOCS tests
> URL   : https://patchwork.freedesktop.org/series/10665/
> State : failure
> 
> == Summary ==
> 
> Applying: igt/gem_mocs_settings: Remove direct register tests
> fatal: sha1 information is lacking or useless (tests/gem_mocs_settings.c).
> error: could not build fake ancestor
> Patch failed at 0001 igt/gem_mocs_settings: Remove direct register tests
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".

rule is that you need a lower-case i-g-t in the patch tag, not upper-case
I-G-T. CI will try to apply to the wrong tree otherwise.
-Daniel

> 
> ___
> 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: Paper over locking inversion after registration rework

[Daniel Vetter]

drm_connector_register_all requires a few too many locks because our
connector_list locking is busted. Add another FIXME+hack to work
around this. This should address the below lockdep splat:

==
[ INFO: possible circular locking dependency detected ]
4.7.0-rc5+ #524 Tainted: G   O
---
kworker/u8:0/6 is trying to acquire lock:
 (>mode_config.mutex){+.+.+.}, at: [] 
drm_modeset_lock_all+0x40/0x120

but task is already holding lock:
 ((fb_notifier_list).rwsem){.+}, at: [] 
__blocking_notifier_call_chain+0x35/0x70

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 ((fb_notifier_list).rwsem){.+}:
   [] lock_acquire+0xb1/0x200
   [] down_write+0x44/0x80
   [] blocking_notifier_chain_register+0x21/0xb0
   [] fb_register_client+0x18/0x20
   [] backlight_device_register+0x136/0x260
   [] intel_backlight_device_register+0xa2/0x160 [i915]
   [] intel_connector_register+0xe/0x10 [i915]
   [] intel_dp_connector_register+0x1b/0x80 [i915]
   [] drm_connector_register+0x4a/0x80
   [] drm_connector_register_all+0x64/0xf0
   [] drm_modeset_register_all+0x174/0x1c0
   [] drm_dev_register+0xc2/0xd0
   [] i915_driver_load+0x1547/0x2200 [i915]
   [] i915_pci_probe+0x4f/0x70 [i915]
   [] local_pci_probe+0x45/0xa0
   [] pci_device_probe+0xdb/0x130
   [] driver_probe_device+0x223/0x440
   [] __driver_attach+0xd5/0x100
   [] bus_for_each_dev+0x66/0xa0
   [] driver_attach+0x1e/0x20
   [] bus_add_driver+0x1ee/0x280
   [] driver_register+0x60/0xe0
   [] __pci_register_driver+0x60/0x70
   [] i915_init+0x5b/0x62 [i915]
   [] do_one_initcall+0x3d/0x150
   [] do_init_module+0x5f/0x1d9
   [] load_module+0x20e6/0x27e0
   [] SYSC_finit_module+0xc3/0xf0
   [] SyS_finit_module+0xe/0x10
   [] entry_SYSCALL_64_fastpath+0x1c/0xac

-> #0 (>mode_config.mutex){+.+.+.}:
   [] __lock_acquire+0x10fc/0x1260
   [] lock_acquire+0xb1/0x200
   [] mutex_lock_nested+0x67/0x3c0
   [] drm_modeset_lock_all+0x40/0x120
   [] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
   [] drm_fb_helper_set_par+0x2d/0x50
   [] intel_fbdev_set_par+0x1a/0x60 [i915]
   [] fbcon_init+0x586/0x610
   [] visual_init+0xca/0x130
   [] do_bind_con_driver+0x1c1/0x3a0
   [] do_take_over_console+0x116/0x180
   [] do_fbcon_takeover+0x57/0xb0
   [] fbcon_event_notify+0x658/0x750
   [] notifier_call_chain+0x3e/0xb0
   [] __blocking_notifier_call_chain+0x4d/0x70
   [] blocking_notifier_call_chain+0x16/0x20
   [] fb_notifier_call_chain+0x1b/0x20
   [] register_framebuffer+0x251/0x330
   [] drm_fb_helper_initial_config+0x25f/0x3f0
   [] intel_fbdev_initial_config+0x18/0x30 [i915]
   [] async_run_entry_fn+0x48/0x150
   [] process_one_work+0x1e7/0x750
   [] worker_thread+0x4b/0x4f0
   [] kthread+0xef/0x110
   [] ret_from_fork+0x1f/0x40

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock((fb_notifier_list).rwsem);
   lock(>mode_config.mutex);
   lock((fb_notifier_list).rwsem);
  lock(>mode_config.mutex);

 *** DEADLOCK ***

6 locks held by kworker/u8:0/6:
 #0:  ("events_unbound"){.+.+.+}, at: [] 
process_one_work+0x169/0x750
 #1:  ((>work)){+.+.+.}, at: [] 
process_one_work+0x169/0x750
 #2:  (registration_lock){+.+.+.}, at: [] 
register_framebuffer+0x27/0x330
 #3:  (console_lock){+.+.+.}, at: [] 
register_framebuffer+0x26e/0x330
 #4:  (_info->lock){+.+.+.}, at: [] lock_fb_info+0x1d/0x40
 #5:  ((fb_notifier_list).rwsem){.+}, at: [] 
__blocking_notifier_call_chain+0x35/0x70

stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G   O4.7.0-rc5+ #524
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS 
APLKRVPA.X64.0138.B33.1606250842 06/25/2016
Workqueue: events_unbound async_run_entry_fn
  8800758577f0 814507a5 828b9900
 828b9900 880075857830 810dc6fa 880075857880
 88007584d688 0005 0006 88007584d6b0
Call Trace:
 [] dump_stack+0x67/0x92
 [] print_circular_bug+0x1aa/0x200
 [] __lock_acquire+0x10fc/0x1260
 [] lock_acquire+0xb1/0x200
 [] ? drm_modeset_lock_all+0x40/0x120
 [] ? drm_modeset_lock_all+0x40/0x120
 [] mutex_lock_nested+0x67/0x3c0
 [] ? drm_modeset_lock_all+0x40/0x120
 [] ? rcu_read_lock_sched_held+0x7f/0x90
 [] ? kmem_cache_alloc_trace+0x248/0x2b0
 [] ? drm_modeset_lock_all+0x25/0x120
 [] drm_modeset_lock_all+0x40/0x120
 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
 [] drm_fb_helper_set_par+0x2d/0x50
 [] intel_fbdev_set_par+0x1a/0x60 [i915]
 [] fbcon_init+0x586/0x610
 [] visual_init+0xca/0x130
 [] 

Re: [Intel-gfx] [PATCH] drm/i915: Disable stolen on 865G

[Daniel Vetter]

On Thu, Aug 04, 2016 at 10:56:04AM +0100, Chris Wilson wrote:
> It appears our calculation for the address of stolen memory is incorrect
> for 865G, so for the time being disable our use of that memory.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
> Fixes: 0ad98c74e093 ("drm/i915: Deatermine the stolen memory base address...")
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Cc: sta...@vger.kernel.org

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index e1791fe96674..8b501ddbc784 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -122,6 +122,7 @@ static unsigned long i915_stolen_to_physical(struct 
> drm_device *dev)
>* always at TOUD? Ie. is it always the last
>* one to be allocated by the BIOS?
>*/
> + if (0) /* https://bugs.freedesktop.org/show_bug.cgi?id=96473 */
>   pci_bus_read_config_word(dev->pdev->bus, PCI_DEVFN(0, 0),
>I865_TOUD, );
>  
> -- 
> 2.8.1
> 

-- 
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 1/4] drm: add picture aspect ratio flags

[Daniel Vetter]

On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
> On 4 August 2016 at 14:15, Sharma, Shashank  wrote:
> > On 8/4/2016 5:04 PM, Emil Velikov wrote:
> >>
> >> On 4 August 2016 at 11:16, Sharma, Shashank 
> >> wrote:
> >>>
> >>> Hello Emil,
> >>>
> >>> Thanks for your time.
> >>>
> >>> I have got mixed opinion on this.
> >>>
> >>> IMHO we should expose them to userspace too, as UI agents like Hardware
> >>> composer/X/Wayland must know what does these
> >>>
> >>> flags means, so that they can display them on the end user screen (like
> >>> settings menu)
> >>>
> >>> But few people even think thats its too complex to be exposed to
> >>> userspace
> >>> agents.
> >>>
> >> If we want these/such flags passed between kernel and user space one must:
> >>   - Provide a kernel interface how to do that
> >>   - Provide a userspace (acked by respective developers/maintainers)
> >> that the approach is sane and proves useful.
> >>
> >> Since the above can take some time, I'd suggest dropping those from
> >> the UAPI header(s)... for now.
> >>
> >> -Emil
> >
> > Please guide me a bit more on this problem, Emil, Daniel.
> > The reason why I want to pass this to userspace is, so that, HWC/X/any other
> > UI manager, can send a modeset
> > which is accurate upto aspect ratio.
> >
> Nobody(?) is arguing that you don't to pass such information to/from
> userspace :-)
> Your series does the internal parsing/management of the attribute and
> has no actual UAPI implementation and/or userspace references (to
> code/discussions). Thus the UAPI changes should _not_ be part of these
> patches.
> 
> Daniel's blog [1] has many educational materials why and how things
> are done upstream. I would kindly invite you to give them (another?)
> courtesy read.

It reuses the already existing uapi mode structure. And since it extends
them both on the probe side and on the modeset set this means userspace
can just pass through the right probed mode and it'll all magically work.
At least that's the idea.

Now if you actually care about the different bits then you can select the
right mode, but that's about it. So if you want to compensate for the
non-square pixels in rendering then you need to look at it, but otherwise
it's just a case of select the mode you want. I don't see what new
userspace we'd need for that really, current one should all work nicely
as-is. At least the entire point of doing this was seamless support with
existing userspace.
-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] ✗ Ro.CI.BAT: failure for series starting with [CI,01/26] drm/i915: Combine loops within i915_gem_evict_something

[Chris Wilson]

On Thu, Aug 04, 2016 at 04:11:24PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,01/26] drm/i915: Combine loops within 
> i915_gem_evict_something
> URL   : https://patchwork.freedesktop.org/series/10676/
> State : failure
> 
> == Summary ==
> 
> Series 10676v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/10676/revisions/1/mbox
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (fi-skl-i5-6260u)
> pass   -> DMESG-WARN (fi-skl-i7-6700k)
> Test kms_cursor_legacy:
> Subgroup basic-flip-vs-cursor-legacy:
> pass   -> FAIL   (ro-skl3-i5-6260u)
> fail   -> PASS   (ro-bdw-i5-5250u)
> fail   -> DMESG-FAIL (fi-skl-i7-6700k)
> Subgroup basic-flip-vs-cursor-varying-size:
> pass   -> FAIL   (ro-snb-i7-2620M)
> fail   -> DMESG-FAIL (fi-skl-i7-6700k)
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (ro-byt-n2820)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-i5-6260u)
> pass   -> DMESG-WARN (fi-skl-i7-6700k)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-skl-i5-6260u)
> pass   -> DMESG-WARN (fi-skl-i7-6700k)
> Subgroup suspend-read-crc-pipe-c:
> pass   -> DMESG-WARN (fi-skl-i5-6260u)
> pass   -> DMESG-WARN (fi-skl-i7-6700k)

The skylake noise is in the base -nightly :|
-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] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

[David Weinehall]

On Tue, Aug 02, 2016 at 03:21:57PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The spec was recently fixed to have the correct iboost setting for the
> SKL Y/U DP DDI buffer translation table entry 2. Update our tables
> to match.
> 
> Cc: David Weinehall 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index fc2ef2d76091..c55a2ad50c0d 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -145,7 +145,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_dp[] = {
>  static const struct ddi_buf_trans skl_u_ddi_translations_dp[] = {
>   { 0x201B, 0x00A2, 0x0 },
>   { 0x5012, 0x0088, 0x0 },
> - { 0x80007011, 0x00CD, 0x0 },
> + { 0x80007011, 0x00CD, 0x1 },
>   { 0x80009010, 0x00C0, 0x1 },
>   { 0x201B, 0x009D, 0x0 },
>   { 0x80005012, 0x00C0, 0x1 },
> @@ -158,7 +158,7 @@ static const struct ddi_buf_trans 
> skl_u_ddi_translations_dp[] = {
>  static const struct ddi_buf_trans skl_y_ddi_translations_dp[] = {
>   { 0x0018, 0x00A2, 0x0 },
>   { 0x5012, 0x0088, 0x0 },
> - { 0x80007011, 0x00CD, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
>   { 0x80009010, 0x00C0, 0x3 },
>   { 0x0018, 0x009D, 0x0 },
>   { 0x80005012, 0x00C0, 0x3 },
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Paper over locking inversion after registration rework

[Chris Wilson]

On Thu, Aug 04, 2016 at 12:15:14PM +0200, Daniel Vetter wrote:
> drm_connector_register_all requires a few too many locks because our
> connector_list locking is busted. Add another FIXME+hack to work
> around this. This should address the below lockdep splat:
> 
> Cc: Imre Deak 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_connector.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index ef921fa09a84..d9104d8b3c6b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -401,16 +401,14 @@ int drm_connector_register_all(struct drm_device *dev)
>   struct drm_connector *connector;
>   int ret;
>  
> - mutex_lock(>mode_config.mutex);
> -
> - drm_for_each_connector(connector, dev) {
> + /* FIXME: taking the mode config mutex ends up in a clash with
> +  * fbcon/backlight registration */
> + list_for_each_entry(connector, >mode_config.connector_list, head) {

Ok, double checked that the only time we delete from this list
(currently) is in cleanup. That's highly unlikely to be running at the
same time as the register, so

Acked-by: Chris Wilson 
-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] ✗ Ro.CI.BAT: failure for series starting with [CI,01/26] drm/i915: Combine loops within i915_gem_evict_something

[Patchwork]

== Series Details ==

Series: series starting with [CI,01/26] drm/i915: Combine loops within 
i915_gem_evict_something
URL   : https://patchwork.freedesktop.org/series/10676/
State : failure

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (ro-skl3-i5-6260u)
fail   -> PASS   (ro-bdw-i5-5250u)
fail   -> DMESG-FAIL (fi-skl-i7-6700k)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-snb-i7-2620M)
fail   -> DMESG-FAIL (fi-skl-i7-6700k)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
dmesg-warn -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-i5-6260u)
pass   -> DMESG-WARN (fi-skl-i7-6700k)

fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-kbl-qkkr  total:240  pass:182  dwarn:29  dfail:0   fail:3   skip:26 
fi-skl-i5-6260u  total:240  pass:220  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:240  pass:204  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:240  pass:198  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:219  dwarn:5   dfail:0   fail:0   skip:16 
ro-bdw-i7-5557U  total:240  pass:223  dwarn:1   dfail:0   fail:0   skip:16 
ro-bdw-i7-5600u  total:240  pass:205  dwarn:1   dfail:0   fail:2   skip:32 
ro-bsw-n3050 total:240  pass:193  dwarn:0   dfail:0   fail:5   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk-i7-620lm  total:240  pass:173  dwarn:1   dfail:0   fail:1   skip:65 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:221  dwarn:1   dfail:0   fail:4   skip:14 
ro-snb-i7-2620M  total:240  pass:197  dwarn:0   dfail:0   fail:2   skip:41 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1716/

8b0dfb8 drm-intel-nightly: 2016y-08m-04d-13h-05m-22s UTC integration manifest
7f486e0 drm/i915: Export our request as a dma-buf fence on the reservation 
object
0f30360 drm/i915: Enable lockless lookup of request tracking via RCU
eb2c665 drm/i915: Move i915_gem_object_wait_rendering()
0178728 drm/i915: Move obj->active:5 to obj->flags
84cfd14 drm/i915: Use dev_priv consistently through the intel_frontbuffer 
interface
24dd1f6 drm/i915: Use atomics to manipulate obj->frontbuffer_bits
37632ba drm/i915: Make fb_tracking.lock a spinlock
906079b drm/i915: Separate intel_frontbuffer into its own header
5eaf46b drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()
5e03638 drm/i915: Make i915_vma_pin() small and inline
145bec5 drm/i915: Combine all i915_vma bitfields into a single set of flags
1ac38f9 drm/i915: Start passing around i915_vma from execbuffer
eccd55b drm/i915: Wrap vma->pin_count accessors with small inline helpers
c2950db drm/i915: Record allocated vma size
74443a7 drm/i915: Update i915_gem_get_ggtt_size/_alignment to use 
drm_i915_private
7c2ad8f drm/i915: Update the GGTT size/alignment query functions
afae76e drm/i915: Convert 4096 alignment request to 0 for drm_mm allocations
4eacdf5 drm/i915: Split insertion/binding of an object into the VM
b0226a9 drm/i915: Reduce WARN(i915_gem_valid_gtt_space) to a debug-only check
6184390 drm/i915: Pad GTT views of exec objects up to user specified size
8e9c271 drm/i915: Fix up vma alignment to be u64
c01d3bc drm/i915: Remove i915_gem_execbuffer_retire_commands()
d881daf drm/i915: Remove request retirement before each batch
570049d drm/i915: Double check the active status on the batch pool
a9b6ee1 drm/i915: Remove surplus drm_device parameter to 
i915_gem_evict_something()
a7da93d drm/i915: Combine loops within i915_gem_evict_something

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

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

[Daniel Vetter]

On Thu, Aug 04, 2016 at 06:35:52PM +0530, Sharma, Shashank wrote:
> Thanks Daniel.
> 
> My comments, inline.
> 
> Regards
> Shashank
> On 8/4/2016 4:06 PM, Daniel Vetter wrote:
> > On Thu, Aug 04, 2016 at 03:46:09PM +0530, Sharma, Shashank wrote:
> > > Hello Emil,
> > > 
> > > Thanks for your time.
> > > 
> > > I have got mixed opinion on this.
> > > 
> > > IMHO we should expose them to userspace too, as UI agents like Hardware
> > > composer/X/Wayland must know what does these
> > > 
> > > flags means, so that they can display them on the end user screen (like
> > > settings menu)
> > > 
> > > But few people even think thats its too complex to be exposed to userspace
> > > agents.
> > > 
> > > So your suggestions are welcome.
> > These are flags for the internal mode representation, not for the uapi
> > one. They really don't belong into the uapi header, but instead into
> > include/drm/drm_modes.h. I.e. I fully concur with Emil.
> > -Daniel
> Please correct me if I am missing anything, but In that case, how will HWC/X
> apply a modeset
> 1920x1080@60 16:9 (Not 1920x1080@60 4:3)

Argh sorry, I mixed up the two mode structures again. You're correct.
-Daniel

> 
> Regards
> Shashank
> > > Regards
> > > Shashank
> > > 
> > > On 8/4/2016 3:12 PM, Emil Velikov wrote:
> > > > On 3 August 2016 at 11:56, Shashank Sharma  
> > > > wrote:
> > > > 
> > > > > --- a/include/uapi/drm/drm_mode.h
> > > > > +++ b/include/uapi/drm/drm_mode.h
> > > > > +
> > > > > +/* Aspect ratio flag bitmask (4 bits 22:19) */
> > > > > +#define DRM_MODE_FLAG_PARMASK  (0x0F<<19)
> > > > > +#define  DRM_MODE_FLAG_PARNONE \
> > > > > +   (DRM_MODE_PICTURE_ASPECT_NONE << 19)
> > > > > +#define  DRM_MODE_FLAG_PAR4_3 \
> > > > > +   (DRM_MODE_PICTURE_ASPECT_4_3 << 19)
> > > > > +#define  DRM_MODE_FLAG_PAR16_9 \
> > > > > +   (DRM_MODE_PICTURE_ASPECT_16_9 << 19)
> > > > > 
> > > > Afaict all these flags are internal/implementation specific thus we
> > > > shouldn't expose them to userspace. Right ?
> > > > 
> > > > -Emil
> > > ___
> > > 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

Re: [Intel-gfx] [I-G-T v3 2/2] igt/gem_mocs_settings: adding RC6 tests

[Chris Wilson]

On Thu, Aug 04, 2016 at 02:39:26PM +0100, Peter Antoine wrote:
> This change adds a RC6 test for the MOCS. The MOCS registers are loaded
> and saved as part of the RC6 cycle but not all the registers are
> saved/restored. This tests that those registers are correctly restored.
> 
> Signed-off-by: Peter Antoine 

Tweaked to use igt_sysfs and pushed.
-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] [CI 05/26] drm/i915: Remove i915_gem_execbuffer_retire_commands()

[Chris Wilson]

Move the single line to the callsite as the name is now misleading, and
the purpose is solely to add the request to the execution queue. Here,
we can see that if we failed to dispatch the batch from the request, we
can forgo flushing the GPU when closing the request.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0593ea3ba211..63984c4d8e5a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1211,13 +1211,6 @@ i915_gem_execbuffer_move_to_active(struct list_head 
*vmas,
}
 }
 
-static void
-i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params *params)
-{
-   /* Add a breadcrumb for the completion of the batch buffer */
-   __i915_add_request(params->request, params->batch_obj, true);
-}
-
 static int
 i915_reset_gen7_sol_offsets(struct drm_i915_gem_request *req)
 {
@@ -1692,7 +1685,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
 
ret = execbuf_submit(params, args, >vmas);
 err_request:
-   i915_gem_execbuffer_retire_commands(params);
+   __i915_add_request(params->request, params->batch_obj, ret == 0);
 
 err_batch_unpin:
/*
-- 
2.8.1

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

[Intel-gfx] [CI 22/26] drm/i915: Use dev_priv consistently through the intel_frontbuffer interface

[Chris Wilson]

Rather than a mismash of struct drm_device *dev and struct
drm_i915_private *dev_priv being used freely within a function, be
consistent and only pass along dev_priv.

Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_display.c | 10 +++
 drivers/gpu/drm/i915/intel_dp.c  | 14 --
 drivers/gpu/drm/i915/intel_drv.h | 15 +-
 drivers/gpu/drm/i915/intel_frontbuffer.c | 47 +---
 drivers/gpu/drm/i915/intel_frontbuffer.h |  7 ++---
 drivers/gpu/drm/i915/intel_overlay.c |  3 +-
 drivers/gpu/drm/i915/intel_psr.c | 26 --
 7 files changed, 53 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5bc82064b219..9068676943bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4566,12 +4566,11 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
-   struct drm_device *dev = crtc->base.dev;
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
drm_atomic_get_existing_plane_state(old_state, primary);
 
-   intel_frontbuffer_flip(dev, pipe_config->fb_bits);
+   intel_frontbuffer_flip(to_i915(crtc->base.dev), pipe_config->fb_bits);
 
crtc->wm.cxsr_allowed = true;
 
@@ -4694,7 +4693,7 @@ static void intel_crtc_disable_planes(struct drm_crtc 
*crtc, unsigned plane_mask
 * to compute the mask of flip planes precisely. For the time being
 * consider this a flip to a NULL plane.
 */
-   intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_ALL_MASK(pipe));
+   intel_frontbuffer_flip(to_i915(dev), INTEL_FRONTBUFFER_ALL_MASK(pipe));
 }
 
 static void ironlake_crtc_enable(struct drm_crtc *crtc)
@@ -10952,7 +10951,8 @@ static void intel_unpin_work_fn(struct work_struct 
*__work)
 
i915_gem_request_put(work->flip_queued_req);
 
-   intel_frontbuffer_flip_complete(dev, 
to_intel_plane(primary)->frontbuffer_bit);
+   intel_frontbuffer_flip_complete(to_i915(dev),
+   
to_intel_plane(primary)->frontbuffer_bit);
intel_fbc_post_update(crtc);
drm_framebuffer_unreference(work->old_fb);
 
@@ -11727,7 +11727,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
  to_intel_plane(primary)->frontbuffer_bit);
mutex_unlock(>struct_mutex);
 
-   intel_frontbuffer_flip_prepare(dev,
+   intel_frontbuffer_flip_prepare(to_i915(dev),
   
to_intel_plane(primary)->frontbuffer_bit);
 
trace_i915_flip_request(intel_crtc->plane, obj);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 53d97f6af24b..0aadc65ff035 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5228,7 +5228,7 @@ unlock:
 
 /**
  * intel_edp_drrs_invalidate - Disable Idleness DRRS
- * @dev: DRM device
+ * @dev_priv: i915 device
  * @frontbuffer_bits: frontbuffer plane tracking bits
  *
  * This function gets called everytime rendering on the given planes start.
@@ -5236,10 +5236,9 @@ unlock:
  *
  * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
  */
-void intel_edp_drrs_invalidate(struct drm_device *dev,
-   unsigned frontbuffer_bits)
+void intel_edp_drrs_invalidate(struct drm_i915_private *dev_priv,
+  unsigned int frontbuffer_bits)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc *crtc;
enum pipe pipe;
 
@@ -5271,7 +5270,7 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
 
 /**
  * intel_edp_drrs_flush - Restart Idleness DRRS
- * @dev: DRM device
+ * @dev_priv: i915 device
  * @frontbuffer_bits: frontbuffer plane tracking bits
  *
  * This function gets called every time rendering on the given planes has
@@ -5281,10 +5280,9 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
  *
  * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits.
  */
-void intel_edp_drrs_flush(struct drm_device *dev,
-   unsigned frontbuffer_bits)
+void intel_edp_drrs_flush(struct drm_i915_private *dev_priv,
+ unsigned int frontbuffer_bits)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_crtc *crtc;
enum pipe pipe;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 127eb651925f..e54e6c205f41 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h

[Intel-gfx] [CI 13/26] drm/i915: Record allocated vma size

[Chris Wilson]

Tracking the size of the VMA as allocated allows us to dramatically
reduce the complexity of later functions (like inserting the VMA in to
the drm_mm range manager).

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 103 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c |  67 ---
 drivers/gpu/drm/i915/i915_gem_gtt.h |   5 +-
 3 files changed, 63 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b8f7c821d184..2b91dee7c328 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2980,53 +2980,36 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
   u64 alignment,
   u64 flags)
 {
-   struct drm_device *dev = obj->base.dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
-   u64 start, end;
-   u32 search_flag, alloc_flag;
+   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct i915_vma *vma;
+   u64 start, end;
+   u64 min_alignment;
int ret;
 
-   if (i915_is_ggtt(vm)) {
-   u32 fence_size, fence_alignment, unfenced_alignment;
-   u64 view_size;
-
-   if (WARN_ON(!ggtt_view))
-   return ERR_PTR(-EINVAL);
-
-   view_size = i915_ggtt_view_size(obj, ggtt_view);
-
-   fence_size = i915_gem_get_ggtt_size(dev_priv,
-   view_size,
-   obj->tiling_mode);
-   fence_alignment = i915_gem_get_ggtt_alignment(dev_priv,
- view_size,
- obj->tiling_mode,
- true);
-   unfenced_alignment = i915_gem_get_ggtt_alignment(dev_priv,
-view_size,
-
obj->tiling_mode,
-false);
-   size = max(size, view_size);
-   if (flags & PIN_MAPPABLE)
-   size = max_t(u64, size, fence_size);
-
-   if (alignment == 0)
-   alignment = flags & PIN_MAPPABLE ? fence_alignment :
-   unfenced_alignment;
-   if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
-   DRM_DEBUG("Invalid object (view type=%u) alignment 
requested %llx\n",
- ggtt_view ? ggtt_view->type : 0,
- alignment);
-   return ERR_PTR(-EINVAL);
-   }
-   } else {
-   size = max_t(u64, size, obj->base.size);
-   alignment = 4096;
+   vma = ggtt_view ?
+   i915_gem_obj_lookup_or_create_ggtt_vma(obj, ggtt_view) :
+   i915_gem_obj_lookup_or_create_vma(obj, vm);
+   if (IS_ERR(vma))
+   return vma;
+
+   size = max(size, vma->size);
+   if (flags & PIN_MAPPABLE)
+   size = i915_gem_get_ggtt_size(dev_priv, size, obj->tiling_mode);
+
+   min_alignment =
+   i915_gem_get_ggtt_alignment(dev_priv, size, obj->tiling_mode,
+   flags & PIN_MAPPABLE);
+   if (alignment == 0)
+   alignment = min_alignment;
+   if (alignment & (min_alignment - 1)) {
+   DRM_DEBUG("Invalid object alignment requested %llu, minimum 
%llu\n",
+ alignment, min_alignment);
+   return ERR_PTR(-EINVAL);
}
 
start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
-   end = vm->total;
+
+   end = vma->vm->total;
if (flags & PIN_MAPPABLE)
end = min_t(u64, end, dev_priv->ggtt.mappable_end);
if (flags & PIN_ZONE_4G)
@@ -3037,8 +3020,7 @@ i915_gem_object_insert_into_vm(struct drm_i915_gem_object 
*obj,
 * attempt to find space.
 */
if (size > end) {
-   DRM_DEBUG("Attempting to bind an object (view type=%u) larger 
than the aperture: request=%llu [object=%zd] > %s aperture=%llu\n",
- ggtt_view ? ggtt_view->type : 0,
+   DRM_DEBUG("Attempting to bind an object larger than the 
aperture: request=%llu [object=%zd] > %s aperture=%llu\n",
  size, obj->base.size,
  flags & PIN_MAPPABLE ? "mappable" : "total",
  end);
@@ -3051,31 +3033,27 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
 

[Intel-gfx] [CI 08/26] drm/i915: Reduce WARN(i915_gem_valid_gtt_space) to a debug-only check

[Chris Wilson]

i915_gem_valid_gtt_space() is used after inserting the VMA to double
check the list - the location should have been chosen to pass all the
restrictions.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4e08aed93225..1e78ccc6538e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3090,10 +3090,7 @@ search_free:
goto err_vma;
}
}
-   if (WARN_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level))) {
-   ret = -EINVAL;
-   goto err_remove_node;
-   }
+   GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level));
 
trace_i915_vma_bind(vma, flags);
ret = i915_vma_bind(vma, obj->cache_level, flags);
-- 
2.8.1

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

[Intel-gfx] [CI 18/26] drm/i915: Remove highly confusing i915_gem_obj_ggtt_pin()

[Chris Wilson]

Since i915_gem_obj_ggtt_pin() is an idiom breaking curry function for
i915_gem_object_ggtt_pin(), spare us the confusion and remove it.
Removing it now simplifies later patches to change the i915_vma_pin()
(and friends) interface.

v2: Add a redundant GEM_BUG_ON(!view) to
i915_gem_obj_lookup_or_create_ggtt_vma()

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  |  9 -
 drivers/gpu/drm/i915/i915_gem.c  | 17 +++--
 drivers/gpu/drm/i915/i915_gem_context.c  |  5 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   |  4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 ++
 drivers/gpu/drm/i915/i915_gem_render_state.c |  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c   |  4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c  |  2 +-
 drivers/gpu/drm/i915/intel_lrc.c |  8 +---
 drivers/gpu/drm/i915/intel_overlay.c |  3 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 15 ---
 11 files changed, 32 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cda8238c952f..7ba99057c317 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3289,15 +3289,6 @@ static inline bool i915_gem_obj_ggtt_bound(struct 
drm_i915_gem_object *obj)
 unsigned long
 i915_gem_obj_ggtt_size(struct drm_i915_gem_object *obj);
 
-static inline int __must_check
-i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
- uint32_t alignment,
- unsigned flags)
-{
-   return i915_gem_object_ggtt_pin(obj, _ggtt_view_normal,
-   0, alignment, flags);
-}
-
 void i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
 const struct i915_ggtt_view *view);
 static inline void
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6876af6914f9..7dcc71fde4a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -652,7 +652,7 @@ i915_gem_gtt_pread(struct drm_device *dev,
uint64_t offset;
int ret;
 
-   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+   ret = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
if (ret) {
ret = insert_mappable_node(dev_priv, , PAGE_SIZE);
if (ret)
@@ -949,7 +949,8 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
if (obj->tiling_mode != I915_TILING_NONE)
return -EFAULT;
 
-   ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE | PIN_NONBLOCK);
+   ret = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
+  PIN_MAPPABLE | PIN_NONBLOCK);
if (ret) {
ret = insert_mappable_node(i915, , PAGE_SIZE);
if (ret)
@@ -3719,7 +3720,7 @@ int __i915_vma_do_pin(struct i915_vma *vma,
goto err;
}
 
-   if ((bound & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND)) == 0) {
+   if ((bound & I915_VMA_BIND_MASK) == 0) {
ret = i915_vma_insert(vma, size, alignment, flags);
if (ret)
goto err;
@@ -3750,7 +3751,8 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
struct i915_vma *vma;
int ret;
 
-   BUG_ON(!view);
+   if (!view)
+   view = _ggtt_view_normal;
 
vma = i915_gem_obj_lookup_or_create_ggtt_vma(obj, view);
if (IS_ERR(vma))
@@ -3782,12 +3784,7 @@ void
 i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view)
 {
-   struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
-
-   WARN_ON(!i915_vma_is_pinned(vma));
-   WARN_ON(!i915_gem_obj_ggtt_bound_view(obj, view));
-
-   __i915_vma_unpin(vma);
+   i915_vma_unpin(i915_gem_obj_to_ggtt_view(obj, view));
 }
 
 int
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index dc7c0ae73b62..bb72af5320b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -763,9 +763,8 @@ static int do_rcs_switch(struct drm_i915_gem_request *req)
return 0;
 
/* Trying to pin first makes error handling easier. */
-   ret = i915_gem_obj_ggtt_pin(to->engine[RCS].state,
-   to->ggtt_alignment,
-   0);
+   ret = i915_gem_object_ggtt_pin(to->engine[RCS].state, NULL, 0,
+  to->ggtt_alignment, 0);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a0c95ab15d57..109bb9d8df4a 100644
--- 

[Intel-gfx] [CI 07/26] drm/i915: Pad GTT views of exec objects up to user specified size

[Chris Wilson]

Our GPUs impose certain requirements upon buffers that depend upon how
exactly they are used. Typically this is expressed as that they require
a larger surface than would be naively computed by pitch * height.
Normally such requirements are hidden away in the userspace driver, but
when we accept pointers from strangers and later impose extra conditions
on them, the original client allocator has no idea about the
monstrosities in the GPU and we require the userspace driver to inform
the kernel how many padding pages are required beyond the client
allocation.

v2: Long time, no see
v3: Try an anonymous union for uapi struct compatibility

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h|  6 ++-
 drivers/gpu/drm/i915/i915_gem.c| 80 ++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 17 ++-
 include/uapi/drm/i915_drm.h|  8 ++-
 4 files changed, 64 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 74a31358fd87..1e1369319326 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3032,11 +3032,13 @@ void i915_gem_free_object(struct drm_gem_object *obj);
 int __must_check
 i915_gem_object_pin(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
+   u64 size,
u64 alignment,
u64 flags);
 int __must_check
 i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 const struct i915_ggtt_view *view,
+u64 size,
 u64 alignment,
 u64 flags);
 
@@ -3313,8 +3315,8 @@ i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct i915_ggtt *ggtt = _priv->ggtt;
 
-   return i915_gem_object_pin(obj, >base,
-  alignment, flags | PIN_GLOBAL);
+   return i915_gem_object_pin(obj, >base, 0, alignment,
+  flags | PIN_GLOBAL);
 }
 
 void i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 504414c4285c..4e08aed93225 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1692,7 +1692,7 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
}
 
/* Now pin it into the GTT if needed */
-   ret = i915_gem_object_ggtt_pin(obj, , 0, PIN_MAPPABLE);
+   ret = i915_gem_object_ggtt_pin(obj, , 0, 0, PIN_MAPPABLE);
if (ret)
goto unlock;
 
@@ -2956,6 +2956,7 @@ static bool i915_gem_valid_gtt_space(struct i915_vma *vma,
  * @obj: object to bind
  * @vm: address space to bind into
  * @ggtt_view: global gtt view if applicable
+ * @size: requested size in bytes (can be larger than the VMA)
  * @alignment: requested alignment
  * @flags: mask of PIN_* flags to use
  */
@@ -2963,21 +2964,20 @@ static struct i915_vma *
 i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
   struct i915_address_space *vm,
   const struct i915_ggtt_view *ggtt_view,
+  u64 size,
   u64 alignment,
   u64 flags)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
-   u32 fence_alignment, unfenced_alignment;
-   u32 search_flag, alloc_flag;
u64 start, end;
-   u64 size, fence_size;
+   u32 search_flag, alloc_flag;
struct i915_vma *vma;
int ret;
 
if (i915_is_ggtt(vm)) {
-   u32 view_size;
+   u32 fence_size, fence_alignment, unfenced_alignment;
+   u64 view_size;
 
if (WARN_ON(!ggtt_view))
return ERR_PTR(-EINVAL);
@@ -2995,48 +2995,39 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
view_size,

obj->tiling_mode,
false);
-   size = flags & PIN_MAPPABLE ? fence_size : view_size;
+   size = max(size, view_size);
+   if (flags & PIN_MAPPABLE)
+   size = max_t(u64, size, fence_size);
+
+   if (alignment == 0)
+   alignment = flags & PIN_MAPPABLE ? fence_alignment :
+   unfenced_alignment;
+   if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
+   

[Intel-gfx] [CI 20/26] drm/i915: Make fb_tracking.lock a spinlock

[Chris Wilson]

We only need a very lightweight mechanism here as the locking is only
used for co-ordinating a bitfield.

v2: Move the cheap unlikely tests into the caller
v3: Move the kerneldoc into the header (now separated out into
intel_fronbuffer.h for better kerneldoc and readability)

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtien 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_gem.c  |  2 +-
 drivers/gpu/drm/i915/intel_frontbuffer.c | 73 ++--
 drivers/gpu/drm/i915/intel_frontbuffer.h | 50 --
 4 files changed, 71 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ba99057c317..b26f5b1f466b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1669,7 +1669,7 @@ struct intel_pipe_crc {
 };
 
 struct i915_frontbuffer_tracking {
-   struct mutex lock;
+   spinlock_t lock;
 
/*
 * Tracking bits for delayed frontbuffer flushing du to gpu activity or
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7396c99aa60a..1fc21871a23c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4455,7 +4455,7 @@ i915_gem_load_init(struct drm_device *dev)
 
dev_priv->mm.interruptible = true;
 
-   mutex_init(_priv->fb_tracking.lock);
+   spin_lock_init(_priv->fb_tracking.lock);
 }
 
 void i915_gem_load_cleanup(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index b83a70016b12..f15486aee7f8 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -66,35 +66,19 @@
 #include "intel_frontbuffer.h"
 #include "i915_drv.h"
 
-/**
- * intel_fb_obj_invalidate - invalidate frontbuffer object
- * @obj: GEM object to invalidate
- * @origin: which operation caused the invalidation
- *
- * This function gets called every time rendering on the given object starts 
and
- * frontbuffer caching (fbc, low refresh rate for DRRS, panel self refresh) 
must
- * be invalidated. For ORIGIN_CS any subsequent invalidation will be delayed
- * until the rendering completes or a flip on this frontbuffer plane is
- * scheduled.
- */
-void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
-enum fb_op_origin origin)
+void __intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
+  enum fb_op_origin origin)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
WARN_ON(!mutex_is_locked(>struct_mutex));
 
-   if (!obj->frontbuffer_bits)
-   return;
-
if (origin == ORIGIN_CS) {
-   mutex_lock(_priv->fb_tracking.lock);
-   dev_priv->fb_tracking.busy_bits
-   |= obj->frontbuffer_bits;
-   dev_priv->fb_tracking.flip_bits
-   &= ~obj->frontbuffer_bits;
-   mutex_unlock(_priv->fb_tracking.lock);
+   spin_lock(_priv->fb_tracking.lock);
+   dev_priv->fb_tracking.busy_bits |= obj->frontbuffer_bits;
+   dev_priv->fb_tracking.flip_bits &= ~obj->frontbuffer_bits;
+   spin_unlock(_priv->fb_tracking.lock);
}
 
intel_psr_invalidate(dev, obj->frontbuffer_bits);
@@ -121,9 +105,9 @@ static void intel_frontbuffer_flush(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
 
/* Delay flushing when rings are still busy.*/
-   mutex_lock(_priv->fb_tracking.lock);
+   spin_lock(_priv->fb_tracking.lock);
frontbuffer_bits &= ~dev_priv->fb_tracking.busy_bits;
-   mutex_unlock(_priv->fb_tracking.lock);
+   spin_unlock(_priv->fb_tracking.lock);
 
if (!frontbuffer_bits)
return;
@@ -133,18 +117,9 @@ static void intel_frontbuffer_flush(struct drm_device *dev,
intel_fbc_flush(dev_priv, frontbuffer_bits, origin);
 }
 
-/**
- * intel_fb_obj_flush - flush frontbuffer object
- * @obj: GEM object to flush
- * @retire: set when retiring asynchronous rendering
- * @origin: which operation caused the flush
- *
- * This function gets called every time rendering on the given object has
- * completed and frontbuffer caching can be started again. If @retire is true
- * then any delayed flushes will be unblocked.
- */
-void intel_fb_obj_flush(struct drm_i915_gem_object *obj,
-   bool retire, enum fb_op_origin origin)
+void __intel_fb_obj_flush(struct drm_i915_gem_object *obj,
+ bool retire,
+ enum fb_op_origin origin)
 {
struct drm_device *dev = obj->base.dev;
struct 

[Intel-gfx] [CI 17/26] drm/i915: Make i915_vma_pin() small and inline

[Chris Wilson]

Not only is i915_vma_pin() called for every single object on every single
execbuf, it is usually a simple increment as the VMA is already bound for
execution by the GPU. Rearrange the tests for unbound and pin_count
overflow so that we can do the increment and test very cheaply and
compact enough to inline the operation into execbuf. The trick used is
to note that we can check for an overflow bit (keeping space available
for it inside the flags) at the same time as checking the binding bits.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 18 +
 drivers/gpu/drm/i915/i915_gem_gtt.h | 53 ++---
 2 files changed, 44 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c47ffe151c82..6876af6914f9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3705,23 +3705,19 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma 
*vma)
obj->map_and_fenceable = mappable && fenceable;
 }
 
-int
-i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
+int __i915_vma_do_pin(struct i915_vma *vma,
+ u64 size, u64 alignment, u64 flags)
 {
-   unsigned int bound;
+   unsigned int bound = vma->flags;
int ret;
 
GEM_BUG_ON((flags & (PIN_GLOBAL | PIN_USER)) == 0);
GEM_BUG_ON((flags & PIN_GLOBAL) && !i915_vma_is_ggtt(vma));
 
-   bound = vma->flags;
-   if (WARN_ON((bound & I915_VMA_PIN_MASK) == I915_VMA_PIN_MASK))
-   return -EBUSY;
-
-   /* Pin early to prevent the shrinker/eviction logic from destroying
-* our vma as we insert and bind.
-*/
-   __i915_vma_pin(vma);
+   if (WARN_ON(bound & I915_VMA_PIN_OVERFLOW)) {
+   ret = -EBUSY;
+   goto err;
+   }
 
if ((bound & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND)) == 0) {
ret = i915_vma_insert(vma, size, alignment, flags);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 5134c0433abd..cc56206a1600 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -194,13 +194,15 @@ struct i915_vma {
 * bits with absolutely no headroom. So use 4 bits.
 */
 #define I915_VMA_PIN_MASK 0xf
+#define I915_VMA_PIN_OVERFLOW  BIT(5)
 
/** Flags and address space this VMA is bound to */
-#define I915_VMA_GLOBAL_BIND   BIT(5)
-#define I915_VMA_LOCAL_BINDBIT(6)
+#define I915_VMA_GLOBAL_BIND   BIT(6)
+#define I915_VMA_LOCAL_BINDBIT(7)
+#define I915_VMA_BIND_MASK (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND | 
I915_VMA_PIN_OVERFLOW)
 
-#define I915_VMA_GGTT  BIT(7)
-#define I915_VMA_CLOSED BIT(8)
+#define I915_VMA_GGTT  BIT(8)
+#define I915_VMA_CLOSED BIT(9)
 
unsigned int active;
struct i915_gem_active last_read[I915_NUM_ENGINES];
@@ -620,20 +622,39 @@ i915_ggtt_view_equal(const struct i915_ggtt_view *a,
return true;
 }
 
-int __must_check
-i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags);
 /* Flags used by pin/bind */
-#define PIN_MAPPABLE   BIT(0)
-#define PIN_NONBLOCK   BIT(1)
-#define PIN_GLOBAL BIT(2)
-#define PIN_OFFSET_BIASBIT(3)
-#define PIN_USER   BIT(4)
-#define PIN_UPDATE BIT(5)
-#define PIN_ZONE_4GBIT(6)
-#define PIN_HIGH   BIT(7)
-#define PIN_OFFSET_FIXED   BIT(8)
+#define PIN_NONBLOCK   BIT(0)
+#define PIN_MAPPABLE   BIT(1)
+#define PIN_ZONE_4GBIT(2)
+
+#define PIN_MBZBIT(5) /* I915_VMA_PIN_OVERFLOW */
+#define PIN_GLOBAL BIT(6) /* I915_VMA_GLOBAL_BIND */
+#define PIN_USER   BIT(7) /* I915_VMA_LOCAL_BIND */
+#define PIN_UPDATE BIT(8)
+
+#define PIN_HIGH   BIT(9)
+#define PIN_OFFSET_BIASBIT(10)
+#define PIN_OFFSET_FIXED   BIT(11)
 #define PIN_OFFSET_MASK(~4095)
 
+int __i915_vma_do_pin(struct i915_vma *vma,
+ u64 size, u64 alignment, u64 flags);
+static inline int __must_check
+i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
+{
+   BUILD_BUG_ON(PIN_MBZ != I915_VMA_PIN_OVERFLOW);
+   BUILD_BUG_ON(PIN_GLOBAL != I915_VMA_GLOBAL_BIND);
+   BUILD_BUG_ON(PIN_USER != I915_VMA_LOCAL_BIND);
+
+   /* Pin early to prevent the shrinker/eviction logic from destroying
+* our vma as we insert and bind.
+*/
+   if (likely(((++vma->flags ^ flags) & I915_VMA_BIND_MASK) == 0))
+   return 0;
+
+   return __i915_vma_do_pin(vma, size, alignment, flags);
+}
+
 static inline int i915_vma_pin_count(const struct i915_vma *vma)
 {
return vma->flags & I915_VMA_PIN_MASK;
@@ -647,7 +668,7 @@ static inline bool 

[Intel-gfx] [CI 25/26] drm/i915: Enable lockless lookup of request tracking via RCU

[Chris Wilson]

If we enable RCU for the requests (providing a grace period where we can
inspect a "dead" request before it is freed), we can allow callers to
carefully perform lockless lookup of an active request.

However, by enabling deferred freeing of requests, we can potentially
hog a lot of memory when dealing with tens of thousands of requests per
second - with a quick insertion of a synchronize_rcu() inside our
shrinker callback, that issue disappears.

v2: Currently, it is our responsibility to handle reclaim i.e. to avoid
hogging memory with the delayed slab frees. At the moment, we wait for a
grace period in the shrinker, and block for all RCU callbacks on oom.
Suggested alternatives focus on flushing our RCU callback when we have a
certain number of outstanding request frees, and blocking on that flush
after a second high watermark. (So rather than wait for the system to
run out of memory, we stop issuing requests - both are nondeterministic.)

Paul E. McKenney wrote:

Another approach is synchronize_rcu() after some largish number of
requests.  The advantage of this approach is that it throttles the
production of callbacks at the source.  The corresponding disadvantage
is that it slows things up.

Another approach is to use call_rcu(), but if the previous call_rcu()
is still in flight, block waiting for it.  Yet another approach is
the get_state_synchronize_rcu() / cond_synchronize_rcu() pair.  The
idea is to do something like this:

cond_synchronize_rcu(cookie);
cookie = get_state_synchronize_rcu();

You would of course do an initial get_state_synchronize_rcu() to
get things going.  This would not block unless there was less than
one grace period's worth of time between invocations.  But this
assumes a busy system, where there is almost always a grace period
in flight.  But you can make that happen as follows:

cond_synchronize_rcu(cookie);
cookie = get_state_synchronize_rcu();
call_rcu(_rcu_head, noop_function);

Note that you need additional code to make sure that the old callback
has completed before doing a new one.  Setting and clearing a flag
with appropriate memory ordering control suffices (e.g,. smp_load_acquire()
and smp_store_release()).

v3: More comments on compiler and processor order of operations within
the RCU lookup and discover we can use rcu_access_pointer() here instead.

v4: Wrap i915_gem_active_get_rcu() to take the rcu_read_lock itself.

Signed-off-by: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: "Goel, Akash" 
Cc: Josh Triplett 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c  |   7 +-
 drivers/gpu/drm/i915/i915_gem_request.c  |   2 +-
 drivers/gpu/drm/i915/i915_gem_request.h  | 163 +--
 drivers/gpu/drm/i915/i915_gem_shrinker.c |  15 ++-
 4 files changed, 174 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 852a14468804..aa40d6c35c30 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4431,7 +4431,9 @@ i915_gem_load_init(struct drm_device *dev)
dev_priv->requests =
kmem_cache_create("i915_gem_request",
  sizeof(struct drm_i915_gem_request), 0,
- SLAB_HWCACHE_ALIGN,
+ SLAB_HWCACHE_ALIGN |
+ SLAB_RECLAIM_ACCOUNT |
+ SLAB_DESTROY_BY_RCU,
  NULL);
 
INIT_LIST_HEAD(_priv->context_list);
@@ -4467,6 +4469,9 @@ void i915_gem_load_cleanup(struct drm_device *dev)
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
kmem_cache_destroy(dev_priv->objects);
+
+   /* And ensure that our DESTROY_BY_RCU slabs are truly destroyed */
+   rcu_barrier();
 }
 
 int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 773b942a3a5f..3fecb8f0e041 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -205,7 +205,7 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
prefetchw(next);
 
INIT_LIST_HEAD(>link);
-   active->request = NULL;
+   RCU_INIT_POINTER(active->request, NULL);
 
active->retire(active, request);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 26ca697f5af7..6002adc43523 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -183,6 +183,12 @@ i915_gem_request_get(struct drm_i915_gem_request *req)

[Intel-gfx] [CI 14/26] drm/i915: Wrap vma->pin_count accessors with small inline helpers

[Chris Wilson]

In the next few patches, the VMA pinning API is overhauled and to reduce
the churn we pull out the update to the accessors into a prep patch.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_gem.c| 26 -
 drivers/gpu/drm/i915/i915_gem_evict.c  | 12 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_fence.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 10 +-
 drivers/gpu/drm/i915/i915_gem_gtt.h| 31 --
 drivers/gpu/drm/i915/i915_gpu_error.c  |  4 ++--
 8 files changed, 58 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b35e6174fa7d..4401a2ab9a74 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -168,7 +168,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
if (obj->base.name)
seq_printf(m, " (name: %d)", obj->base.name);
list_for_each_entry(vma, >vma_list, obj_link) {
-   if (vma->pin_count > 0)
+   if (i915_vma_is_pinned(vma))
pin_count++;
}
seq_printf(m, " (pinned x %d)", pin_count);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2b91dee7c328..6987cb22ff9c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -153,10 +153,10 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void 
*data,
pinned = 0;
mutex_lock(>struct_mutex);
list_for_each_entry(vma, >base.active_list, vm_link)
-   if (vma->pin_count)
+   if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
list_for_each_entry(vma, >base.inactive_list, vm_link)
-   if (vma->pin_count)
+   if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(>struct_mutex);
 
@@ -2809,7 +2809,7 @@ static void i915_gem_object_finish_gtt(struct 
drm_i915_gem_object *obj)
 
 static void __i915_vma_iounmap(struct i915_vma *vma)
 {
-   GEM_BUG_ON(vma->pin_count);
+   GEM_BUG_ON(i915_vma_is_pinned(vma));
 
if (vma->iomap == NULL)
return;
@@ -2836,7 +2836,7 @@ int i915_vma_unbind(struct i915_vma *vma)
 * take a pin on the vma so that the second unbind is
 * aborted.
 */
-   vma->pin_count++;
+   __i915_vma_pin(vma);
 
for_each_active(active, idx) {
ret = i915_gem_active_retire(>last_read[idx],
@@ -2845,14 +2845,14 @@ int i915_vma_unbind(struct i915_vma *vma)
break;
}
 
-   vma->pin_count--;
+   __i915_vma_unpin(vma);
if (ret)
return ret;
 
GEM_BUG_ON(i915_vma_is_active(vma));
}
 
-   if (vma->pin_count)
+   if (i915_vma_is_pinned(vma))
return -EBUSY;
 
if (!drm_mm_node_allocated(>node))
@@ -3297,7 +3297,7 @@ restart:
if (!drm_mm_node_allocated(>node))
continue;
 
-   if (vma->pin_count) {
+   if (i915_vma_is_pinned(vma)) {
DRM_DEBUG("can not change the cache level of pinned 
objects\n");
return -EBUSY;
}
@@ -3734,11 +3734,11 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
  i915_gem_obj_to_vma(obj, vm);
 
if (vma) {
-   if (WARN_ON(vma->pin_count == 
DRM_I915_GEM_OBJECT_MAX_PIN_COUNT))
+   if (WARN_ON(i915_vma_pin_count(vma) == 
DRM_I915_GEM_OBJECT_MAX_PIN_COUNT))
return -EBUSY;
 
if (i915_vma_misplaced(vma, size, alignment, flags)) {
-   WARN(vma->pin_count,
+   WARN(i915_vma_is_pinned(vma),
 "bo is already pinned in %s with incorrect 
alignment:"
 " offset=%08x %08x, req.alignment=%llx, 
req.map_and_fenceable=%d,"
 " obj->map_and_fenceable=%d\n",
@@ -3776,7 +3776,7 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
 
GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
 
-   vma->pin_count++;
+   __i915_vma_pin(vma);
return 0;
 }
 
@@ -3815,10 +3815,10 @@ i915_gem_object_ggtt_unpin_view(struct 
drm_i915_gem_object *obj,
 {
struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
 
-   WARN_ON(vma->pin_count == 0);
+   WARN_ON(!i915_vma_is_pinned(vma));
WARN_ON(!i915_gem_obj_ggtt_bound_view(obj, view));
 

[Intel-gfx] [CI 21/26] drm/i915: Use atomics to manipulate obj->frontbuffer_bits

[Chris Wilson]

The individual bits inside obj->frontbuffer_bits are protected by each
plane->mutex, but the whole bitfield may be accessed by multiple KMS
operations simultaneously and so the RMW need to be under atomics.
However, for updating the single field we do not need to mandate that it
be under the struct_mutex, one more step towards its removal as the de
facto BKL.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  6 --
 drivers/gpu/drm/i915/i915_drv.h  |  4 +---
 drivers/gpu/drm/i915/i915_gem.c  | 21 ++---
 drivers/gpu/drm/i915/intel_display.c | 18 ++
 drivers/gpu/drm/i915/intel_frontbuffer.c | 23 +--
 drivers/gpu/drm/i915/intel_frontbuffer.h | 20 ++--
 6 files changed, 48 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8d47d1bf7b85..9796b07bdb0d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -138,6 +138,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct intel_engine_cs *engine;
struct i915_vma *vma;
+   unsigned int frontbuffer_bits;
int pin_count = 0;
enum intel_engine_id id;
 
@@ -204,8 +205,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
if (engine)
seq_printf(m, " (%s)", engine->name);
 
-   if (obj->frontbuffer_bits)
-   seq_printf(m, " (frontbuffer: 0x%03x)", obj->frontbuffer_bits);
+   frontbuffer_bits = atomic_read(>frontbuffer_bits);
+   if (frontbuffer_bits)
+   seq_printf(m, " (frontbuffer: 0x%03x)", frontbuffer_bits);
 }
 
 static int i915_gem_object_list_info(struct seq_file *m, void *data)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b26f5b1f466b..3de75e82ca76 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2127,8 +2127,6 @@ struct drm_i915_gem_object_ops {
  */
 #define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
 #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
-#define INTEL_FRONTBUFFER_BITS \
-   (INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES)
 #define INTEL_FRONTBUFFER_PRIMARY(pipe) \
(1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
 #define INTEL_FRONTBUFFER_CURSOR(pipe) \
@@ -2216,7 +2214,7 @@ struct drm_i915_gem_object {
unsigned int cache_level:3;
unsigned int cache_dirty:1;
 
-   unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+   atomic_t frontbuffer_bits;
 
unsigned int has_wc_mmap;
/** Count of VMA actually bound by this object */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1fc21871a23c..3c0531ba8f60 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4040,7 +4040,7 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
if (obj->stolen)
i915_gem_object_unpin_pages(obj);
 
-   WARN_ON(obj->frontbuffer_bits);
+   WARN_ON(atomic_read(>frontbuffer_bits));
 
if (obj->pages && obj->madv == I915_MADV_WILLNEED &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES &&
@@ -4557,16 +4557,23 @@ void i915_gem_track_fb(struct drm_i915_gem_object *old,
   struct drm_i915_gem_object *new,
   unsigned frontbuffer_bits)
 {
+   /* Control of individual bits within the mask are guarded by
+* the owning plane->mutex, i.e. we can never see concurrent
+* manipulation of individual bits. But since the bitfield as a whole
+* is updated using RMW, we need to use atomics in order to update
+* the bits.
+*/
+   BUILD_BUG_ON(INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES >
+sizeof(atomic_t) * BITS_PER_BYTE);
+
if (old) {
-   WARN_ON(!mutex_is_locked(>base.dev->struct_mutex));
-   WARN_ON(!(old->frontbuffer_bits & frontbuffer_bits));
-   old->frontbuffer_bits &= ~frontbuffer_bits;
+   WARN_ON(!(atomic_read(>frontbuffer_bits) & 
frontbuffer_bits));
+   atomic_andnot(frontbuffer_bits, >frontbuffer_bits);
}
 
if (new) {
-   WARN_ON(!mutex_is_locked(>base.dev->struct_mutex));
-   WARN_ON(new->frontbuffer_bits & frontbuffer_bits);
-   new->frontbuffer_bits |= frontbuffer_bits;
+   WARN_ON(atomic_read(>frontbuffer_bits) & frontbuffer_bits);
+   atomic_or(frontbuffer_bits, >frontbuffer_bits);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 229b1c471df3..5bc82064b219 100644
--- 

[Intel-gfx] [CI 26/26] drm/i915: Export our request as a dma-buf fence on the reservation object

[Chris Wilson]

If the GEM objects being rendered with in this request have been
exported via dma-buf to a third party, hook ourselves into the dma-buf
reservation object so that the third party can serialise with our
rendering via the dma-buf fences.

Testcase: igt/prime_busy
Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 58 --
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31 ++--
 2 files changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 3a00ab3ad06e..c60a8d5bbad0 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -23,9 +23,13 @@
  * Authors:
  * Dave Airlie 
  */
+
+#include 
+#include 
+
 #include 
+
 #include "i915_drv.h"
-#include 
 
 static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
 {
@@ -218,25 +222,73 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
.end_cpu_access = i915_gem_end_cpu_access,
 };
 
+static void export_fences(struct drm_i915_gem_object *obj,
+ struct dma_buf *dma_buf)
+{
+   struct reservation_object *resv = dma_buf->resv;
+   struct drm_i915_gem_request *req;
+   unsigned long active;
+   int idx;
+
+   active = __I915_BO_ACTIVE(obj);
+   if (!active)
+   return;
+
+   /* Serialise with execbuf to prevent concurrent fence-loops */
+   mutex_lock(>base.dev->struct_mutex);
+
+   /* Mark the object for future fences before racily adding old fences */
+   obj->base.dma_buf = dma_buf;
+
+   ww_mutex_lock(>lock, NULL);
+
+   for_each_active(active, idx) {
+   req = i915_gem_active_get(>last_read[idx],
+ >base.dev->struct_mutex);
+   if (!req)
+   continue;
+
+   if (reservation_object_reserve_shared(resv) == 0)
+   reservation_object_add_shared_fence(resv, >fence);
+
+   i915_gem_request_put(req);
+   }
+
+   req = i915_gem_active_get(>last_write,
+ >base.dev->struct_mutex);
+   if (req) {
+   reservation_object_add_excl_fence(resv, >fence);
+   i915_gem_request_put(req);
+   }
+
+   ww_mutex_unlock(>lock);
+   mutex_unlock(>base.dev->struct_mutex);
+}
+
 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
  struct drm_gem_object *gem_obj, int flags)
 {
struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   struct dma_buf *dma_buf;
 
exp_info.ops = _dmabuf_ops;
exp_info.size = gem_obj->size;
exp_info.flags = flags;
exp_info.priv = gem_obj;
 
-
if (obj->ops->dmabuf_export) {
int ret = obj->ops->dmabuf_export(obj);
if (ret)
return ERR_PTR(ret);
}
 
-   return dma_buf_export(_info);
+   dma_buf = dma_buf_export(_info);
+   if (IS_ERR(dma_buf))
+   return dma_buf;
+
+   export_fences(obj, dma_buf);
+   return dma_buf;
 }
 
 static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a1da3028a949..71834741bd87 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -26,14 +26,18 @@
  *
  */
 
+#include 
+#include 
+#include 
+
 #include 
 #include 
+
 #include "i915_drv.h"
+#include "i915_gem_dmabuf.h"
 #include "i915_trace.h"
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
-#include 
-#include 
 
 #define  __EXEC_OBJECT_HAS_PIN (1<<31)
 #define  __EXEC_OBJECT_HAS_FENCE   (1<<30)
@@ -1205,6 +1209,28 @@ void i915_vma_move_to_active(struct i915_vma *vma,
list_move_tail(>vm_link, >vm->active_list);
 }
 
+static void eb_export_fence(struct drm_i915_gem_object *obj,
+   struct drm_i915_gem_request *req,
+   unsigned int flags)
+{
+   struct reservation_object *resv;
+
+   resv = i915_gem_object_get_dmabuf_resv(obj);
+   if (!resv)
+   return;
+
+   /* Ignore errors from failing to allocate the new fence, we can't
+* handle an error right now. Worst case should be missed
+* synchronisation leading to rendering corruption.
+*/
+   ww_mutex_lock(>lock, NULL);
+   if (flags & EXEC_OBJECT_WRITE)
+   reservation_object_add_excl_fence(resv, >fence);
+   else if (reservation_object_reserve_shared(resv) == 0)
+   reservation_object_add_shared_fence(resv, >fence);
+   ww_mutex_unlock(>lock);
+}
+
 static void
 

[Intel-gfx] [CI 10/26] drm/i915: Convert 4096 alignment request to 0 for drm_mm allocations

[Chris Wilson]

As we always allocate in chunks of 4096 (that being both the PAGE_SIZE
and our own GTT_PAGE_SIZE), we know that all results from the drm_mm are
aligned to at least 4096. The drm_mm allocator itself is optimised for
alignment == 0, and so by converting alignments of 4096 to 0 we can
satisfy our own requirements and still hit the faster path.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 00f8d8fa0b04..eedb80451dd5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3072,6 +3072,15 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
alloc_flag = DRM_MM_CREATE_DEFAULT;
}
 
+   /* We only allocate in PAGE_SIZE/GTT_PAGE_SIZE (4096) chunks,
+* so we know that we always have a minimum alignment of 4096.
+* The drm_mm range manager is optimised to return results
+* with zero alignment, so where possible use the optimal
+* path.
+*/
+   if (alignment <= 4096)
+   alignment = 0;
+
 search_free:
ret = drm_mm_insert_node_in_range_generic(>mm, >node,
  size, alignment,
-- 
2.8.1

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

[Intel-gfx] [CI 15/26] drm/i915: Start passing around i915_vma from execbuffer

[Chris Wilson]

During execbuffer we look up the i915_vma in order to reserve them in
the VM. However, we then do a double lookup of the vma in order to then
pin them, all because we lack the necessary interfaces to operate on
i915_vma - so introduce i915_vma_pin()!

v2: Tidy parameter lists to remove one level of redirection in the hot
path.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h|  24 +---
 drivers/gpu/drm/i915/i915_gem.c| 173 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 142 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|   3 -
 drivers/gpu/drm/i915/i915_gem_gtt.h|  14 +++
 5 files changed, 149 insertions(+), 207 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d73394b52d7..cda8238c952f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3018,23 +3018,6 @@ struct drm_i915_gem_object 
*i915_gem_object_create_from_data(
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
 void i915_gem_free_object(struct drm_gem_object *obj);
 
-/* Flags used by pin/bind */
-#define PIN_MAPPABLE   (1<<0)
-#define PIN_NONBLOCK   (1<<1)
-#define PIN_GLOBAL (1<<2)
-#define PIN_OFFSET_BIAS(1<<3)
-#define PIN_USER   (1<<4)
-#define PIN_UPDATE (1<<5)
-#define PIN_ZONE_4G(1<<6)
-#define PIN_HIGH   (1<<7)
-#define PIN_OFFSET_FIXED   (1<<8)
-#define PIN_OFFSET_MASK (~4095)
-int __must_check
-i915_gem_object_pin(struct drm_i915_gem_object *obj,
-   struct i915_address_space *vm,
-   u64 size,
-   u64 alignment,
-   u64 flags);
 int __must_check
 i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 const struct i915_ggtt_view *view,
@@ -3311,11 +3294,8 @@ i915_gem_obj_ggtt_pin(struct drm_i915_gem_object *obj,
  uint32_t alignment,
  unsigned flags)
 {
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   struct i915_ggtt *ggtt = _priv->ggtt;
-
-   return i915_gem_object_pin(obj, >base, 0, alignment,
-  flags | PIN_GLOBAL);
+   return i915_gem_object_ggtt_pin(obj, _ggtt_view_normal,
+   0, alignment, flags);
 }
 
 void i915_gem_object_ggtt_unpin_view(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6987cb22ff9c..325a546ff88e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2963,34 +2963,30 @@ static bool i915_gem_valid_gtt_space(struct i915_vma 
*vma,
 }
 
 /**
- * Finds free space in the GTT aperture and binds the object or a view of it
- * there.
- * @obj: object to bind
- * @vm: address space to bind into
- * @ggtt_view: global gtt view if applicable
+ * i915_vma_insert - finds a slot for the vma in its address space
+ * @vma: the vma
  * @size: requested size in bytes (can be larger than the VMA)
- * @alignment: requested alignment
+ * @alignment: required alignment
  * @flags: mask of PIN_* flags to use
+ *
+ * First we try to allocate some free space that meets the requirements for
+ * the VMA. Failiing that, if the flags permit, it will evict an old VMA,
+ * preferrably the oldest idle entry to make room for the new VMA.
+ *
+ * Returns:
+ * 0 on success, negative error code otherwise.
  */
-static struct i915_vma *
-i915_gem_object_insert_into_vm(struct drm_i915_gem_object *obj,
-  struct i915_address_space *vm,
-  const struct i915_ggtt_view *ggtt_view,
-  u64 size,
-  u64 alignment,
-  u64 flags)
+static int
+i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
 {
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   struct i915_vma *vma;
+   struct drm_i915_private *dev_priv = to_i915(vma->vm->dev);
+   struct drm_i915_gem_object *obj = vma->obj;
u64 start, end;
u64 min_alignment;
int ret;
 
-   vma = ggtt_view ?
-   i915_gem_obj_lookup_or_create_ggtt_vma(obj, ggtt_view) :
-   i915_gem_obj_lookup_or_create_vma(obj, vm);
-   if (IS_ERR(vma))
-   return vma;
+   GEM_BUG_ON(vma->bound);
+   GEM_BUG_ON(drm_mm_node_allocated(>node));
 
size = max(size, vma->size);
if (flags & PIN_MAPPABLE)
@@ -3004,7 +3000,7 @@ i915_gem_object_insert_into_vm(struct drm_i915_gem_object 
*obj,
if (alignment & (min_alignment - 1)) {
DRM_DEBUG("Invalid object alignment requested %llu, minimum 
%llu\n",
  alignment, 

[Intel-gfx] [CI 06/26] drm/i915: Fix up vma alignment to be u64

[Chris Wilson]

This is not the full fix, as we are required to percolate the u64 nature
down through the drm_mm stack, but this is required now to prevent
explosions due to mismatch between execbuf (eb_vma_misplaced) and vma
binding (i915_vma_misplaced) - and reduces the risk of spurious changes
as we adjust the vma interface in the next patches.

v2: long long casts not required for u64 printk (%llx)

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h   | 14 ++
 drivers/gpu/drm/i915/i915_gem.c   | 22 +++---
 drivers/gpu/drm/i915/i915_gem_evict.c |  5 +++--
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2de3d16f7b80..74a31358fd87 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3032,13 +3032,13 @@ void i915_gem_free_object(struct drm_gem_object *obj);
 int __must_check
 i915_gem_object_pin(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
-   uint32_t alignment,
-   uint64_t flags);
+   u64 alignment,
+   u64 flags);
 int __must_check
 i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
 const struct i915_ggtt_view *view,
-uint32_t alignment,
-uint64_t flags);
+u64 alignment,
+u64 flags);
 
 int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
  u32 flags);
@@ -3398,11 +3398,9 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev, void *data,
 
 /* i915_gem_evict.c */
 int __must_check i915_gem_evict_something(struct i915_address_space *vm,
- int min_size,
- unsigned alignment,
+ u64 min_size, u64 alignment,
  unsigned cache_level,
- unsigned long start,
- unsigned long end,
+ u64 start, u64 end,
  unsigned flags);
 int __must_check i915_gem_evict_for_vma(struct i915_vma *target);
 int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d8b2fbb9bcb9..504414c4285c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2963,8 +2963,8 @@ static struct i915_vma *
 i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
   struct i915_address_space *vm,
   const struct i915_ggtt_view *ggtt_view,
-  unsigned alignment,
-  uint64_t flags)
+  u64 alignment,
+  u64 flags)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3023,7 +3023,7 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
*obj,
alignment = flags & PIN_MAPPABLE ? fence_alignment :
unfenced_alignment;
if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
-   DRM_DEBUG("Invalid object (view type=%u) alignment requested 
%u\n",
+   DRM_DEBUG("Invalid object (view type=%u) alignment requested 
%llx\n",
  ggtt_view ? ggtt_view->type : 0,
  alignment);
return ERR_PTR(-EINVAL);
@@ -3678,7 +3678,7 @@ i915_gem_ring_throttle(struct drm_device *dev, struct 
drm_file *file)
 }
 
 static bool
-i915_vma_misplaced(struct i915_vma *vma, uint32_t alignment, uint64_t flags)
+i915_vma_misplaced(struct i915_vma *vma, u64 alignment, u64 flags)
 {
struct drm_i915_gem_object *obj = vma->obj;
 
@@ -3727,8 +3727,8 @@ static int
 i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
   struct i915_address_space *vm,
   const struct i915_ggtt_view *ggtt_view,
-  uint32_t alignment,
-  uint64_t flags)
+  u64 alignment,
+  u64 flags)
 {
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct i915_vma *vma;
@@ -3757,7 +3757,7 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
if (i915_vma_misplaced(vma, alignment, flags)) {
WARN(vma->pin_count,
 "bo is already pinned in %s with incorrect 
alignment:"
-" offset=%08x %08x, req.alignment=%x, 
req.map_and_fenceable=%d,"
+   

[Intel-gfx] [CI 12/26] drm/i915: Update i915_gem_get_ggtt_size/_alignment to use drm_i915_private

[Chris Wilson]

For consistency, internal functions should take drm_i915_private rather
than drm_device. Now that we are subclassing drm_device, there are no
more size wins, but being consistent is its own blessing.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h|  5 +++--
 drivers/gpu/drm/i915/i915_gem.c| 30 --
 drivers/gpu/drm/i915/i915_gem_tiling.c |  8 
 3 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b6e56ecb8637..3d73394b52d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3241,8 +3241,9 @@ int i915_gem_object_attach_phys(struct 
drm_i915_gem_object *obj,
 int i915_gem_open(struct drm_device *dev, struct drm_file *file);
 void i915_gem_release(struct drm_device *dev, struct drm_file *file);
 
-u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int tiling_mode);
-u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, u64 size,
+u64 i915_gem_get_ggtt_size(struct drm_i915_private *dev_priv, u64 size,
+  int tiling_mode);
+u64 i915_gem_get_ggtt_alignment(struct drm_i915_private *dev_priv, u64 size,
int tiling_mode, bool fenced);
 
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0be3c5e4d307..b8f7c821d184 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1849,25 +1849,26 @@ i915_gem_release_all_mmaps(struct drm_i915_private 
*dev_priv)
 
 /**
  * i915_gem_get_ggtt_size - return required global GTT size for an object
- * @dev: drm device
+ * @dev_priv: i915 device
  * @size: object size
  * @tiling_mode: tiling mode
  *
  * Return the required global GTT size for an object, taking into account
  * potential fence register mapping.
  */
-u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int tiling_mode)
+u64 i915_gem_get_ggtt_size(struct drm_i915_private *dev_priv,
+  u64 size, int tiling_mode)
 {
u64 ggtt_size;
 
GEM_BUG_ON(size == 0);
 
-   if (INTEL_GEN(dev) >= 4 ||
+   if (INTEL_GEN(dev_priv) >= 4 ||
tiling_mode == I915_TILING_NONE)
return size;
 
/* Previous chips need a power-of-two fence region when tiling */
-   if (IS_GEN3(dev))
+   if (IS_GEN3(dev_priv))
ggtt_size = 1024*1024;
else
ggtt_size = 512*1024;
@@ -1880,7 +1881,7 @@ u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 
size, int tiling_mode)
 
 /**
  * i915_gem_get_ggtt_alignment - return required global GTT alignment
- * @dev: drm device
+ * @dev_priv: i915 device
  * @size: object size
  * @tiling_mode: tiling mode
  * @fenced: is fenced alignment required or not
@@ -1888,7 +1889,7 @@ u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 
size, int tiling_mode)
  * Return the required global GTT alignment for an object, taking into account
  * potential fence register mapping.
  */
-u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, u64 size,
+u64 i915_gem_get_ggtt_alignment(struct drm_i915_private *dev_priv, u64 size,
int tiling_mode, bool fenced)
 {
GEM_BUG_ON(size == 0);
@@ -1897,7 +1898,7 @@ u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, 
u64 size,
 * Minimum alignment is 4k (GTT page size), but might be greater
 * if a fence register is needed for the object.
 */
-   if (INTEL_GEN(dev) >= 4 || (!fenced && IS_G33(dev)) ||
+   if (INTEL_GEN(dev_priv) >= 4 || (!fenced && IS_G33(dev_priv)) ||
tiling_mode == I915_TILING_NONE)
return 4096;
 
@@ -1905,7 +1906,7 @@ u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, 
u64 size,
 * Previous chips need to be aligned to the size of the smallest
 * fence register that can contain the object.
 */
-   return i915_gem_get_ggtt_size(dev, size, tiling_mode);
+   return i915_gem_get_ggtt_size(dev_priv, size, tiling_mode);
 }
 
 static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object *obj)
@@ -2995,14 +2996,14 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
 
view_size = i915_ggtt_view_size(obj, ggtt_view);
 
-   fence_size = i915_gem_get_ggtt_size(dev,
+   fence_size = i915_gem_get_ggtt_size(dev_priv,
view_size,
obj->tiling_mode);
-   fence_alignment = i915_gem_get_ggtt_alignment(dev,
+   fence_alignment = i915_gem_get_ggtt_alignment(dev_priv,
  view_size,

[Intel-gfx] [CI 24/26] drm/i915: Move i915_gem_object_wait_rendering()

[Chris Wilson]

Just move it earlier so that we can use the companion nonblocking
version in a couple of more callsites without having to add a forward
declaration.

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

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ce422e0dce8f..852a14468804 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -302,6 +302,109 @@ i915_gem_object_unbind(struct drm_i915_gem_object *obj)
return ret;
 }
 
+/**
+ * Ensures that all rendering to the object has completed and the object is
+ * safe to unbind from the GTT or access from the CPU.
+ * @obj: i915 gem object
+ * @readonly: waiting for just read access or read-write access
+ */
+int
+i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
+  bool readonly)
+{
+   struct reservation_object *resv;
+   struct i915_gem_active *active;
+   unsigned long active_mask;
+   int idx;
+
+   lockdep_assert_held(>base.dev->struct_mutex);
+
+   if (!readonly) {
+   active = obj->last_read;
+   active_mask = i915_gem_object_get_active(obj);
+   } else {
+   active_mask = 1;
+   active = >last_write;
+   }
+
+   for_each_active(active_mask, idx) {
+   int ret;
+
+   ret = i915_gem_active_wait([idx],
+  >base.dev->struct_mutex);
+   if (ret)
+   return ret;
+   }
+
+   resv = i915_gem_object_get_dmabuf_resv(obj);
+   if (resv) {
+   long err;
+
+   err = reservation_object_wait_timeout_rcu(resv, !readonly, true,
+ MAX_SCHEDULE_TIMEOUT);
+   if (err < 0)
+   return err;
+   }
+
+   return 0;
+}
+
+/* A nonblocking variant of the above wait. This is a highly dangerous routine
+ * as the object state may change during this call.
+ */
+static __must_check int
+i915_gem_object_wait_rendering__nonblocking(struct drm_i915_gem_object *obj,
+   struct intel_rps_client *rps,
+   bool readonly)
+{
+   struct drm_device *dev = obj->base.dev;
+   struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
+   struct i915_gem_active *active;
+   unsigned long active_mask;
+   int ret, i, n = 0;
+
+   lockdep_assert_held(>struct_mutex);
+   GEM_BUG_ON(!to_i915(dev)->mm.interruptible);
+
+   active_mask = i915_gem_object_get_active(obj);
+   if (!active_mask)
+   return 0;
+
+   if (!readonly) {
+   active = obj->last_read;
+   } else {
+   active_mask = 1;
+   active = >last_write;
+   }
+
+   for_each_active(active_mask, i) {
+   struct drm_i915_gem_request *req;
+
+   req = i915_gem_active_get([i],
+ >base.dev->struct_mutex);
+   if (req)
+   requests[n++] = req;
+   }
+
+   mutex_unlock(>struct_mutex);
+   ret = 0;
+   for (i = 0; ret == 0 && i < n; i++)
+   ret = i915_wait_request(requests[i], true, NULL, rps);
+   mutex_lock(>struct_mutex);
+
+   for (i = 0; i < n; i++)
+   i915_gem_request_put(requests[i]);
+
+   return ret;
+}
+
+static struct intel_rps_client *to_rps_client(struct drm_file *file)
+{
+   struct drm_i915_file_private *fpriv = file->driver_priv;
+
+   return >rps;
+}
+
 int
 i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
int align)
@@ -1339,107 +1442,6 @@ put_rpm:
return ret;
 }
 
-/**
- * Ensures that all rendering to the object has completed and the object is
- * safe to unbind from the GTT or access from the CPU.
- * @obj: i915 gem object
- * @readonly: waiting for read access or write
- */
-int
-i915_gem_object_wait_rendering(struct drm_i915_gem_object *obj,
-  bool readonly)
-{
-   struct reservation_object *resv;
-   struct i915_gem_active *active;
-   unsigned long active_mask;
-   int idx, ret;
-
-   lockdep_assert_held(>base.dev->struct_mutex);
-
-   if (!readonly) {
-   active = obj->last_read;
-   active_mask = i915_gem_object_get_active(obj);
-   } else {
-   active_mask = 1;
-   active = >last_write;
-   }
-
-   for_each_active(active_mask, idx) {
-   ret = i915_gem_active_wait([idx],
-  >base.dev->struct_mutex);
-   if (ret)
-   return ret;
- 

[Intel-gfx] [CI 23/26] drm/i915: Move obj->active:5 to obj->flags

[Chris Wilson]

We are motivated to avoid using a bitfield for obj->active for a couple
of reasons. Firstly, we wish to document our lockless read of obj->active
using READ_ONCE inside i915_gem_busy_ioctl() and that requires an
integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code
when presented with a bitfield and that shows up high on the profiles of
request tracking (mainly due to excess memory traffic as it converts
the bitfield to a register and back and generates frequent AGI in the
process).

v2: BIT, break up a long line in compute the other engines, new paint
for i915_gem_object_is_active (now i915_gem_object_get_active).

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h| 37 +-
 drivers/gpu/drm/i915/i915_gem.c| 16 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 20 
 drivers/gpu/drm/i915/i915_gem_shrinker.c   |  5 ++--
 drivers/gpu/drm/i915/i915_gem_userptr.c|  2 +-
 6 files changed, 64 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9796b07bdb0d..24d63e271f4b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -91,7 +91,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
 
 static char get_active_flag(struct drm_i915_gem_object *obj)
 {
-   return obj->active ? '*' : ' ';
+   return i915_gem_object_is_active(obj) ? '*' : ' ';
 }
 
 static char get_pin_flag(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3de75e82ca76..db5dc5bd78d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2155,12 +2155,16 @@ struct drm_i915_gem_object {
 
struct list_head batch_pool_link;
 
+   unsigned long flags;
/**
 * This is set if the object is on the active lists (has pending
 * rendering and so a non-zero seqno), and is not set if it i s on
 * inactive (ready to be unbound) list.
 */
-   unsigned int active:I915_NUM_ENGINES;
+#define I915_BO_ACTIVE_SHIFT 0
+#define I915_BO_ACTIVE_MASK ((1 << I915_NUM_ENGINES) - 1)
+#define __I915_BO_ACTIVE(bo) \
+   ((READ_ONCE((bo)->flags) >> I915_BO_ACTIVE_SHIFT) & I915_BO_ACTIVE_MASK)
 
/**
 * This is set if the object has been written to since last bound
@@ -2325,6 +2329,37 @@ i915_gem_object_has_struct_page(const struct 
drm_i915_gem_object *obj)
return obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE;
 }
 
+static inline unsigned long
+i915_gem_object_get_active(const struct drm_i915_gem_object *obj)
+{
+   return (obj->flags >> I915_BO_ACTIVE_SHIFT) & I915_BO_ACTIVE_MASK;
+}
+
+static inline bool
+i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
+{
+   return i915_gem_object_get_active(obj);
+}
+
+static inline void
+i915_gem_object_set_active(struct drm_i915_gem_object *obj, int engine)
+{
+   obj->flags |= BIT(engine + I915_BO_ACTIVE_SHIFT);
+}
+
+static inline void
+i915_gem_object_clear_active(struct drm_i915_gem_object *obj, int engine)
+{
+   obj->flags &= ~BIT(engine + I915_BO_ACTIVE_SHIFT);
+}
+
+static inline bool
+i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
+ int engine)
+{
+   return obj->flags & BIT(engine + I915_BO_ACTIVE_SHIFT);
+}
+
 /*
  * Optimised SGL iterator for GEM objects
  */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3c0531ba8f60..ce422e0dce8f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1358,7 +1358,7 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
 
if (!readonly) {
active = obj->last_read;
-   active_mask = obj->active;
+   active_mask = i915_gem_object_get_active(obj);
} else {
active_mask = 1;
active = >last_write;
@@ -1402,7 +1402,7 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
BUG_ON(!mutex_is_locked(>struct_mutex));
BUG_ON(!dev_priv->mm.interruptible);
 
-   active_mask = obj->active;
+   active_mask = i915_gem_object_get_active(obj);
if (!active_mask)
return 0;
 
@@ -2365,10 +2365,10 @@ i915_gem_object_retire__read(struct i915_gem_active 
*active,
struct drm_i915_gem_object *obj =
container_of(active, struct drm_i915_gem_object, 
last_read[idx]);
 
-   GEM_BUG_ON((obj->active & (1 << idx)) == 0);
+   GEM_BUG_ON(!i915_gem_object_has_active_engine(obj, idx));
 
-   obj->active &= ~(1 << idx);
-   if (obj->active)
+   i915_gem_object_clear_active(obj, idx);
+   if 

[Intel-gfx] [CI 16/26] drm/i915: Combine all i915_vma bitfields into a single set of flags

[Chris Wilson]

In preparation to perform some magic to speed up i915_vma_pin(), which
is among the hottest of hot paths in execbuf, refactor all the bitfields
accessed by i915_vma_pin() into a single unified set of flags.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  8 ++---
 drivers/gpu/drm/i915/i915_gem.c| 40 --
 drivers/gpu/drm/i915/i915_gem_context.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  5 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c| 46 -
 drivers/gpu/drm/i915/i915_gem_gtt.h| 55 ++
 drivers/gpu/drm/i915/i915_gem_shrinker.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_stolen.c |  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  4 +--
 9 files changed, 90 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4401a2ab9a74..8d47d1bf7b85 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -125,7 +125,7 @@ static u64 i915_gem_obj_total_ggtt_size(struct 
drm_i915_gem_object *obj)
struct i915_vma *vma;
 
list_for_each_entry(vma, >vma_list, obj_link) {
-   if (vma->is_ggtt && drm_mm_node_allocated(>node))
+   if (i915_vma_is_ggtt(vma) && drm_mm_node_allocated(>node))
size += vma->node.size;
}
 
@@ -181,9 +181,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
continue;
 
seq_printf(m, " (%sgtt offset: %08llx, size: %08llx",
-  vma->is_ggtt ? "g" : "pp",
+  i915_vma_is_ggtt(vma) ? "g" : "pp",
   vma->node.start, vma->node.size);
-   if (vma->is_ggtt)
+   if (i915_vma_is_ggtt(vma))
seq_printf(m, ", type: %u", vma->ggtt_view.type);
seq_puts(m, ")");
}
@@ -356,7 +356,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (!drm_mm_node_allocated(>node))
continue;
 
-   if (vma->is_ggtt) {
+   if (i915_vma_is_ggtt(vma)) {
stats->global += vma->node.size;
} else {
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vma->vm);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 325a546ff88e..c47ffe151c82 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2861,7 +2861,8 @@ int i915_vma_unbind(struct i915_vma *vma)
GEM_BUG_ON(obj->bind_count == 0);
GEM_BUG_ON(!obj->pages);
 
-   if (vma->is_ggtt && vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
+   if (i915_vma_is_ggtt(vma) &&
+   vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
i915_gem_object_finish_gtt(obj);
 
/* release the fence reg _after_ flushing */
@@ -2876,12 +2877,12 @@ int i915_vma_unbind(struct i915_vma *vma)
trace_i915_vma_unbind(vma);
vma->vm->unbind_vma(vma);
}
-   vma->bound = 0;
+   vma->flags &= ~(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND);
 
drm_mm_remove_node(>node);
list_move_tail(>vm_link, >vm->unbound_list);
 
-   if (vma->is_ggtt) {
+   if (i915_vma_is_ggtt(vma)) {
if (vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL) {
obj->map_and_fenceable = false;
} else if (vma->ggtt_view.pages) {
@@ -2904,7 +2905,7 @@ int i915_vma_unbind(struct i915_vma *vma)
i915_gem_object_unpin_pages(obj);
 
 destroy:
-   if (unlikely(vma->closed))
+   if (unlikely(i915_vma_is_closed(vma)))
i915_vma_destroy(vma);
 
return 0;
@@ -2985,7 +2986,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
u64 min_alignment;
int ret;
 
-   GEM_BUG_ON(vma->bound);
+   GEM_BUG_ON(vma->flags & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND));
GEM_BUG_ON(drm_mm_node_allocated(>node));
 
size = max(size, vma->size);
@@ -3707,13 +3708,14 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma 
*vma)
 int
 i915_vma_pin(struct i915_vma *vma, u64 size, u64 alignment, u64 flags)
 {
-   unsigned int bound = vma->bound;
+   unsigned int bound;
int ret;
 
GEM_BUG_ON((flags & (PIN_GLOBAL | PIN_USER)) == 0);
-   GEM_BUG_ON((flags & PIN_GLOBAL) && !vma->is_ggtt);
+   GEM_BUG_ON((flags & PIN_GLOBAL) && !i915_vma_is_ggtt(vma));
 
-   if (WARN_ON(i915_vma_pin_count(vma) == 
DRM_I915_GEM_OBJECT_MAX_PIN_COUNT))
+   bound = vma->flags;
+   if (WARN_ON((bound & I915_VMA_PIN_MASK) == I915_VMA_PIN_MASK))
return -EBUSY;
 
/* Pin early to prevent 

[Intel-gfx] [CI 02/26] drm/i915: Remove surplus drm_device parameter to i915_gem_evict_something()

[Chris Wilson]

Eviction is VM local, so we can ignore the significance of the
drm_device in the caller, and leave it to i915_gem_evict_something() to
manage itself.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h   |  3 +--
 drivers/gpu/drm/i915/i915_gem.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_evict.c |  9 -
 drivers/gpu/drm/i915/i915_gem_gtt.c   |  2 +-
 drivers/gpu/drm/i915/i915_trace.h | 14 --
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 66b98fa4715a..fbda38f25c6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3398,8 +3398,7 @@ int i915_gem_context_reset_stats_ioctl(struct drm_device 
*dev, void *data,
   struct drm_file *file);
 
 /* i915_gem_evict.c */
-int __must_check i915_gem_evict_something(struct drm_device *dev,
- struct i915_address_space *vm,
+int __must_check i915_gem_evict_something(struct i915_address_space *vm,
  int min_size,
  unsigned alignment,
  unsigned cache_level,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9cb838ef8d02..d8b2fbb9bcb9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3089,7 +3089,7 @@ search_free:
  search_flag,
  alloc_flag);
if (ret) {
-   ret = i915_gem_evict_something(dev, vm, size, alignment,
+   ret = i915_gem_evict_something(vm, size, alignment,
   obj->cache_level,
   start, end,
   flags);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 016be7316676..4bce72fa14c4 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -61,7 +61,6 @@ mark_free(struct i915_vma *vma, struct list_head *unwind)
 
 /**
  * i915_gem_evict_something - Evict vmas to make room for binding a new one
- * @dev: drm_device
  * @vm: address space to evict from
  * @min_size: size of the desired free space
  * @alignment: alignment constraint of the desired free space
@@ -84,12 +83,12 @@ mark_free(struct i915_vma *vma, struct list_head *unwind)
  * memory in e.g. the shrinker.
  */
 int
-i915_gem_evict_something(struct drm_device *dev, struct i915_address_space *vm,
+i915_gem_evict_something(struct i915_address_space *vm,
 int min_size, unsigned alignment, unsigned cache_level,
 unsigned long start, unsigned long end,
 unsigned flags)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct list_head eviction_list;
struct list_head *phases[] = {
>inactive_list,
@@ -99,7 +98,7 @@ i915_gem_evict_something(struct drm_device *dev, struct 
i915_address_space *vm,
struct i915_vma *vma, *next;
int ret;
 
-   trace_i915_gem_evict(dev, min_size, alignment, flags);
+   trace_i915_gem_evict(vm, min_size, alignment, flags);
 
/*
 * The goal is to evict objects and amalgamate space in LRU order.
@@ -154,7 +153,7 @@ search_again:
 * back to userspace to give our workqueues time to
 * acquire our locks and unpin the old scanouts.
 */
-   return intel_has_pending_fb_unpin(dev) ? -EAGAIN : -ENOSPC;
+   return intel_has_pending_fb_unpin(vm->dev) ? -EAGAIN : -ENOSPC;
}
 
/* Not everything in the GGTT is tracked via vma (otherwise we
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 685ca2aaada8..f1f14e5a5a99 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2012,7 +2012,7 @@ alloc:
  0, ggtt->base.total,
  DRM_MM_TOPDOWN);
if (ret == -ENOSPC && !retried) {
-   ret = i915_gem_evict_something(dev, >base,
+   ret = i915_gem_evict_something(>base,
   GEN6_PD_SIZE, GEN6_PD_ALIGN,
   I915_CACHE_NONE,
   0, ggtt->base.total,
diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 9e43c0aa6e3b..178798002a73 

[Intel-gfx] [CI 03/26] drm/i915: Double check the active status on the batch pool

[Chris Wilson]

We should not rely on obj->active being uptodate unless we manually
flush it. Instead, we can verify that the next available batch object is
idle by looking at its last active request (and checking it for
completion).

v2: remove the struct drm_device forward declaration added in the
process of removing its necessity

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 15 ---
 drivers/gpu/drm/i915/i915_gem_batch_pool.h |  6 --
 drivers/gpu/drm/i915/intel_engine_cs.c |  2 +-
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 825981b5aa40..ed989596d9a3 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -41,15 +41,15 @@
 
 /**
  * i915_gem_batch_pool_init() - initialize a batch buffer pool
- * @dev: the drm device
+ * @engine: the associated request submission engine
  * @pool: the batch buffer pool
  */
-void i915_gem_batch_pool_init(struct drm_device *dev,
+void i915_gem_batch_pool_init(struct intel_engine_cs *engine,
  struct i915_gem_batch_pool *pool)
 {
int n;
 
-   pool->dev = dev;
+   pool->engine = engine;
 
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++)
INIT_LIST_HEAD(>cache_list[n]);
@@ -65,7 +65,7 @@ void i915_gem_batch_pool_fini(struct i915_gem_batch_pool 
*pool)
 {
int n;
 
-   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+   lockdep_assert_held(>engine->i915->drm.struct_mutex);
 
for (n = 0; n < ARRAY_SIZE(pool->cache_list); n++) {
struct drm_i915_gem_object *obj, *next;
@@ -101,7 +101,7 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
struct list_head *list;
int n;
 
-   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
+   lockdep_assert_held(>engine->i915->drm.struct_mutex);
 
/* Compute a power-of-two bucket, but throw everything greater than
 * 16KiB into the same bucket: i.e. the the buckets hold objects of
@@ -114,7 +114,8 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
 
list_for_each_entry_safe(tmp, next, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
-   if (tmp->active)
+   if (!i915_gem_active_is_idle(>last_read[pool->engine->id],
+>base.dev->struct_mutex))
break;
 
/* While we're looping, do some clean up */
@@ -133,7 +134,7 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
if (obj == NULL) {
int ret;
 
-   obj = i915_gem_object_create(pool->dev, size);
+   obj = i915_gem_object_create(>engine->i915->drm, size);
if (IS_ERR(obj))
return obj;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
index 848e90703eed..10d5ac4c00d3 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
@@ -27,13 +27,15 @@
 
 #include "i915_drv.h"
 
+struct intel_engine_cs;
+
 struct i915_gem_batch_pool {
-   struct drm_device *dev;
+   struct intel_engine_cs *engine;
struct list_head cache_list[4];
 };
 
 /* i915_gem_batch_pool.c */
-void i915_gem_batch_pool_init(struct drm_device *dev,
+void i915_gem_batch_pool_init(struct intel_engine_cs *engine,
  struct i915_gem_batch_pool *pool);
 void i915_gem_batch_pool_fini(struct i915_gem_batch_pool *pool);
 struct drm_i915_gem_object*
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 202ad83b3dd1..f495969f749b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -185,7 +185,7 @@ void intel_engine_setup_common(struct intel_engine_cs 
*engine)
engine->fence_context = fence_context_alloc(1);
 
intel_engine_init_hangcheck(engine);
-   i915_gem_batch_pool_init(>i915->drm, >batch_pool);
+   i915_gem_batch_pool_init(engine, >batch_pool);
 }
 
 /**
-- 
2.8.1

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

[Intel-gfx] [CI 04/26] drm/i915: Remove request retirement before each batch

[Chris Wilson]

This reimplements the denial-of-service protection against igt from
commit 227f782e4667 ("drm/i915: Retire requests before creating a new
one") and transfers the stall from before each batch into get_pages().
The issue is that the stall is increasing latency between batches which
is detrimental in some cases (especially coupled with execlists) to
keeping the GPU well fed. Also we have made the observation that retiring
requests can of itself free objects (and requests) and therefore makes
a good first step when shrinking.

v2: Recycle objects prior to i915_gem_object_get_pages()
v3: Remove the reference to the ring from i915_gem_requests_ring() as it
operates on an intel_engine_cs.
v4: Since commit 9b5f4e5ed6fd ("drm/i915: Retire oldest completed request
before allocating next") we no longer need the safeguard to retire
requests before get_pages(). We no longer see the huge latencies when
hitting the shrinker between allocations.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h| 1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 --
 drivers/gpu/drm/i915/i915_gem_request.c| 4 ++--
 3 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fbda38f25c6b..2de3d16f7b80 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3169,7 +3169,6 @@ struct drm_i915_gem_request *
 i915_gem_find_active_request(struct intel_engine_cs *engine);
 
 void i915_gem_retire_requests(struct drm_i915_private *dev_priv);
-void i915_gem_retire_requests_ring(struct intel_engine_cs *engine);
 
 static inline u32 i915_reset_counter(struct i915_gpu_error *error)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 5e3b5054f72d..0593ea3ba211 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -781,8 +781,6 @@ i915_gem_execbuffer_reserve(struct intel_engine_cs *engine,
bool has_fenced_gpu_access = INTEL_GEN(engine->i915) < 4;
int retry;
 
-   i915_gem_retire_requests_ring(engine);
-
vm = list_first_entry(vmas, struct i915_vma, exec_list)->vm;
 
INIT_LIST_HEAD(_vmas);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 6faa84832ade..773b942a3a5f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -732,7 +732,7 @@ complete:
return ret;
 }
 
-void i915_gem_retire_requests_ring(struct intel_engine_cs *engine)
+static void engine_retire_requests(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *request, *next;
 
@@ -756,7 +756,7 @@ void i915_gem_retire_requests(struct drm_i915_private 
*dev_priv)
GEM_BUG_ON(!dev_priv->gt.awake);
 
for_each_engine(engine, dev_priv) {
-   i915_gem_retire_requests_ring(engine);
+   engine_retire_requests(engine);
if (list_empty(>request_list))
dev_priv->gt.active_engines &= 
~intel_engine_flag(engine);
}
-- 
2.8.1

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

[Intel-gfx] [CI 09/26] drm/i915: Split insertion/binding of an object into the VM

[Chris Wilson]

Split the insertion into the address space's range manager and binding
of that object into the GTT to simplify the code flow when pinning a
VMA.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1e78ccc6538e..00f8d8fa0b04 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2961,12 +2961,12 @@ static bool i915_gem_valid_gtt_space(struct i915_vma 
*vma,
  * @flags: mask of PIN_* flags to use
  */
 static struct i915_vma *
-i915_gem_object_bind_to_vm(struct drm_i915_gem_object *obj,
-  struct i915_address_space *vm,
-  const struct i915_ggtt_view *ggtt_view,
-  u64 size,
-  u64 alignment,
-  u64 flags)
+i915_gem_object_insert_into_vm(struct drm_i915_gem_object *obj,
+  struct i915_address_space *vm,
+  const struct i915_ggtt_view *ggtt_view,
+  u64 size,
+  u64 alignment,
+  u64 flags)
 {
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -3092,19 +3092,12 @@ search_free:
}
GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, obj->cache_level));
 
-   trace_i915_vma_bind(vma, flags);
-   ret = i915_vma_bind(vma, obj->cache_level, flags);
-   if (ret)
-   goto err_remove_node;
-
list_move_tail(>global_list, _priv->mm.bound_list);
list_move_tail(>vm_link, >inactive_list);
obj->bind_count++;
 
return vma;
 
-err_remove_node:
-   drm_mm_remove_node(>node);
 err_vma:
vma = ERR_PTR(ret);
 err_unpin:
@@ -3764,24 +3757,26 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
}
}
 
-   bound = vma ? vma->bound : 0;
if (vma == NULL || !drm_mm_node_allocated(>node)) {
-   vma = i915_gem_object_bind_to_vm(obj, vm, ggtt_view,
-size, alignment, flags);
+   vma = i915_gem_object_insert_into_vm(obj, vm, ggtt_view,
+size, alignment, flags);
if (IS_ERR(vma))
return PTR_ERR(vma);
-   } else {
-   ret = i915_vma_bind(vma, obj->cache_level, flags);
-   if (ret)
-   return ret;
}
 
+   bound = vma->bound;
+   ret = i915_vma_bind(vma, obj->cache_level, flags);
+   if (ret)
+   return ret;
+
if (ggtt_view && ggtt_view->type == I915_GGTT_VIEW_NORMAL &&
(bound ^ vma->bound) & GLOBAL_BIND) {
__i915_vma_set_map_and_fenceable(vma);
WARN_ON(flags & PIN_MAPPABLE && !obj->map_and_fenceable);
}
 
+   GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
+
vma->pin_count++;
return 0;
 }
-- 
2.8.1

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

[Intel-gfx] [CI 01/26] drm/i915: Combine loops within i915_gem_evict_something

[Chris Wilson]

Slight micro-optimise to produce combine loops so that gcc is able to
optimise the inner-loops concisely. Since we are reviewing the loops, we
can update the comments to describe the current state of affairs, in
particular the distinction between evicting from the global GTT (which
may contain untracked items and transient global pins) and the
per-process GTT.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_evict.c | 143 +-
 1 file changed, 70 insertions(+), 73 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 3437ced76cb6..016be7316676 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -34,6 +34,19 @@
 #include "i915_trace.h"
 
 static bool
+gpu_is_idle(struct drm_i915_private *dev_priv)
+{
+   struct intel_engine_cs *engine;
+
+   for_each_engine(engine, dev_priv) {
+   if (!list_empty(>request_list))
+   return false;
+   }
+
+   return true;
+}
+
+static bool
 mark_free(struct i915_vma *vma, struct list_head *unwind)
 {
if (vma->pin_count)
@@ -76,37 +89,31 @@ i915_gem_evict_something(struct drm_device *dev, struct 
i915_address_space *vm,
 unsigned long start, unsigned long end,
 unsigned flags)
 {
-   struct list_head eviction_list, unwind_list;
-   struct i915_vma *vma;
-   int ret = 0;
-   int pass = 0;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct list_head eviction_list;
+   struct list_head *phases[] = {
+   >inactive_list,
+   >active_list,
+   NULL,
+   }, **phase;
+   struct i915_vma *vma, *next;
+   int ret;
 
trace_i915_gem_evict(dev, min_size, alignment, flags);
 
/*
 * The goal is to evict objects and amalgamate space in LRU order.
 * The oldest idle objects reside on the inactive list, which is in
-* retirement order. The next objects to retire are those on the (per
-* ring) active list that do not have an outstanding flush. Once the
-* hardware reports completion (the seqno is updated after the
-* batchbuffer has been finished) the clean buffer objects would
-* be retired to the inactive list. Any dirty objects would be added
-* to the tail of the flushing list. So after processing the clean
-* active objects we need to emit a MI_FLUSH to retire the flushing
-* list, hence the retirement order of the flushing list is in
-* advance of the dirty objects on the active lists.
+* retirement order. The next objects to retire are those in flight,
+* on the active list, again in retirement order.
 *
 * The retirement sequence is thus:
 *   1. Inactive objects (already retired)
-*   2. Clean active objects
-*   3. Flushing list
-*   4. Dirty active objects.
+*   2. Active objects (will stall on unbinding)
 *
 * On each list, the oldest objects lie at the HEAD with the freshest
 * object on the TAIL.
 */
-
-   INIT_LIST_HEAD(_list);
if (start != 0 || end != vm->total) {
drm_mm_init_scan_with_range(>mm, min_size,
alignment, cache_level,
@@ -114,79 +121,71 @@ i915_gem_evict_something(struct drm_device *dev, struct 
i915_address_space *vm,
} else
drm_mm_init_scan(>mm, min_size, alignment, cache_level);
 
-search_again:
-   /* First see if there is a large enough contiguous idle region... */
-   list_for_each_entry(vma, >inactive_list, vm_link) {
-   if (mark_free(vma, _list))
-   goto found;
-   }
-
if (flags & PIN_NONBLOCK)
-   goto none;
+   phases[1] = NULL;
 
-   /* Now merge in the soon-to-be-expired objects... */
-   list_for_each_entry(vma, >active_list, vm_link) {
-   if (mark_free(vma, _list))
-   goto found;
-   }
+search_again:
+   INIT_LIST_HEAD(_list);
+   phase = phases;
+   do {
+   list_for_each_entry(vma, *phase, vm_link)
+   if (mark_free(vma, _list))
+   goto found;
+   } while (*++phase);
 
-none:
/* Nothing found, clean up and bail out! */
-   while (!list_empty(_list)) {
-   vma = list_first_entry(_list,
-  struct i915_vma,
-  exec_list);
+   list_for_each_entry_safe(vma, next, _list, exec_list) {
ret = drm_mm_scan_remove_block(>node);
BUG_ON(ret);
 
-   list_del_init(>exec_list);
+   

[Intel-gfx] [CI 11/26] drm/i915: Update the GGTT size/alignment query functions

[Chris Wilson]

In order to be consistent with other address space functions, we want to
pass around 64-bit sizes, even though all known global GTT are limited
to 4GiB. Similarly, we are trying to be consistent in using the _ggtt_
nomenclature when referring to the special global GTT.

v2: Update docs to consistently state "global GTT".

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h|  8 ++--
 drivers/gpu/drm/i915/i915_gem.c| 81 +++---
 drivers/gpu/drm/i915/i915_gem_tiling.c |  3 +-
 3 files changed, 51 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e1369319326..b6e56ecb8637 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3241,11 +3241,9 @@ int i915_gem_object_attach_phys(struct 
drm_i915_gem_object *obj,
 int i915_gem_open(struct drm_device *dev, struct drm_file *file);
 void i915_gem_release(struct drm_device *dev, struct drm_file *file);
 
-uint32_t
-i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode);
-uint32_t
-i915_gem_get_gtt_alignment(struct drm_device *dev, uint32_t size,
-   int tiling_mode, bool fenced);
+u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int tiling_mode);
+u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, u64 size,
+   int tiling_mode, bool fenced);
 
 int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eedb80451dd5..0be3c5e4d307 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1847,46 +1847,57 @@ i915_gem_release_all_mmaps(struct drm_i915_private 
*dev_priv)
i915_gem_release_mmap(obj);
 }
 
-uint32_t
-i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode)
+/**
+ * i915_gem_get_ggtt_size - return required global GTT size for an object
+ * @dev: drm device
+ * @size: object size
+ * @tiling_mode: tiling mode
+ *
+ * Return the required global GTT size for an object, taking into account
+ * potential fence register mapping.
+ */
+u64 i915_gem_get_ggtt_size(struct drm_device *dev, u64 size, int tiling_mode)
 {
-   uint32_t gtt_size;
+   u64 ggtt_size;
 
-   if (INTEL_INFO(dev)->gen >= 4 ||
+   GEM_BUG_ON(size == 0);
+
+   if (INTEL_GEN(dev) >= 4 ||
tiling_mode == I915_TILING_NONE)
return size;
 
/* Previous chips need a power-of-two fence region when tiling */
if (IS_GEN3(dev))
-   gtt_size = 1024*1024;
+   ggtt_size = 1024*1024;
else
-   gtt_size = 512*1024;
+   ggtt_size = 512*1024;
 
-   while (gtt_size < size)
-   gtt_size <<= 1;
+   while (ggtt_size < size)
+   ggtt_size <<= 1;
 
-   return gtt_size;
+   return ggtt_size;
 }
 
 /**
- * i915_gem_get_gtt_alignment - return required GTT alignment for an object
+ * i915_gem_get_ggtt_alignment - return required global GTT alignment
  * @dev: drm device
  * @size: object size
  * @tiling_mode: tiling mode
- * @fenced: is fenced alignemned required or not
+ * @fenced: is fenced alignment required or not
  *
- * Return the required GTT alignment for an object, taking into account
+ * Return the required global GTT alignment for an object, taking into account
  * potential fence register mapping.
  */
-uint32_t
-i915_gem_get_gtt_alignment(struct drm_device *dev, uint32_t size,
-  int tiling_mode, bool fenced)
+u64 i915_gem_get_ggtt_alignment(struct drm_device *dev, u64 size,
+   int tiling_mode, bool fenced)
 {
+   GEM_BUG_ON(size == 0);
+
/*
 * Minimum alignment is 4k (GTT page size), but might be greater
 * if a fence register is needed for the object.
 */
-   if (INTEL_INFO(dev)->gen >= 4 || (!fenced && IS_G33(dev)) ||
+   if (INTEL_GEN(dev) >= 4 || (!fenced && IS_G33(dev)) ||
tiling_mode == I915_TILING_NONE)
return 4096;
 
@@ -1894,7 +1905,7 @@ i915_gem_get_gtt_alignment(struct drm_device *dev, 
uint32_t size,
 * Previous chips need to be aligned to the size of the smallest
 * fence register that can contain the object.
 */
-   return i915_gem_get_gtt_size(dev, size, tiling_mode);
+   return i915_gem_get_ggtt_size(dev, size, tiling_mode);
 }
 
 static int i915_gem_object_create_mmap_offset(struct drm_i915_gem_object *obj)
@@ -2984,17 +2995,17 @@ i915_gem_object_insert_into_vm(struct 
drm_i915_gem_object *obj,
 
view_size = i915_ggtt_view_size(obj, ggtt_view);
 
-   fence_size = i915_gem_get_gtt_size(dev,
-

Re: [Intel-gfx] [PATCH 0/4]: Picture aspect ratio support in DRM layer

[Jose Abreu]

On 04-08-2016 15:29, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 8/4/2016 7:46 PM, Jose Abreu wrote:
>> Hi Sharma,
>>
>>
>> On 03-08-2016 16:47, Sharma, Shashank wrote:
>>> Hello Joes,
 I've also seen this before and I am using them in order to
 pass HDMI compliance. Without
 these patches the compliance fails. Still, I've made some
 changes which I can submit. I've
 some comments to you (Shashank):
>>> Thanks for addressing these patches. You are welcome to
>>> review the series.
>>> Will it be possible for you, to comment in-line with the
>>> patch code, it's easier that way, and kind of conventional too.
>>>
 Second, you are expecting that the picture aspect field is
 correctly set in the HDMI parsing but, at least in the test
 equipment that I am using, this field is not set by the DRM
 layer because the mode is coming in the detailed timings
 section which does not
 include a picture aspect field. In my implementation I add a
 function which given the mode width and height (fields
 ->width_mm and ->height_mm of mode) computes the aspect
 ratio and populates the field.
>>> Please note that we can run the aspect ratio test cases (7-27
>>> and similar) for CEA modes only. For the modes coming from
>>> DTDs and VSDBs can be with or without aspect ratio.
>>> But the suggestion to initialize all the drm_modes with
>>> ASPECT_RATIO_NONE/DEFAULT is a good one, and it might help
>>> for these modes too.
>>> I think Daniel also had similar suggestion last time, in a
>>> different context.
>> In our compliance equipment the modes are coming from DTD and
>> from the video datablock but the kernel is preferring the DTD
>> modes so we found a way of determining the picture aspect ratio
>> from the DTD section. We do not populate the field with
>> ASPECT_RATIO_NONE/DEFAULT, we populate it given the ratio of
>> width_mm and height_mm that is sent in the DTD (of course if
>> these values are zero we set aspect ratio to none). I think it
>> could be a nice addition to the EDID parsing.
> I agree, I will come up with another patch, which does either
> of this:
> - initialize all the DRM_MODE with aspect ratio default while
> creating the new mode itself
> - initialize all the DRM_MODES  with aspect ratio default while
> parsing the modes.

Ok, please cc me when you send the new patches.

 Third, I am facing some difficulties when using Xserver and
 Xrandr. Using libdrm's modetest application everything works
 ok but with xrandr the aspect ratio gets lost between the
 link DRM
 -> Xserver -> DRM. I set the aspect ratio in the flags field
 when
 passing the mode to user level (just like you do in patch 2)
 but then when the mode is returned and delivered to the DRM
 driver the picture aspect is not present. I think this is
 due to how Xserver or xrandr sets the mode but I am not sure.
>>> I think while parsing the aspect ratio from libdrm to
>>> userspace (X), it's getting lost, and we have to fix your
>>> Xserver implementation.
>>> We had added similar support in our HWComposer, and I guess
>>> it would be required for X and Wayland too, coz finally these
>>> guys issue the modeset.
>>> So May be X server is not handling these flags, ignoring
>>> these flags, and sending the flagless modeset back to libdrm.
>> Do you mean Xserver, the X driver that I am using (which is
>> modesetting), the xrandr or all of them? I guess that if they
>> don't touch the flags field and return the mode exactly the same
>> as it was probed to DRM then it will work as expected.
> I agree, in fact, if the userspace is not even touching the
> flag field, we should get the aspect ratio information intact.
> But if we are populating the aspect ratio information while
> reading the modes from EDID, and passing the right flags to
> userspace, but still we see the modeset doesn't contain the
> right flags, means userspace is clearing the flags or modifying
> the flags. So we should check:
> - While creating a user_mode from kernel_mode, are we
> populating the aspect ratio flags (If you have my patches, this
> shoud work)

Yes, this is correct.

> - These modes are passed to userspace via a get_modes or
> get_connector IOCTLs, so we should check these IOCTLS

I think it is also happening correctly.

> - Once user space sends a modeset, does it set the flags
> properly ?

If it is a mode created by the user then I think not. If it is a
mode that was passed by the kernel then it will if the flags are
not touched. This correctly happens using libdrm's modetest but
it doesn't happen when using xrandr.

> - while creating a kernel_mode from user_mode, during modeset,
> are we preserving these flags ? (if you have my patches, this
> should work)

Again correct if the user does not touch the flags field.

Best regards,
Jose Miguel Abreu

>
> Regards
> Shashank
>> Best regards,
>> Jose Miguel Abreu
>>
>>> Regards
>>> Shashank
>>> -Original 

[Intel-gfx] [PATCH i-g-t v2] gem_largeobject: Fix for clang compiler

[Derek Morton]

The clang compiler generates a build error for binaries with >128MB
data segments because "The gap between stack and binary is only
guarenteed to be 128MB on x86_64"

Simple solution is to allocate the required memory from the heap.

[v2: moved malloc to after skip_on_simulation]

Signed-off-by: Derek Morton 
---
 tests/gem_largeobject.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tests/gem_largeobject.c b/tests/gem_largeobject.c
index c001c17..518396f 100644
--- a/tests/gem_largeobject.c
+++ b/tests/gem_largeobject.c
@@ -39,7 +39,7 @@
 /* Should take 64 pages to store the page pointers on 64 bit */
 #define OBJ_SIZE (128 * 1024 * 1024)
 
-unsigned char data[OBJ_SIZE];
+unsigned char *data;
 
 static void
 test_large_object(int fd)
@@ -79,7 +79,12 @@ igt_simple_main
 
igt_skip_on_simulation();
 
+   data = malloc(OBJ_SIZE);
+   igt_assert(data);
+
fd = drm_open_driver(DRIVER_INTEL);
 
test_large_object(fd);
+
+   free(data);
 }
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

[Emil Velikov]

On 4 August 2016 at 14:15, Sharma, Shashank  wrote:
> On 8/4/2016 5:04 PM, Emil Velikov wrote:
>>
>> On 4 August 2016 at 11:16, Sharma, Shashank 
>> wrote:
>>>
>>> Hello Emil,
>>>
>>> Thanks for your time.
>>>
>>> I have got mixed opinion on this.
>>>
>>> IMHO we should expose them to userspace too, as UI agents like Hardware
>>> composer/X/Wayland must know what does these
>>>
>>> flags means, so that they can display them on the end user screen (like
>>> settings menu)
>>>
>>> But few people even think thats its too complex to be exposed to
>>> userspace
>>> agents.
>>>
>> If we want these/such flags passed between kernel and user space one must:
>>   - Provide a kernel interface how to do that
>>   - Provide a userspace (acked by respective developers/maintainers)
>> that the approach is sane and proves useful.
>>
>> Since the above can take some time, I'd suggest dropping those from
>> the UAPI header(s)... for now.
>>
>> -Emil
>
> Please guide me a bit more on this problem, Emil, Daniel.
> The reason why I want to pass this to userspace is, so that, HWC/X/any other
> UI manager, can send a modeset
> which is accurate upto aspect ratio.
>
Nobody(?) is arguing that you don't to pass such information to/from
userspace :-)
Your series does the internal parsing/management of the attribute and
has no actual UAPI implementation and/or userspace references (to
code/discussions). Thus the UAPI changes should _not_ be part of these
patches.

Daniel's blog [1] has many educational materials why and how things
are done upstream. I would kindly invite you to give them (another?)
courtesy read.

Regards,
Emil

[1] 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 0/4]: Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 8/4/2016 7:46 PM, Jose Abreu wrote:

Hi Sharma,


On 03-08-2016 16:47, Sharma, Shashank wrote:

Hello Joes,

I've also seen this before and I am using them in order to pass HDMI 
compliance. Without
these patches the compliance fails. Still, I've made some changes which I can 
submit. I've
some comments to you (Shashank):

Thanks for addressing these patches. You are welcome to review the series.
Will it be possible for you, to comment in-line with the patch code, it's 
easier that way, and kind of conventional too.


Second, you are expecting that the picture aspect field is correctly set in the 
HDMI parsing but, at least in the test equipment that I am using, this field is 
not set by the DRM layer because the mode is coming in the detailed timings 
section which does not
include a picture aspect field. In my implementation I add a function which 
given the mode width and height (fields
->width_mm and ->height_mm of mode) computes the aspect ratio and populates the 
field.

Please note that we can run the aspect ratio test cases (7-27 and similar) for 
CEA modes only. For the modes coming from DTDs and VSDBs can be with or without 
aspect ratio.
But the suggestion to initialize all the drm_modes with 
ASPECT_RATIO_NONE/DEFAULT is a good one, and it might help for these modes too.
I think Daniel also had similar suggestion last time, in a different context.

In our compliance equipment the modes are coming from DTD and
from the video datablock but the kernel is preferring the DTD
modes so we found a way of determining the picture aspect ratio
from the DTD section. We do not populate the field with
ASPECT_RATIO_NONE/DEFAULT, we populate it given the ratio of
width_mm and height_mm that is sent in the DTD (of course if
these values are zero we set aspect ratio to none). I think it
could be a nice addition to the EDID parsing.

I agree, I will come up with another patch, which does either of this:
- initialize all the DRM_MODE with aspect ratio default while creating 
the new mode itself
- initialize all the DRM_MODES  with aspect ratio default while parsing 
the modes.

Third, I am facing some difficulties when using Xserver and Xrandr. Using 
libdrm's modetest application everything works ok but with xrandr the aspect 
ratio gets lost between the link DRM
-> Xserver -> DRM. I set the aspect ratio in the flags field when
passing the mode to user level (just like you do in patch 2) but then when the 
mode is returned and delivered to the DRM driver the picture aspect is not 
present. I think this is due to how Xserver or xrandr sets the mode but I am 
not sure.

I think while parsing the aspect ratio from libdrm to userspace (X), it's 
getting lost, and we have to fix your Xserver implementation.
We had added similar support in our HWComposer, and I guess it would be 
required for X and Wayland too, coz finally these guys issue the modeset.
So May be X server is not handling these flags, ignoring these flags, and 
sending the flagless modeset back to libdrm.

Do you mean Xserver, the X driver that I am using (which is
modesetting), the xrandr or all of them? I guess that if they
don't touch the flags field and return the mode exactly the same
as it was probed to DRM then it will work as expected.
I agree, in fact, if the userspace is not even touching the flag field, 
we should get the aspect ratio information intact.
But if we are populating the aspect ratio information while reading the 
modes from EDID, and passing the right flags to
userspace, but still we see the modeset doesn't contain the right flags, 
means userspace is clearing the flags or modifying

the flags. So we should check:
- While creating a user_mode from kernel_mode, are we populating the 
aspect ratio flags (If you have my patches, this shoud work)
- These modes are passed to userspace via a get_modes or get_connector 
IOCTLs, so we should check these IOCTLS

- Once user space sends a modeset, does it set the flags properly ?
- while creating a kernel_mode from user_mode, during modeset, are we 
preserving these flags ? (if you have my patches, this should work)


Regards
Shashank

Best regards,
Jose Miguel Abreu


Regards
Shashank
-Original Message-
From: Jose Abreu [mailto:jose.ab...@synopsys.com]
Sent: Wednesday, August 3, 2016 6:38 PM
To: Daniel Vetter ; Sharma, Shashank 

Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter, Daniel 
; Carlos Palminha 
Subject: Re: [PATCH 0/4]: Picture aspect ratio support in DRM layer

Hi,


On 03-08-2016 12:48, Daniel Vetter wrote:

On Wed, Aug 03, 2016 at 04:26:24PM +0530, Shashank Sharma wrote:

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
   supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA